/v1/bash is a subprocess pipe-based command execution service for programmatic and agent-friendly workflows. It is different from the PTY-based Shell Terminal: Bash Pipe keeps stdout and stderr separate and supports incremental output reads with offsets.
/v1/shell | /v1/bash | |
|---|---|---|
| Backend | Terminal / PTY | subprocess pipe |
| Best for | Interactive terminals, WebSocket UI, human takeover | Agent tool calls, short commands, long command polling |
| Output | One combined output field | Separate stdout and stderr |
| Read model | Terminal snapshots and waits | Incremental reads with offset / stderr_offset |
| stdin | Terminal input stream | Writes to the running process stdin pipe |
| Command identity | Session-level | Each command has a command_id |
Most tool calls can complete with a single exec request. status is the command lifecycle state; exit_code is the command success indicator.
Typical response shape:
Python:
TypeScript:
When a command is still running after timeout, /v1/bash/exec returns status: "running" and the command continues in the background. Use /v1/bash/output to read incremental output.
wait=false returns the currently available output immediately. wait=true long-polls until new output arrives, the command finishes, or wait_timeout expires. For agent polling, prefer wait=true to avoid unnecessary empty polling.
For services that do not exit on their own, use async_mode: true, read startup logs, and call /kill when done.
Read logs:
Stop the process:
/v1/bash/write writes to the stdin pipe of the running process. Use it for cat, prompt-driven scripts, REPLs, and similar programs. For line-buffered programs, include \n at the end of each line.
Some programs write prompts to stderr, including some REPLs and interactive commands. Consumers should inspect both stdout and stderr.
/v1/bash creates a new process for each exec. The same session_id preserves API-level state, such as the default working directory, but command-internal cd and export calls do not affect later requests.
Set the session default working directory with exec_dir:
Reuse the same session:
If later commands should continue in a directory, pass exec_dir again or update the API-level session default. Do not rely on cd inside a command.
Common POST /v1/bash/exec parameters:
| Parameter | Type | Description |
|---|---|---|
command | string | Shell command to execute |
session_id | string | Target session; auto-created when omitted |
exec_dir | string | Absolute working directory; updates the session default |
env | object | Extra environment variables for this command only |
async_mode | boolean | Return running immediately when true |
timeout | number | Soft timeout; returns running while the command continues in the background |
hard_timeout | number | Hard timeout; kills the process and returns timed_out |
max_output_length | number | Maximum inline stdout / stderr length for sync responses; default 50000, set 0 to disable truncation for the request |
Common POST /v1/bash/output parameters:
| Parameter | Type | Description |
|---|---|---|
session_id | string | Target session |
command_id | string | Optional target async command |
offset | number | stdout byte offset to read from |
stderr_offset | number | stderr byte offset to read from |
wait | boolean | Whether to long-poll for new output |
wait_timeout | number | Maximum wait time when wait=true |
HTTP success for /v1/bash means the request was accepted by the service. It does not mean the command itself succeeded. Recommended order:
success.data.status for the command lifecycle.status="completed", use exit_code for command success.POST /v1/bash/execPOST /v1/bash/outputPOST /v1/bash/writePOST /v1/bash/killGET /v1/bash/sessionsPOST /v1/bash/sessions/createPOST /v1/bash/sessions/{session_id}/close