Skip to main content
execute_command(..., run_in_background=True) starts a shell command and returns a handle immediately, so dev servers, watchers, and long test suites don’t block the turn or get killed by the 30-second timeout.

Quick Start

1

Start

2

Poll Output

3

Stop


Which Mode Should I Use?


How It Works

The agent starts the process, polls a log file, and stops the process tree when done. The same safety checks apply as for foreground commands:

Configuration Options

execute_command (new parameter)

get_command_output(process_id, tail=200)

stop_command(process_id)

An unknown id returns {"success": False, "error": "No background command with process_id '...'"} from both functions.

Common Patterns

Start a server, then test it

Long test suite with periodic tailing

Watcher that outlives several turns


Platform Behaviour

An atexit hook stops any still-running background commands when the interpreter exits, so dev servers are not orphaned.

Deliberate Limits

Background commands are tracked only in-process on the ShellTools() instance.
  • A restart loses the process handle. The log file stays on disk, but the process is not re-adopted.
  • There is no shell_list tool to list running background commands.
  • There is no push notification on completion — the agent polls get_command_output.
  • Background commands are not surfaced in the jobs CLI.

Best Practices

The exit hook reaps leftovers, but relying on it is bad hygiene. Write the matching stop_command(process_id) into the agent’s instructions for every background start.
Use get_command_output(process_id, tail=20). The read is bounded to 64 KB, and a small tail keeps the agent’s context small.
Once status is "exited", exit_code is the authoritative result. Output text can look healthy while the process failed.

Shell Tools

All shell functions for agents

Tool Approval

Approval gates for critical commands

Tool Output Spill

Large foreground output saved to artifacts

Concurrency

Run work in parallel safely