Sandbox lifecycle

A managed Environment is owned by one Session. Its Sandbox identity stays fixed for the lifetime of that binding.

Provisioning

Rebyte records the Environment configuration and reserves its binding when a hosted Session is created. It does not allocate a Sandbox yet. The first environment tool, file operation, or environment-origin MCP operation enters a guard that creates and attaches the Session's Sandbox, then initializes packages, files, setup commands and Skills. Creating a saved Agent or merely sending a chat message does not allocate compute.

Retrieve the Session and its Environment to inspect state. The Environment resource is available at GET /v1/agents/environments/{environment_id}. Failed initialization is reported on the Session.

Persistence

Working files persist across Turns in the same Session. Sessions created from the same Agent have separate environments; using the same path in both does not share a file.

When a Sandbox pauses, later connection resumes the same Sandbox. Initialization and Skill installation do not repeat on resume. A connection error does not replace the environment or discard its files. Applications should surface the failure and retain the Session and Environment IDs for diagnosis.

Ending a Turn

Completion, failure, and cancellation end a Turn without deleting the Session. A Session whose initialization succeeded can accept subsequent input. Disconnecting from the event stream also leaves execution running.

Deliverables in /workspace/outputs are published as immutable Artifacts when a Turn completes. See Files and artifacts.

Deletion

Explicit Session deletion removes its Sandbox and stored Artifacts. Deleting one Session does not delete another Session's environment. Deleting a saved Agent does not remove the environments of existing Sessions.