BashExecutor
Defined in: bash/executor.ts:7
Pluggable boundary a bash tool runs commands through. Implementations decide the actual isolation strategy (kernel-enforced OS sandbox, bare subprocess, container, …). A project picks one executor explicitly; a missing prerequisite is a thrown error, never a silent downgrade to a weaker one.
Methods
Section titled “Methods”describe()
Section titled “describe()”describe():
BashExecutorDescription
Defined in: bash/executor.ts:35
Reports this executor’s actual, resolved configuration — for the describeEnvironment
tool (createBashToolProvider/createWorkspaceToolProvider) to give the model situational
awareness of what it can and can’t do, instead of it only discovering limits by hitting a
denial. Every concrete executor already holds this in closure; describe() just returns
it, no new computation.
Returns
Section titled “Returns”run(
argv,options):AsyncGenerator<BashExecutorUpdate,void,void>
Defined in: bash/executor.ts:23
Yields zero or more { done: false, ... } progress updates while the command is still
running, then exactly one { done: true, ... } final result. An executor that doesn’t
stream progress can just yield the final result alone — both shapes satisfy the same
AsyncGenerator, so a caller (e.g. createBashTool) doesn’t need to know which.
argv is spawned as-is — no shell. A caller that wants a shell (the model-facing
bash tool) passes ["/bin/bash", "-c", command]. Empty argv is an invariant break
(AdlError("INIT_FAILED")), not a no-op.
This return type is exactly what the AI SDK’s tool execute accepts for a
streaming tool (AsyncIterable<OUTPUT> — see ai’s ToolExecuteFunction): every
yielded value becomes a preliminary tool-result, and the last one is re-emitted as the
final one. createBashTool forwards this generator directly with no wrapping.
Parameters
Section titled “Parameters”readonly string[]
options
Section titled “options”Returns
Section titled “Returns”AsyncGenerator<BashExecutorUpdate, void, void>