FAQ & troubleshooting
The questions we actually get, and the footguns worth knowing before they find you. If your question isn't here, ask us - good questions end up on this page.
Why can't my sandbox reach the internet?
Because the default network mode is off - the VM has no network device at all. Create with network="restricted" for the curated allowlist (package registries, GitHub, major model APIs) or network="open" for full egress. See Networking & egress.
pip / npm works in restricted mode, but my code's HTTP call fails
Restricted egress is an HTTPS forward proxy. Proxy-aware tools (pip, npm, curl, standard HTTP libraries - HTTP_PROXY and HTTPS_PROXY are pre-set) work as-is, but raw sockets and direct DNS do not resolve, and only allowlisted hosts are reachable. If you need another host, pass your own allow_domains - and note it replaces the default list, so keep the registries you still need on it.
My custom allowlist broke pip install
allow_domains replaces the default set rather than extending it. Start from default_egress_domains (returned by the limits API) and add your hosts to that list.
Where did my files go after terminate?
/workspace and /tmp are RAM-backed scratch - gone the moment the sandbox terminates, by design. Anything you want to keep goes on a volume under /persist, or read it out with files.read before terminating.
Why did my paused sandbox disappear?
Paused snapshots have a retention window: 7 days on the free tier, 30 days with a card on file, no expiry on enterprise. The deadline is returned as paused_expires_at, and every resume restarts the clock. If your agent parks sessions for days, check that field and resume in time.
get_host raises / returns 409
Preview URLs need two things: a networked sandbox (restricted or open - an off sandbox has no port to expose) and a card on file. Both requirements are checked at call time.
My exec timed out - is the sandbox dead?
No. ExecTimeout kills the command, not the sandbox - it stays alive so you can read partial output, grab logs, and decide what to do next. The sandbox's own lifetime clock is separate.
I stopped reading exec_stream early and things got weird
Breaking out of a stream leaves the in-sandbox process running until its own timeout fires. Iterate streams to completion; if you need to abandon a command, follow up with a kill (for example pkill via a second exec).
Do runtime installs survive? apt-get, npm -g?
They work, but they don't survive. The root filesystem is a writable per-sandbox overlay, so apt-get install (on debian-12), npm install -g, and writes anywhere on the filesystem all work at run time - and all vanish when the sandbox terminates, exactly like /workspace. If every run installs the same packages, bake them into a custom template once: you skip the install time on every boot and the image is captured permanently.
How many sandboxes can I run in parallel?
Concurrency is a RAM budget, not a count: your live sandboxes' combined memory must fit your tier's max_concurrent_memory_mb. Small sandboxes pack more parallelism than large ones, and paused sandboxes don't count. Check Limits & quotas.
Does pausing stop billing?
Pausing stops the per-second compute meter. The snapshot itself meters as storage (GB-month), like volumes and templates - small compared to compute, but not zero.
Can I extend a running sandbox's lifetime?
Not currently - the timeout is fixed at create, so create with the lifetime the task needs (up to your tier's ceiling). For long-lived sessions, pause between turns and resume: resuming restarts the lifetime clock.
Is my data used to train anything?
No. Sandbox contents are your data; we run them, meter them, and delete them per the lifecycle on the data residency page.