loading
loading
The harness component that actually executes a tool the model asked for and feeds the result back into context.
The model never runs anything itself — it emits a tool-call request, and the tool runner (inside the CLI/SDK) validates it against permissions, executes the real bash/edit/MCP call, captures stdout and errors, and returns that as the tool result for the next turn. This split is what makes hooks, allowlists, and sandboxing possible: enforcement lives in the runner, not the model. Example: when Claude 'edits a file', the runner applies the diff to disk and reports success or a failure the model must handle. Understanding this boundary is key to reasoning about safety and determinism.
Plainly
Think of Tool Runner as a named building block in a big LEGO app. The harness component that actually executes a tool the model asked for and feeds the result back into context.
In practice
Use it when you are mapping how the app is structured or explaining a feature to a teammate or agent. In practice, define the owner, input, output, and failure mode before you rely on it.