{"version":"2.1.248","anchor":"tools-that-run-code-now-carry-an-enablescodeexecution-marker","canonical_anchor":"tools-that-run-code-now-carry-an-enablescodeexecution-marker","heading":"Tools that run code now carry an enablesCodeExecution marker","tier":"internal","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/tools-that-run-code-now-carry-an-enablescodeexecution-marker","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Tools that run code now carry an `enablesCodeExecution` marker\n\nBash, REPL and cloud trigger tools now carry a marker saying they execute code.\n\n**What**\n\nTool descriptors gained a new capability flag that marks a tool as one that executes code, so other logic can key permission or classification decisions off the descriptor instead of matching tool names. The Bash tool, the REPL tool and the cloud trigger tool all set it, and downstream filtering uses it to pick out the code-executing set.\n\n**Details**\n\n- The flag is `enablesCodeExecution`, set unconditionally to true on each of the three tool definitions, with no setting, environment variable or feature gate to turn it off.\n- Tools without the marker are treated as not executing code, which is the behaviour everything had before this build.\n- Nothing user-visible changes here: the marker is only read by internal filtering and classification, and no permission prompt, message or default is altered by it in this release.\n\n**Evidence**\n\n`enablesCodeExecution: !0,`, `enablesCodeExecution: !0`\n\n- Area: Permissions\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}