Buffered exec
200 — check exit_code in the body.
sandbox_exec tool runs a buffered command the same way.
The request body (DirectExecRequest) extends the common command shape:
string[]
required
Argv to run. At least one element.
object
Environment variables to set.
string
Working directory.
integer
Timeout in seconds, 1–300.
string
Base64-encoded stdin to feed the process.
string
utf8 or base64, controlling how stdout/stderr are encoded in the response.DirectExecResponse), always 200:
integer
required
The process’s exit code.
boolean
required
Whether the process was terminated by a signal.
integer
The signal number, if
signaled is true.boolean
required
Whether
timeout_s was reached before the process exited.string
required
Captured stdout, encoded per
output_encoding.string
required
Captured stderr, encoded per
output_encoding.boolean
required
Whether
stdout was cut short.boolean
required
Whether
stderr was cut short.string
required
utf8 or base64, matching the request (or the server default).TTY exec
TTYStartRequest. See WebSockets for how the upgrade, START frame, and admission-at-START model work — that mechanism isn’t repeated here.
There’s no raw cURL example for this mode — it’s a WebSocket upgrade, not a single request/response — but the CLI and every SDK reach it directly: the CLI’s --tty flag and each SDK’s tty: true option both drive this exact endpoint, not a separate mechanism.
tty: true (plus matching cols/rows) to get terminal semantics on the stream instead.
There’s no MCP tool for TTY exec — MCP tools notes the WebSocket exec and session attach endpoints don’t fit a request/response tool call; sandbox_exec is buffered-only.