sandbox

Why supports command stdin (, , ), but the mock didn't, so code using it couldn't be tested without a real sandbox. The mock runs commands through just-bash, which takes stdin up front. So writes are buffered and the command runs once stdin is closed. It can't respond to input as it arrives, which the README notes as a limitation. Validation Offsets, resends and closes return the same status codes as the real API: an offset past the bytes written is 409, new bytes after close are 400, and writes to an exited command are 404. Kill, session stop and end a command still waiting for stdin. rejects on abort instead of hanging. New compat tests pass against the mock. The real-sandbox variants need integration credentials and weren't run locally.

Every sandbox now supports stdin write offsets, so the SDK no longer needs the fallbacks for ones that don't: always sends an offset, instead of switching to unsafe writes when a response lacks . If it can't learn the current offset, it fails before writing rather than assuming 0. A 504 no longer triggers an extra empty request to find the bytes written; the timeout response already includes them.

The Sandbox skill covers sandbox forks but leaves agents without a path for persistent files shared across runs. Add a short choice between and , followed by an example that seeds a drive, forks it, and mounts the worker's writable copy. The example follows the GA Drives guide's initialization rule: write to a read-write mount before forking. It also keeps the sandbox in the drive's region and stops each sandbox after writing. Concurrent readers use ; each mount sees the files as they stood when that sandbox mounted it. The docs say many readers can mount snapshots but give no numeric reader limit. Checked the example's APIs and behavior against the live Drives guide and SDK reference on October 18. passed. A live run with Sandbox credentials was not available in this worktree.