Skip to main content
Every FissionPlane sandbox exposes a command API through its data-plane agent. You can run a one-shot command and wait for its result, start a long-lived background process and stream its output in real time, send stdin, list all supervised processes, or signal any of them by PID. This page walks through each of those patterns in TypeScript, Python, and Rust.

Blocking commands

Use commands.run() when you want to execute a command and wait for it to finish before continuing. The call blocks until the process exits and returns the full exit_code, stdout, and stderr. An optional truncated flag indicates whether the output was cut short by the platform. Pass timeoutSeconds (TypeScript) or timeout_seconds (Python/Rust) to set a maximum wall-clock limit for the command.
When the command timeout expires, FissionPlane terminates the process and throws a command-timeout error. Catch it with CommandTimeoutError (TypeScript/Python) or match on fissionplane::Error (Rust) to handle timeouts gracefully in your application logic.

Background processes

Use commands.start() when you need to keep the process running while streaming its output or sending it input over time. Optionally request a PTY — pass pty: { cols, rows } to allocate a pseudo-terminal with the specified dimensions. Call attach() (or process.attach(0) in Rust) on the returned handle to get an iterable stream of events.

Sending stdin

After calling attach(), send input to the process using sendInput() / send_input(). This is especially useful for interactive shells and REPL-based workflows.

Listing processes

Call commands.listProcesses() / list_processes() / Commands::list_processes() to get a snapshot of all processes currently supervised by the data-plane agent in this sandbox.

Killing a process

Send a signal to a specific process by PID using commands.kill() / Commands::kill(). Pass the PID and a signal name such as "SIGTERM" or "SIGKILL".
Pass an idempotencyKey (TypeScript) or idempotency_key (Python/Rust) when creating your sandbox so that retried creation attempts return the same sandbox. This is especially useful in job-runner patterns where your orchestrator may restart a task before it confirms the sandbox was created.