Sandbox SDK: startProcess stream controller closes prematurely, killing agent processes

[jbbjbb]

Bug Report: Sandbox SDK Stream Controller Premature Closure

Environment

• @cloudflare/sandbox via Cloudflare Workers
• Sandbox container running OpenClaw AI agents (Node.js processes)
• Bun-based container runtime (/$bunfs/root/sandbox)

Description

When running long-lived processes via sandbox.startProcess() with onOutput callbacks, the internal ReadableStream controller closes prematurely while the child process is still streaming output. This causes:

1. TypeError: Invalid state: Controller is already closed in the SDK's internal Bun runtime
2. The onOutput callback stops receiving data
3. The process is marked as "Failed to execute streaming command"
4. Subsequent SDK operations (containerFetch, exec) become unreliable — the SDK bridge enters a degraded state

Reproduction

This occurs consistently when:

• A startProcess() command runs for >2 minutes producing continuous output
• Multiple concurrent startProcess() calls are active (e.g., parent agent spawns a child agent via OpenClaw's sessions_spawn)
• The container is under memory pressure (~1.4GB+ of 5.4GB used)

Approximate frequency: Every 30-80 minutes during sustained agent activity.

Error Details

Two correlated errors appear in Cloudflare container logs:

Error 1: Background streaming failure

{
  "level": "error",
  "component": "container",
  "originalError": "Invalid state: Controller is already closed",
  "error": {
    "message": "Invalid state: Controller is already closed",
    "stack": "TypeError: Invalid state: Controller is already closed\n    at unknown\n    at <anonymous> (native:1:11)\n    at _ (/$bunfs/root/sandbox:26:12)\n    at <anonymous> (/$bunfs/root/sandbox:50:9084)\n    at forEach (native:1:11)\n    at <anonymous> (/$bunfs/root/sandbox:50:9076)\n    at <anonymous> (/$bunfs/root/sandbox:159:5464)\n    at processTicksAndRejections (native:7:39)"
  },
  "$metadata": {
    "error": "Error during background streaming",
    "message": "Error during background streaming",
    "type": "cf-container"
  }
}

Error 2: Command execution failure (same timestamp)

{
  "level": "error",
  "component": "container",
  "command": "openclaw agent --agent 'clarity-ordinator' --message '...' --json",
  "error": {
    "message": "Invalid state: Controller is already closed",
    "stack": "(same as above)"
  },
  "$metadata": {
    "error": "Failed to execute streaming command",
    "message": "Failed to execute streaming command",
    "type": "cf-container"
  }
}

Impact

After this error:

• The SDK bridge enters a degraded state where containerFetch() fails but exec() may still work briefly
• Eventually the bridge becomes fully unresponsive ("bridge-dead")
• The only recovery is sandbox.destroy() + fresh container creation
• All in-progress agent work is lost

What we'd like

1. onError callback in startProcess() options — so callers can detect streaming failures and handle gracefully (log, mark task as failed, skip waiting for onExit)
2. Stream controller resilience — if the controller closes, the error should be surfaced to the caller rather than silently breaking the bridge
3. Graceful degradation — a single stream failure shouldn't poison the entire SDK bridge for subsequent operations

Workaround

We've mitigated the worst case by:

• Denying OpenClaw's sessions_spawn tool to prevent concurrent startProcess() calls
• Running agents serially through a queue (max_batch_size=1)
• Circuit-breaker that destroys the container after detecting the degraded state

But the underlying stream controller issue still causes flaps every 30-80 minutes during any sustained agent activity.

[jbbjbb]

Update: We added onError to our startProcess() call, but the "Controller is already closed" error does NOT flow through the onError callback. It remains trapped in Cloudflare's internal cf-container logging layer, invisible to user code.

Additionally, disabling concurrent startProcess() calls (only one agent at a time) did not prevent the issue. The stream controller death occurs with a single streaming process — this is not a concurrency/race condition on our side.

The error continues at the same ~30-80 minute cadence with a single serial agent process, confirming this is an SDK-internal issue with the Bun runtime's ReadableStream controller lifecycle.

We can see the error in the Cloudflare dashboard container logs but have no programmatic way to detect or handle it from Worker code.

[jbbjbb]

Cross-references from related issues:

This appears to be the same underlying ReadableStream controller lifecycle bug documented across several repos:

• A couple of issues with execStreaming long running tasks sandbox-sdk#101 — "execStreaming long running tasks" — same silent stream death pattern. Reporter built health-poll + 260s timeout workarounds. The keepAlive fix addressed container idle timeouts but not the controller crash itself.
• ws-transport sets unconfigurable 120000ms timeout, breaking long running execStream sandbox-sdk#398 — WS transport had a hardcoded 120s timeout killing streams (fixed, but our streams die at 30-80 min, not 2 min)
• killProcess maybe doesn't work? sandbox-sdk#338 — killProcess() doesn't propagate SIGTERM to child processes (OPEN) — orphan processes writing to a closed controller could be a trigger
• ReadableStream controller.desiredSize throws TypeError: null is not an object after downstream closes oven-sh/bun#26377 — controller.desiredSize throws TypeError after downstream close instead of returning null per spec (CLOSED/fixed in Bun — but the Sandbox runtime may be on an older Bun version)
• Bug: Controller is already closed crash in run-tools-transformation when stream errors during tool execution vercel/ai#12874 — Identical race condition pattern: async callbacks call controller.enqueue() after stream is closed. Proposed fix: guard all enqueue()/close() calls with a synchronous _controllerClosed flag set in cancel(). This fix pattern would need to be applied inside the Sandbox SDK's container runtime.

The Bun fixes (oven-sh/bun#19661, #26377) may resolve this if the Sandbox runtime's Bun version is updated. Can you confirm what Bun version the /$bunfs/root/sandbox runtime uses?

[whoiskatrin]

@jbbjbb can you confirm which version of sandbox-sdk you are running?

[whoiskatrin]

@jbbjbb thanks for reporting this! This PR should fix your experience: cloudflare/sandbox-sdk#576

try this SDK version and let me know how this feels on your side

npm i https://pkg.pr.new/cloudflare/sandbox-sdk/@cloudflare/sandbox@576

[whoiskatrin]

@jbbjbb let me know, would love to get this merged and released for you