How does the Bash tool execute a command end-to-end, from permission classification through AST safety check to subprocess spawn and output streaming

en
100.0% sentence pass·19/19 cited·19/20 citations valid·95 fn·0 dec·765 sem
Tool FrameworkPermission & Security Framework

Bash Tool End-to-End Execution

Overview

This flow traces a model-emitted Bash tool_use from tool dispatch through permission gating, AST safety parsing, and eventual shell execution . The whitelist does not include the actual subprocess spawn or output-streaming internals, so that tail of the flow cannot be fully cited .

Steps

  1. The agent loop receives a tool_use block and calls runToolUse, which looks up the Bash tool by name and forwards to the permission+call pipeline .
  2. checkPermissionsAndCallTool runs zod input validation on the BashTool input schema and, on success, speculatively kicks off the async bash classifier in parallel with the permission dialog setup .
  3. It then invokes the canUseTool callback, which in print/headless mode delegates to hasPermissionsToUseTool and only falls back to the permission prompt tool when the result is ask .
  4. hasPermissionsToUseTool computes a base decision, and if the session is in auto mode it routes ask outcomes through the YOLO classifier instead of a user prompt .
  5. For Bash specifically, bashToolHasPermission first tries the tree-sitter AST path: it parses the command and calls parseForSecurityFromAst to get either a clean SimpleCommand[], too-complex, or parse-unavailable .
  6. The parser entry point parseCommand dispatches on token shape — subshells, compound statements, test commands, keywords, function definitions — and falls through to parseSimpleCommand for ordinary argv .
  7. parseSimpleCommand accumulates assignments and pre-redirects via tryParseRedirect, then collects the command name and arguments while maybeRedirect wraps trailing redirects into a redirected_statement .
  8. Pipelines and &&/|| structure are layered on top by parsePipeline and parseTestAnd, giving bashToolHasPermission the tokenized subcommands it uses for rule matching .
  9. On too-complex, the code runs exact-match deny/ask/allow checks, and if nothing denies it returns ask with a pendingClassifierCheck so the bash classifier decides .
  10. When auto mode sends the action to the classifier, classifyYoloAction builds the transcript, picks a model, and dispatches to classifyYoloActionXml when the two-stage XML classifier is enabled .
  11. classifyYoloActionXml runs a fast stage-1 sideQuery that can return <block>no</block> for an immediate allow, otherwise escalates to a thinking stage-2 call and parses <block>/<reason> from the result .
  12. The sideQuery itself is executed by sideQuery, which acquires an Anthropic client via getAnthropicClient and issues the classifier request .
  13. Once permission resolves to allow, checkPermissionsAndCallTool invokes BashTool.call, which handles the _simulatedSedEdit fast path and otherwise drives runShellCommand as an async generator collecting stdout into an EndTruncatingAccumulator .
  14. The whitelisted source for BashTool.call is truncated before the actual runShellCommand subprocess spawn and stdout/stderr streaming, so the fd-level spawn and progress-yield loop cannot be cited from the provided context .

State touched

Decisions

None of the whitelisted tokens include [decision:...] entries for this flow, so no design-decision citations are available .