`dcode --sandbox <provider>` fails server startup with `Blocking call to socket.socket.connect` (blockbuster guard kills sync sandbox creation on the event loop)

[jack-michaud]

Submission checklist

• This is a bug, not a usage question.
• I added a clear and descriptive title.
• I searched existing issues and didn't find this.
• I can reproduce this with the latest released version.
• I included a minimal reproducible example and steps to reproduce.

Area (Required)

• deepagents (SDK)
• dcode
• talon
• acp
• evals
• harbor
• daytona
• modal
• quickjs
• runloop
• vercel
• langsmith-sandbox
• Other / not sure / general

Related Issues / PRs

• Sandbox creation runs on the event loop and is killed by the blocking-call guard #5278: same root cause (sync create_sandbox on the event loop trips the blockbuster guard), filed for daytona; auto-closed by the triage bot before human review. Still unfixed on main.
• perf(langsmith-sandbox): run LangSmith sandbox commands over the async client #5061 (merged): moved LangSmith sandbox command execution to the async client, but not the snapshot-creation path, so this bug persists.
• fix(code): run sandbox creation and entry off the guarded event loop #6017 (closed): failing regression test for this exact bug (test(code): sandbox creation must not run on the blockbuster-guarded loop). It was automatically closed for lacking an approved issue link. The test fails on main and passes once sandbox creation is offloaded from the event loop.

Reproduction Steps / Example Code (Python)

# langsmith (needs valid LANGSMITH_API_KEY or LANGSMITH_SANDBOX_API_KEY)
dcode --sandbox langsmith

# agentcore (needs AWS credentials)
dcode --sandbox agentcore

# Both abort before the server passes readiness. Reproduced on langsmith and agentcore

Error Message and Stack Trace (if applicable)

# langsmith
Error: Server failed to start: RuntimeError: Server graph 'agent' failed readiness
check (status: 500): Sandbox creation failed for 'langsmith': Failed to list
snapshots: Blocking call to socket.socket.connect

# agentcore
Error: Server failed to start: RuntimeError: Server graph 'agent' failed readiness
check (status: 500): Sandbox creation failed for 'agentcore': Blocking call to
socket.socket.connect

Description

dcode --sandbox <provider> fails at server startup for the synchronous-SDK providers I tried (langsmith and agentcore). The same failure was previously reproduced with daytona in #5278. The server runs python -m langgraph_cli dev, which arms the blockbuster blocking-I/O guard on the event loop (langgraph_runtime_inmem/queue.py -> _enable_blockbuster()). dcode's graph factory then creates the sandbox synchronously on that loop:

_make_graph()                      async  server_graph.py
  └─ create_sandbox(...)            sync  server_graph.py   ← creates context manager
       └─ __enter__()                 sync  server_graph.py   ← on the event loop
            └─ provider.get_or_create()  sync  sandbox_factory.py
                 └─ socket / filesystem I/O    ← guard fires here

For langsmith specifically, _LangSmithProvider._ensure_snapshot -> list_snapshots() uses the sync SandboxClient from langsmith.sandbox, so the first blocking HTTP connect raises BlockingError. The readiness probe 500s and startup aborts.

Unfortunately, inheriting LANGGRAPH_ALLOW_BLOCKING=true does not work around this: langgraph dev rewrites it from the CLI --allow-blocking option, which dcode does not pass, so it becomes false.

Suggested fix: offload the complete synchronous context-manager entry (create_sandbox(...) plus __enter__()) via asyncio.to_thread, with cancellation and late-cleanup handling. SandboxProvider.aget_or_create already exists but has zero call sites. Using AsyncSandboxClient would address LangSmith only; __exit__() currently runs from atexit, outside the guarded event loop.

Environment / System Info

OS: macOS 15.7.4
Python: 3.13.2
deepagents: 0.7.10
deepagents-code: 0.1.65
langsmith: 0.11.2
langgraph-cli: 0.4.31

[UniversePeak]

I checked the reported startup path and the relevant deepagents-code code: the async graph factory still calls synchronous sandbox creation and context entry directly on the event loop, while the provider layer already exposes an async-safe offload path. I’d like to update the server-side sandbox lifecycle to keep blocking provider work off the guarded loop and add a focused regression covering startup under the blockbuster guard. Could you assign this issue to me if no one else is working on it?

[wangjiawei-vegetable]

I'd like to work on this issue. I have prepared and locally validated a candidate fix, but I have not opened a PR yet because I would like to confirm the direction first.

The implementation moves the complete synchronous sandbox context-manager initialization — create_sandbox(...) and __enter__() — into a worker thread via asyncio.to_thread().

It also:

• publishes _sandbox_cm and _sandbox_backend only after successful entry;
• cleans up a sandbox that finishes opening after the startup task is cancelled;
• makes each atexit handler capture the exact context manager it owns; and
• preserves the existing startup-error behavior.

I also validated the cancellation scenario against real Open Sandbox instances using the same probe command in both cases:

printf 'OPEN_SANDBOX_ALIVE\n'

With the current implementation, startup blocked the event loop, cancellation did not take effect, and the probe still completed successfully (exit_code=0, OPEN_SANDBOX_ALIVE). No automatic cleanup occurred. I manually terminated the reproduced sandbox immediately after capturing the evidence.

Current implementation:

With the candidate fix, the event loop remained responsive and cancellation propagated as CancelledError. Once the late sandbox creation completed, it was automatically cleaned up. Repeating the probe against the same sandbox failed with HTTP 409 / SANDBOX_STATE_CONFLICT, and the API reported its state as Terminated.

Candidate fix:

The network-free tests use BlockBuster and a fake provider with blocking work. I also added cancellation and cleanup-ownership coverage. The targeted server-graph tests pass, along with Ruff and ty.

The separate setup-script failure leak is intentionally out of scope.

If this direction looks good, would you mind assigning #6018 to me? I'll open the PR and include Fixes #6018 in its description.

[open-swe]

Edited for precision after checking current main: marked #6017 as closed and explained why; narrowed the affected scope to synchronous-SDK providers with the three reproduced cases; corrected the call graph to show that blocking work starts in __enter__(); clarified why inheriting LANGGRAPH_ALLOW_BLOCKING=true is ineffective; and refined the suggested fix to offload complete context-manager entry with cancellation/late-cleanup handling. No change to the core diagnosis.

[abhinavkr26104]

I can take this if the existing candidate implementation is no longer being pursued. Please assign it to Abhinav Kumar Singh (@abhinavkr26104) if available; I will wait for assignment before coding.

[jack-michaud]

Thanks Mason Daugherty (@mdrxy)!