Run agents on CoreWeave sandboxes

Give your agent a workspace where it can edit code, run tests, and save results on CoreWeave. This overview helps you choose an integration and configure the environment for longer sessions, subagents, and tool execution.

CoreWeave Serverless sandboxes are in public preview.

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:

Guide	Agent loop runs in	You interact through	Use it to
Claude Code CLI	The sandbox	An attached terminal	Work interactively on a repository without running the agent’s commands on your laptop.
Claude Managed Agents	Anthropic’s managed service	The Managed Agents API	Connect a self-hosted worker to a managed agent session.
Devin Outposts	Devin Cloud	Devin Cloud	Run Devin’s commands in a sandbox through an outpost worker.

The CLI example starts an interactive agent in a workspace you manage. 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. Each integration guide includes a quick-start path where the tool supports that workflow, plus direct setup with the Sandbox SDK. You can use either path independently. Follow the installation instructions, then choose an integration guide. These guides use a W&B API key for sandbox access. Authenticate to the agent provider separately. For other sandbox credentials, see Choose a credential. The SANDBOX_USER Identity and Access Management (IAM) action applies only to CoreWeave API access tokens, not W&B keys.

export WANDB_API_KEY="[WANDB-API-KEY]"
unset CWSANDBOX_API_KEY

Unsetting CWSANDBOX_API_KEY makes cws-agent select W&B authentication. 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.

Choose where sandboxes run

Serverless placement uses capacity CoreWeave operates. It’s the starting point in these guides. Use CoreWeave Kubernetes Service (CKS) placement when you need your own cluster placement and sandbox policy. Your administrator deploys the runner and configures the network and resource constraints. Agents require outbound access to their provider and any package or source hosts they use.

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. Serverless sandboxes default to a 10-minute lifetime when you omit max_lifetime_seconds. A CKS runner can supply a different policy default. Set the lifetime explicitly at creation, allowing time for setup and the task.

Set a serverless sandbox lifetime

After completing SDK installation and authentication, use this creation request for a sandbox with a 24-hour lifetime. The Python client requires the wandb extra. TypeScript uses the W&B client entry point:

Python
TypeScript

from cwsandbox import AuthStrategy, Sandbox

sandbox = Sandbox.run(
    auth=AuthStrategy.WANDB,
    placement_mode="serverless",
    container_image="python:3.12-slim",
    resources={"cpu": "4", "memory": "8Gi"},
    max_lifetime_seconds=24 * 60 * 60,
)
print(f"Sandbox ID: {sandbox.sandbox_id}")

import { createSandboxClientFromEnv } from "@coreweave/cwsandbox/wandb";

const client = createSandboxClientFromEnv();
const sandbox = await client.create({
  containerImage: "python:3.12-slim",
  resources: { cpu: "4", memory: "8Gi" },
  maxLifetimeSeconds: 24 * 60 * 60,
  waitUntilRunning: false,
});
console.log(`Sandbox ID: ${sandbox.sandboxId}`);

Save the printed ID to reconnect with the SDK. The ID confirms that creation was accepted, not that startup has finished. Follow an integration guide to wait for readiness, install, and start your agent, or supply an image with your tools already installed. Both standalone creation calls leave the sandbox running after the script exits. TypeScript’s 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:

cws-agent launch [SANDBOX-NAME] --lifetime 24h --cpu 4 --memory 8Gi --permission-mode native

To keep an interactive agent running when you close your terminal, run it inside a terminal multiplexer. See the tmux guide for detach and reconnect instructions. A detached session can still wait for an approval or login.

Configure CKS placement and policy

CKS placement requires a CoreWeave API access token and its SANDBOX_USER IAM action. W&B keys cover the serverless examples in this guide. Follow CKS authentication and setup. In Python, use auth=AuthStrategy.COREWEAVE_API_KEY, the same max_lifetime_seconds field, placement_mode="cks", and runner_ids=["[RUNNER-ID]"]. Replace [RUNNER-ID] with your cluster’s runner ID. In TypeScript, use the @coreweave/cwsandbox/node entry point with CWSANDBOX_API_KEY, set runnerIds: ["[RUNNER-ID]"] to select CKS, and use maxLifetimeSeconds for the lifetime. The runner must have a configured policy. The resource ceilings must accommodate the creation request. Retain other constraints and any higher ceilings needed by existing workloads. Policy writes replace the entire document, and changes apply to newly created sandboxes. To make 24 hours the default for requests that omit a lifetime, have the administrator edit the existing policy with the CoreWeave Intelligent CLI:

cwic sandbox runner policy edit [RUNNER-ID]

Merge these fields into the existing constraints object. This is a policy fragment, not a complete replacement document:

{
  "constraints": {
    "lifecycle": {
      "defaultLifetimeSeconds": 86400
    },
    "resources": {
      "maxCpu": "4",
      "maxMemory": "8Gi"
    }
  }
}

An explicit request lifetime takes precedence over defaultLifetimeSeconds. The platform maximum is 30 days. The policy has no maxLifetimeSeconds field to raise. To permit provider connections, also configure network egress: allowedEgress permits requested destinations, while defaultEgress supplies access when the request omits egress rules. An allowance alone doesn’t grant access.

Keep execution time and conversation state separate

A tool command’s timeout_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:

Use separate subagents to inspect the API and its tests in parallel.
Have each report relevant files and findings without editing anything.
Combine their findings into an implementation plan.

To define a reusable specialist, create this file in the sandbox’s project before starting Claude Code:

.claude/agents/test-reader.md

---
name: test-reader
description: Inspect tests and report coverage gaps without editing files.
tools: Read, Grep, Glob
---
Find tests relevant to the requested change. Summarize coverage gaps and
cite the test files. Do not modify files.

Ask Claude to use 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_image at 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 Claude Code CLI session managed by cws-agent, preview local configuration and import selected items into its sandbox:
cws-agent config preview [SANDBOX-NAME] --verbose cws-agent config sync [SANDBOX-NAME]
Configuration import isn’t available for Claude Managed Agents workers. The sync command 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.

Tool discovery, context compaction, and decisions about which tools to call remain harness features. CoreWeave runs the commands and stores their files.

Keep results and stop compute

Exiting an agent or ending a provider session doesn’t necessarily stop its sandbox. Follow the cleanup steps in the integration guide, and set a lifetime when you create compute. Copy results out before stopping, push changes to your repository, or configure a snapshot volume to use file system snapshots. Snapshots preserve files, not running processes. Provider conversation history has its own lifecycle.

​Interactive coding agents and autonomous agents

​Choose an integration

​Build your own integration

​Get started with cws-agent

​Choose where sandboxes run

​Run longer sessions

​Set a serverless sandbox lifetime

​Configure CKS placement and policy

​Keep execution time and conversation state separate

​Delegate work to subagents

​Use tools efficiently

​Keep results and stop compute

Interactive coding agents and autonomous agents

Choose an integration

Build your own integration

Get started with cws-agent

Choose where sandboxes run

Run longer sessions

Set a serverless sandbox lifetime

Configure CKS placement and policy

Keep execution time and conversation state separate

Delegate work to subagents

Use tools efficiently

Keep results and stop compute