Skip to main content
TypeScript, Rust, Python, and Go surface typed errors so you can match specific failure modes instead of parsing strings. TypeScript exposes a dedicated subclass per variant (use instanceof). Rust has an Error enum, and Python provides dedicated exception classes. Go provides an *Error value with an ErrorKind discriminator that you match via m.IsKind(err, kind) or errors.As. Ruby v0.7.4 adds typed subclasses of Microsandbox::Error with stable code strings; failures without a dedicated subclass still use the base class.

Matching errors

Spawn-time exec failures

exec() distinguishes between:
  • A program that ran and exited non-zero: the call returns an ExecOutput with a non-zero code. This is not an error in the SDK sense; it’s a normal result.
  • A program that never started: the binary doesn’t exist, isn’t executable, the working directory is unreachable, etc. The call returns or raises an SDK error.
Rust exposes a structured ExecFailed payload, and Go exposes the same detail on streaming execution events. Common failure kinds include NotFound (binary missing on PATH), PermissionDenied, NotExecutable, BadCwd, BadArgs, ResourceLimit, UserSetupFailed, OutOfMemory, PtySetupFailed, and Other.
The CLI maps these kinds to POSIX-style exit codes: 127 for NotFound, 126 for PermissionDenied and NotExecutable, and 1 otherwise.

Name conflicts

Creating a sandbox with a name that’s already in use (and without replace) surfaces a typed error. Branch on it to decide how to recover, such as resuming the existing sandbox or regenerating the name.
Use connect_or_create and its language-specific equivalents to reuse the existing sandbox without changing its configuration. Pass replace() / replace=True / replace: true / --replace / WithReplace() only when you intend to stop the existing sandbox and create a new one. See Naming conflicts for the grace-period setting.

When a sandbox object is stale

A Sandbox or SandboxHandle keeps the ID of the exact sandbox it represents. If that sandbox is removed and the name is reused, lifecycle methods refuse to act on the replacement and return a typed error.
Ruby does not yet expose a dedicated stale-identity subclass. Until it does, Microsandbox::Error with the stable was replaced message is the Ruby-specific contract; the operation still refuses to act on the replacement.

Stop observation timeouts

On Local, a graceful-stop timeout causes the SDK to force-kill the sandbox. On Cloud, the same timeout only limits how long the SDK waits: the accepted server-side stop is not cancelled and may still complete. Cloud reports this with SandboxStopTimedOutError in TypeScript and Python, Error::SandboxStopTimedOut in Rust, and ErrSandboxStopTimedOut in Go. Ruby currently raises Microsandbox::Error with a message explaining that the accepted stop may still complete. After a Cloud timeout, poll the sandbox status or call the wait-until-stopped method if you still need confirmation. Calling request_stop first is useful when the application wants to submit the stop and control its own observation deadline.

Sandbox start failures

When a sandbox process exits before the agent relay is ready, creation returns or raises an SDK error. Rust exposes a structured BootStart payload with the failure stage and underlying message.
The CLI prints the startup failure before any captured log output so the immediate cause stays visible.

Resource cleanup

Sandboxes hold compute resources, so release them when done. In TypeScript, prefer await using (Node 22+) which calls Sandbox.stop() automatically when the binding leaves scope. In Rust, Drop handles cleanup when the sandbox goes out of scope. In Go, pair every CreateSandbox with a defer that calls Stop + Close.