CWSANDBOX_API_KEY. For Forge API key authentication, see Get started. For CKS requirements, see Placement modes.
This guide covers resource management and cleanup strategies for sandboxes. Reliable cleanup prevents orphaned sandboxes after a script exits, which keeps costs predictable and avoids unintentional compute resource usage. The patterns here apply to scripts that create one or many sandboxes, with or without an explicit session.
Automatic cleanup
Automatic cleanup ties a sandbox’s lifetime to a Python construct (a context manager, or a session that the SDK closes when the process exits) so the SDK releases resources without explicitstop() calls. A sandbox you start with Sandbox.run() outside a session or context manager keeps running after your script exits, until its main command exits, you stop it, or its maximum lifetime expires.
Context managers (recommended)
Context managers are the recommended pattern because they guarantee cleanup even if the enclosed code raises an exception. The SDK stops sandboxes when the context exits:Global cleanup handlers
The SDK registers cleanup handlers that stop sandboxes owned by registered sessions when the process terminates. Standalone sandboxes created outside a session or context manager require explicit cleanup:
The SDK installs these handlers when your code first creates a sandbox. The
SIGINT and SIGTERM handlers install only from Python’s main thread. If your application manages its own signals, call cwsandbox.disable_signal_handlers() or set CWSANDBOX_DISABLE_SIGNAL_HANDLERS=1 before you create the first sandbox. The atexit handler still runs, but stopping sandboxes when a signal arrives becomes your application’s job.
Manual cleanup
Use manual cleanup when you need explicit control over when to release a sandbox or session. Manual cleanup lets you pass stop options or coordinate cleanup across long-running code.Sandbox stop()
Session close()
Batch cleanup
Orphan management
Orphans are sandboxes left running unintentionally after the process that created them exits. A standalone sandbox that you keep running on purpose isn’t an orphan, but it becomes one if you lose track of it. The following sections describe how to make orphans easy to find, how to query for them, and how to bring them back under managed cleanup.Tagging for discovery
For sandboxes in sessions and context managers, the SDK’s automatic cleanup prevents most orphans. Those sandboxes can still keep running after forced shutdowns (kill -9) or network failures. The cleanup handlers never stop a standalone sandbox, so it becomes an orphan if you forget to stop it. Use tags to make any orphans discoverable later.
- Project or application name (
my-project) - Job or run identifier (
batch-job-123,run-2024-01-15) - Environment (
dev,staging,prod)
Find orphaned sandboxes
Query by tags to find sandboxes from previous runs:Session adoption
Adopting an orphan attaches it to a session so the session governs its lifetime. The orphan then receives the same automatic cleanup guarantees as newly created sandboxes.session.list() adds the session’s default tags to your filter, so it finds only sandboxes that carry them. To search without the session’s tags, use Sandbox.list() and adopt each result, as in the Sessions guide: