Interactive coding agents and autonomous agents
With an interactive coding agent, you work alongside the agent: ask questions, review edits, and approve actions through a terminal, browser, or mobile app. For example, use Claude Code to investigate a failing test while you guide the changes. With an autonomous agent, you delegate a task and collect results later. For example, assign a repository migration, let the agent run tests and revise its changes, then review the result. Configure its permissions, credentials, and stopping conditions before starting work. It can still pause for your input when needed. These are ways of working, not separate sandbox types. A coding harness can support both. The harness manages the agent loop, model context, tool selection, and delegation. CoreWeave supplies the compute and filesystem where tools run. A longer sandbox lifetime gives the agent more execution time, but conversation compaction and task recovery depend on the harness.Choose an integration
The following integrations execute commands in a CoreWeave sandbox. The location of the agent loop and the interface you use differ:
The Claude Code and Pi examples start an interactive agent in a workspace you manage. The Cursor examples support interactive work and unattended tasks. The Muse Code example runs a task without an interactive terminal. The Managed Agents and Devin Outposts examples start workers that reuse a sandbox across queued sessions. Ending one provider session doesn’t stop that worker sandbox.
Model inference remains with the provider configured for your agent. Running tools in a sandbox doesn’t prevent the agent from sending prompts, file contents, or tool output to that provider. Review its data-handling requirements before connecting your workspace.
Build your own integration
Use the Sandbox SDK to create an environment, execute tool calls, collect results, and stop compute from your own harness. Start with command execution, file operations, and cleanup patterns.Get started with cws-agent
cws-agent automates sandbox creation, agent installation, and workspace management. Most integration guides include a quick-start path that uses it. Other guides set up the sandbox directly with the Sandbox SDK. Where a guide documents both, you can use either path independently.
インストール手順に従ってインストールしたら、インテグレーションガイドを選択してください。各ガイドの cws-agent のサンプルでは、サンドボックスへのアクセスに W&B APIキーを使用します。エージェントのプロバイダーへの認証は別途行ってください。
CWSANDBOX_API_KEY の設定を解除すると、cws-agent は W&B 認証を選択します。この変数を設定すると、cws-agent は CoreWeave 認証を選択します。
Sandbox SDK のサンプルはコード内で認証情報を選択するため、各ガイドに記載されている認証情報の手順に従ってください。たとえば OpenAI Agents API のレシピでは、デフォルトで CWSANDBOX_API_KEY が必要です。W&B キーが選択されるのは、--sandbox-auth wandb を渡した場合のみです。この変数の設定を解除すると、デフォルト設定での実行は失敗します。
For configuration imports, parallel sessions, and saving or restoring workspaces, see the cws-agent documentation. You don’t need cws-agent to integrate a harness directly.
Run longer sessions
The lifetime is a wall-clock limit, including startup, and can’t be extended after creation. It doesn’t guarantee that the agent finishes or recovers from interruptions. サーバーレスサンドボックスでは、max_lifetime_seconds を省略すると有効期間がデフォルトの 10 分になります。セットアップとタスクの実行に必要な時間を見込んだうえで、作成時に有効期間を明示的に設定してください。
Set a serverless sandbox lifetime
SDK のインストールと認証が完了したら、次の作成リクエストを使用して、有効期間が 24 時間のサンドボックスを作成します。Python クライアントではwandb extra が必要です。TypeScript では W&B クライアントのエントリポイントを使用します。
- Python
- TypeScript
withSandbox() stops it when its callback finishes. A with Sandbox.run(...) block stops it when the block exits. Sandboxes created through an SDK Session stop when that session closes, including during process-exit cleanup.
With cws-agent installed and authenticated, set the same lifetime when launching Claude Code. Replace [SANDBOX-NAME] with a cws-agent session name for your workspace. Use 1 to 40 lowercase letters, digits, or hyphens, starting with a letter or digit:
tmux guide for detach and reconnect instructions. A detached session can still wait for an approval or login.
Keep execution time and conversation state separate
A tool command’stimeout_seconds is separate from the sandbox lifetime. Give long builds and tests an appropriate command timeout. For unattended tasks, use the harness’s supported background execution and recovery features, and save intermediate results. See command timeouts and sandbox lifecycle.
Delegate work to subagents
Configure subagents in your harness. No sandbox creation flag enables subagents. For example, Claude Code includes built-in subagents. In an interactive session, ask it to split independent investigations:.claude/agents/test-reader.md
test-reader for a specific task. Delegation is available by default. A permissions.deny rule for the parent agent’s Agent tool blocks delegation. For tool permissions and other options, see Claude Code subagent configuration.
Subagents using one sandbox share its compute and filesystem. Size CPU and memory for concurrent tools, and avoid simultaneous edits to the same files. When workers need independent credentials or isolation, use separate sandboxes.
For separate coding tasks, cws-agent parallel sessions provide separate Git worktrees within one sandbox. These are independent sessions, not harness-managed subagents or separate security boundaries.
Use tools efficiently
Prepare the environment so agents can spend time on the task:-
Install recurring dependencies in the image. Pass a prepared
container_imageat creation to avoid installing the same test tools and runtimes for every session. See sandbox configuration. -
Select the tools the task needs. Configure skills and Model Context Protocol (MCP) servers in the harness. For a CLI session managed by
cws-agent, preview local configuration and import selected items into its sandbox:Configuration import isn’t available for Claude Managed Agents workers. Thesynccommand prompts for selections and confirmation. Restart the agent to load the changes. Install required executables in the sandbox and replace laptop-only paths. See skills and MCP imports. - Return focused results. Have tools filter or summarize data in the sandbox before returning it to the model. For example, save full test output to a file and return failed test names and a short failure summary. Keep the file available for follow-up inspection.
- Parallelize independent operations. When resources allow, run independent checks concurrently. Wait for prerequisites before dependent steps. The SDK execution guide shows how to start commands and collect results.