/sandbox-migrate-to-next
Use when porting a Cloudflare Sandbox app from stable @cloudflare/sandbox to @cloudflare/sandbox@next (Sandbox SDK 1.0 preview), or when the user asks to migrate or upgrade to Sandbox 1.0 / @next. Not for day-to-day stable work (sandbox-stable) or new @next apps (sandbox-next).
$ npx -y skills add cloudflare/skills --skill sandbox-migrate-to-next --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/sandbox-migrate-to-next
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when porting a Cloudflare Sandbox app from stable @cloudflare/sandbox to @cloudflare/sandbox@next (Sandbox SDK 1.0 preview), or when the user asks to migrate or upgrade to Sandbox 1.0 / @next. Not for day-to-day stable work (sandbox-stable) or new @next apps (sandbox-next).
SKILL.md
sandbox-migrate-to-next.SKILL.mdname: sandbox-migrate-to-next
description: Use when porting a Cloudflare Sandbox app from stable @cloudflare/sandbox to @cloudflare/sandbox@next (Sandbox SDK 1.0 preview), or when the user asks to migrate or upgrade to Sandbox 1.0 / @next. Not for day-to-day stable work (sandbox-stable) or new @next apps (sandbox-next).
Migrate stable → Sandbox SDK 1.0 preview (`@next`)
**Perform** the port. Follow the steps in order. Depth lives in docs—fetch the linked page when a step needs detail.
Human guide: [Migrate](https://developers.cloudflare.com/sandbox/1-0-preview/migrate/) · [1.0 preview](https://developers.cloudflare.com/sandbox/1-0-preview/)
**New projects** should start on `@next` (**`sandbox-next`**), not this skill. **Day-to-day stable work** → **`sandbox-stable`**. Deprecated-API cleanup **without** moving to `@next` → [2026 deprecation guide](https://developers.cloudflare.com/sandbox/guides/2026-deprecation/) first if needed.
Existing apps should migrate **when you can**, so you are ready when 1.0 becomes the stable release. Do **not** force production cutover without the user agreeing.
**Prefer installed `@next` types and the migrate doc over memory.**
Workflow
1. **Review** hard rules and the replacement map 2. **Audit** the codebase; list hits and target shapes 3. **Clarify** with the user (cutover, bridge, Python image, unclear sites) 4. **Upgrade** package, image, and code 5. **Validate**
Stop after any step that needs a user decision.
Hard rules
- Worker package and container image must be the **same** `@next` line.
- Production cutover uses **immediate** container rollout. Stable and `@next` control protocols are incompatible both ways; gradual rollout leaves a broken mixed window. In-flight container work can stop.
- After cutover, `await sandbox.exec(...)` means process **started**, not command **finished**.
- Argv is as-is (no implicit shell). Shell syntax needs an explicit shell binary.
- Process handles have **no stdin** → terminals for interactive input.
- Observation `timeout` / `AbortSignal` cancel the **wait only**, not the process.
- No single retry loop for every error.
- Do not invent APIs (`gitCheckout` on core, process stdin, string-exec completion helper).
- Self-deployed bridge stays on **stable** (not part of the preview line yet).
Replacement map
| Stable | `@next` | | ------ | ------- | | `SANDBOX_TRANSPORT` / `transport` / `setTransport` | Remove — RPC only | | `await sandbox.exec("cmd")` → buffered result | `await sandbox.exec(argv)` → handle, then `output` / waits | | `execStream` / `startProcess` | Same handle: `logs`, `waitFor*`, `kill` | | Default / named sessions | Gone — `cwd`/`env` per launch, or one shell script | | `sandbox.terminal(request)` / session terminal | `createTerminal` + `terminal.connect(request)` | | xterm `sessionId` | `terminalId` | | Interpreter methods on `Sandbox` | `withInterpreter` → `sandbox.interpreter.*` | | `gitCheckout` | argv `git` via `exec` | | String kill signals | Numeric only | | Files, mounts, backups, ports, tunnels, `proxyToSandbox` | Mostly unchanged (ignore session/transport bits on stable pages) |
Depth: [Migrate](https://developers.cloudflare.com/sandbox/1-0-preview/migrate/) · after port, day-to-day → **`sandbox-next`**
Audit
rg 'SANDBOX_TRANSPORT|transport:|setTransport|enableDefaultSession|createSession|getSession|deleteSession|execStream\(|startProcess\(|killProcess\(|sandbox\.terminal\(|sessionId|gitCheckout\(|SandboxTransport|ExecutionSession'
Also: string `exec(`, `cd` then a later `exec`, bare `createCodeContext` / `runCode` on `Sandbox`.
Clarify (ask when needed)
- OK to cut production with `--containers-rollout=immediate` (live processes/terminals/streams may stop)?
- Self-deployed bridge? Leave on stable.
- Python interpreter → **`-python`** image variant?
- Call sites not covered by the map?
Upgrade
Package and image
npm install @cloudflare/sandbox@next
FROM cloudflare/sandbox:next
# Python: cloudflare/sandbox:next-python
Same prerelease tag on Worker and image when not on floating `next`.
Code by area
Apply replacements from the map. For each area, implement from the doc—not from stable habits:
| Area | Doc | | ---- | --- | | Commands / handles / waits | [Processes](https://developers.cloudflare.com/sandbox/1-0-preview/processes/) · [Processes API](https://developers.cloudflare.com/sandbox/1-0-preview/api/processes/) | | `cwd` / `env` / secrets | [Environment](https://developers.cloudflare.com/sandbox/1-0-preview/environment/) · [Outbound traffic](https://developers.cloudflare.com/sandbox/guides/outbound-traffic/) | | Drop sessions | [Migrate](https://developers.cloudflare.com/sandbox/1-0-preview/migrate/) · [Lifecycle](https://developers.cloudflare.com/sandbox/1-0-preview/lifecycle/) | | Terminals | [Terminals](https://developers.cloudflare.com/sandbox/1-0-preview/terminals/) | | Interpreter | [Interpreter](https://developers.cloudflare.com/sandbox/1-0-preview/interpreter/) | | Errors | [Errors](https://developers.cloudflare.com/sandbox/1-0-preview/errors/) | | Durable job across requests | [Process execution — lifetime / durability](https://developers.cloudflare.com/sandbox/1-0-preview/processes/) |
**Commands (shape):**
// Before (stable)
const result = await sandbox.exec("npm test");
// After (@next)
const process = await sandbox.exec(["/bin/bash", "-lc", "npm test"]);
const result = await process.output({ encoding: "utf8" });const server = await sandbox.exec(["/bin/bash", "-lc", "npm run dev"], {
cwd: "/workspace/app",
});
await server.waitForPort(3000, { timeout: 60_000 });
await server.kill(); // numeric; default 15**Terminals (shape):**
const terminal = await sandbox.createTerminal({ command: ["bash"], cwd: "/workspace" });
const t = await sandbox.getTerminal(terminal.id);
if (!t) return new Response("terminal gone", {Read more
name: sandbox-migrate-to-next description: Use when porting a Cloudflare Sandbox app from stable @cloudflare/sandbox to @cloudflare/sandbox@next (Sandbox SDK 1.0 preview), or when the user asks to migrate or upgrade to Sandbox 1.0 / @next. Not for day-to-day stable work (sandbox-stable) or new @next apps (sandbox-next).
Migrate stable → Sandbox SDK 1.0 preview (`@next`)
**Perform** the port. Follow the steps in order. Depth lives in docs—fetch the linked page when a step needs detail.
Human guide: [Migrate](https://developers.cloudflare.com/sandbox/1-0-preview/migrate/) · [1.0 preview](https://developers.cloudflare.com/sandbox/1-0-preview/)
**New projects** should start on `@next` (**`sandbox-next`**), not this skill. **Day-to-day stable work** → **`sandbox-stable`**. Deprecated-API cleanup **without** moving to `@next` → [2026 deprecation guide](https://developers.cloudflare.com/sandbox/guides/2026-deprecation/) first if needed.
Existing apps should migrate **when you can**, so you are ready when 1.0 becomes the stable release. Do **not** force production cutover without the user agreeing.
**Prefer installed `@next` types and the migrate doc over memory.**
Workflow
1. **Review** hard rules and the replacement map 2. **Audit** the codebase; list hits and target shapes 3. **Clarify** with the user (cutover, bridge, Python image, unclear sites) 4. **Upgrade** package, image, and code 5. **Validate**
Stop after any step that needs a user decision.
Hard rules
- Worker package and container image must be the **same** `@next` line.
- Production cutover uses **immediate** container rollout. Stable and `@next` control protocols are incompatible both ways; gradual rollout leaves a broken mixed window. In-flight container work can stop.
- After cutover, `await sandbox.exec(...)` means process **started**, not command **finished**.
- Argv is as-is (no implicit shell). Shell syntax needs an explicit shell binary.
- Process handles have **no stdin** → terminals for interactive input.
- Observation `timeout` / `AbortSignal` cancel the **wait only**, not the process.
- No single retry loop for every error.
- Do not invent APIs (`gitCheckout` on core, process stdin, string-exec completion helper).
- Self-deployed bridge stays on **stable** (not part of the preview line yet).
Replacement map
| Stable | `@next` | | ------ | ------- | | `SANDBOX_TRANSPORT` / `transport` / `setTransport` | Remove — RPC only | | `await sandbox.exec("cmd")` → buffered result | `await sandbox.exec(argv)` → handle, then `output` / waits | | `execStream` / `startProcess` | Same handle: `logs`, `waitFor*`, `kill` | | Default / named sessions | Gone — `cwd`/`env` per launch, or one shell script | | `sandbox.terminal(request)` / session terminal | `createTerminal` + `terminal.connect(request)` | | xterm `sessionId` | `terminalId` | | Interpreter methods on `Sandbox` | `withInterpreter` → `sandbox.interpreter.*` | | `gitCheckout` | argv `git` via `exec` | | String kill signals | Numeric only | | Files, mounts, backups, ports, tunnels, `proxyToSandbox` | Mostly unchanged (ignore session/transport bits on stable pages) |
Depth: [Migrate](https://developers.cloudflare.com/sandbox/1-0-preview/migrate/) · after port, day-to-day → **`sandbox-next`**
Audit
rg 'SANDBOX_TRANSPORT|transport:|setTransport|enableDefaultSession|createSession|getSession|deleteSession|execStream\(|startProcess\(|killProcess\(|sandbox\.terminal\(|sessionId|gitCheckout\(|SandboxTransport|ExecutionSession'
Also: string `exec(`, `cd` then a later `exec`, bare `createCodeContext` / `runCode` on `Sandbox`.
Clarify (ask when needed)
- OK to cut production with `--containers-rollout=immediate` (live processes/terminals/streams may stop)?
- Self-deployed bridge? Leave on stable.
- Python interpreter → **`-python`** image variant?
- Call sites not covered by the map?
Upgrade
Package and image
npm install @cloudflare/sandbox@next
FROM cloudflare/sandbox:next # Python: cloudflare/sandbox:next-python
Same prerelease tag on Worker and image when not on floating `next`.
Code by area
Apply replacements from the map. For each area, implement from the doc—not from stable habits:
| Area | Doc | | ---- | --- | | Commands / handles / waits | [Processes](https://developers.cloudflare.com/sandbox/1-0-preview/processes/) · [Processes API](https://developers.cloudflare.com/sandbox/1-0-preview/api/processes/) | | `cwd` / `env` / secrets | [Environment](https://developers.cloudflare.com/sandbox/1-0-preview/environment/) · [Outbound traffic](https://developers.cloudflare.com/sandbox/guides/outbound-traffic/) | | Drop sessions | [Migrate](https://developers.cloudflare.com/sandbox/1-0-preview/migrate/) · [Lifecycle](https://developers.cloudflare.com/sandbox/1-0-preview/lifecycle/) | | Terminals | [Terminals](https://developers.cloudflare.com/sandbox/1-0-preview/terminals/) | | Interpreter | [Interpreter](https://developers.cloudflare.com/sandbox/1-0-preview/interpreter/) | | Errors | [Errors](https://developers.cloudflare.com/sandbox/1-0-preview/errors/) | | Durable job across requests | [Process execution — lifetime / durability](https://developers.cloudflare.com/sandbox/1-0-preview/processes/) |
**Commands (shape):**
// Before (stable)
const result = await sandbox.exec("npm test");
// After (@next)
const process = await sandbox.exec(["/bin/bash", "-lc", "npm test"]);
const result = await process.output({ encoding: "utf8" });const server = await sandbox.exec(["/bin/bash", "-lc", "npm run dev"], {
cwd: "/workspace/app",
});
await server.waitForPort(3000, { timeout: 60_000 });
await server.kill(); // numeric; default 15**Terminals (shape):**
const terminal = await sandbox.createTerminal({ command: ["bash"], cwd: "/workspace" });
const t = await sandbox.getTerminal(terminal.id);
if (!t) return new Response("terminal gone", {A collection of Agent Skills for building on Cloudflare, Workers, the Agents SDK, and the wider Cloudflare Developer Platform.
Repo: cloudflare/skills
Other skills on cloudflare.
- /agents-sdk
Build AI agents on Cloudflare Workers using the Agents SDK. Load when creating stateful agents, durable workflows, real-time WebSocket apps, scheduled tasks, MCP servers, chat applications, voice agents, or browser automation. Covers Agent class, state management, callable RPC,
Open skill - /cloudflare-email-service
Send and receive transactional emails with Cloudflare Email Service (Email Sending + Email Routing). Use when building email sending (Workers binding or REST API), email routing, Agents SDK email handling, or integrating email into any app — Workers, Node.js, Python, Go, etc.
Open skill - /cloudflare-one-migrations
Plans migrations from Zscaler ZIA/ZPA, Palo Alto, legacy VPN, SWG, or SASE stacks to Cloudflare One. Use for migration assessments, policy mapping, rollout plans, and parity/gap analysis.
Open skill - /cloudflare-one
Guides Cloudflare One Zero Trust and SASE work across Access, Gateway, WARP, Tunnel, Cloudflare WAN, DLP, CASB, device posture, and identity. Use when designing, configuring, troubleshooting, or reviewing Cloudflare One deployments. Retrieval-first: use current Cloudflare
Open skill - /cloudflare
Comprehensive Cloudflare platform skill covering Workers, Pages, storage (KV, D1, R2), AI (Workers AI, Vectorize, Agents SDK), feature flags (Flagship), networking (Tunnel, Spectrum), security (WAF, DDoS), and infrastructure-as-code (Terraform, Pulumi). Use for any Cloudflare
Open skill - /durable-objects
Create and review Cloudflare Durable Objects. Use when building stateful coordination (chat rooms, multiplayer games, booking systems), implementing RPC methods, SQLite storage, alarms, WebSockets, or reviewing DO code for best practices. Covers Workers integration, wrangler
Open skill

