Skip to content

Bug: sandbox.mode: "non-main" silently breaks sessions_spawn subagent initialization #39248

Description

@alexputici

Summary

When agents.defaults.sandbox.mode is set to "non-main", sub-agents spawned via sessions_spawn fail to initialize. Sessions are accepted (return valid childSessionKey and runId) but never start executing — zero tokens, zero messages, no transcript files created. No errors appear in gateway logs.

Environment

  • OpenClaw Version: 2026.3.2 (85377a2)
  • OS: macOS 15.3.0 (Apple Silicon, arm64)
  • Node: v25.8.0
  • Docker Desktop: running (coding agent sandbox works fine)

Steps to Reproduce

  1. Set agents.defaults.sandbox.mode: "non-main" in config
  2. Restart gateway
  3. From main agent, spawn a sub-agent:
    sessions_spawn(task="Reply with: test", model="sonnet")
    
  4. Check sessions_history or subagents list after 30+ seconds

Expected Behavior

Sub-agent starts within seconds, systemSent: true, tokens accumulate, task completes.

Actual Behavior

  • sessions_spawn returns status: "accepted" with valid session key
  • Sub-agent appears in subagents list as running
  • sessions_history returns messages: [] indefinitely
  • No transcript file created on disk
  • systemSent never set to true
  • totalTokens never set
  • Zero error output in gateway logs
  • Eventually times out via runTimeoutSeconds

Bisect Results

Systematically tested with a simple one-line task (Reply with exactly: ...):

Test sandbox.mode Docker settings Result
1 non-main network: bridge, readOnlyRoot: true stall
2 non-main network: bridge, readOnlyRoot: false stall
3 off (same as test 2) works (4s)
4 non-main minimal (image + workdir only) stall

The issue is not caused by specific Docker settings (network, readOnlyRoot, tmpfs). Any sandbox.mode that enables Docker for subagents causes silent failure.

Notes

  • Cron isolated sessions work fine with sandbox.mode: "non-main" on the same config — they appear to use a different code path that bypasses container initialization.
  • Per-agent sandbox overrides are unaffected: a coding agent with sandbox.mode: "all" and its own Docker settings works correctly.
  • Possibly related to Bug: agentToAgent.enabled: true breaks sessions_spawn - sub-agents never start #5813 (similar symptoms, different attributed cause).
  • The silent failure with zero log output makes this very difficult to diagnose.

Workaround

Set agents.defaults.sandbox.mode: "off" and use per-agent sandbox.mode: "all" overrides for agents that specifically need sandboxing (e.g., coding agents with tools.exec.host: "sandbox").

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:crash-loopCrash, hang, restart loop, or process-level availability failure.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions