[BUG] /ultraplan: mutating tool calls time out in WSL2 cloud sandbox; chat-response fallback works

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On WSL2, /ultraplan initial exploration succeeds (read-only tool calls work fine), but the first mutating tool call in the cloud sandbox (e.g. Write to create a plan file, or Bash mkdir) hangs until the sandbox surfaces a Request timed out after roughly 15–25 minutes. The browser shows the loading state ("Baking…", "Elucidating…", etc.) the entire time.

The session is not killed — phase transitions to needs_input and the worker remains responsive. A follow-up prompt asking the worker to "skip the file write and emit the result as chat markdown" succeeds immediately, delivering the full plan output intact.

The exact same account, same repository, and same Claude Code version on Windows native runs /ultraplan to completion without any error. claude remote-control on the same WSL2 host also works fine.

Channel matrix observed in one stuck session:

| Channel | Result |
|---|---|
| OAuth / remote session creation | OK |
| Read-only tool calls (Glob/Grep/Read, 34+ in one session) | OK |
| Mutating tool calls (Write, mkdir via Bash) | Hang → sandbox-side Request timed out |
| Worker chat / message response | OK (full markdown delivered intact) |

The chat-response channel and the mutating-tool-response channel produce different results in the same session, which suggests they don't share the same transport between the cloud sandbox and the WSL local CLI.

What Should Happen?

/ultraplan should complete on WSL2 the same way it does on Windows native: the worker explores the repo, writes its plan output to a file (or to the chat), and hands control back to the local terminal — all without hitting an internal timeout in the mutating-tool-response path.

Error Messages/Logs

# Browser-side worker output (last lines before timeout):
분석 재료가 충분합니다. 이제 요약/개선점/점수를 플랜 파일에 작성하겠습니다.
[2 commands ran]
Request timed out

# Local debug log excerpts (~/.claude/debug/<session>.txt) — internal scaffolding prompt redacted:

[teleportToRemote] Bundling (reason: github_preflight_failed)
[files-api] Uploaded /tmp/ccr-seed-...bundle as _source_seed.bundle (310809 bytes)

Available environments:
  env_xxx (N:repo:NNNN, bridge)
  env_yyy (Default, anthropic_cloud)
  env_zzz (Default, anthropic_cloud)
Selected environment: env_yyy (Default, anthropic_cloud)

Successfully created remote session: session_xxx

[ultraplan] phase running → needs_input
[ultraplan] phase needs_input → running
[ultraplan] phase running → needs_input
... (~17 minute gap, no entries) ...
[ultraplan] phase running → needs_input    # appears the moment "Request timed out" surfaces in browser

Steps to Reproduce

1. On a WSL2 host (Windows 11 + Ubuntu), in a Git repository that does NOT have the Claude Code GitHub App installed, start Claude Code:

$ claude

1. Inside the session, invoke /ultraplan with any prompt that the worker will reasonably want to write to a file as part of producing its plan. In my repro the prompt was (Korean — same outcome with English equivalent):

"현재 프로젝트를 요약하고, 개선점들을 알려줘. 현재 프로젝트의 수준과 종합점수도 매겨줘."
English equivalent:
"Summarize this project, list improvements, and give it an overall score."

1. Open the resulting claude.ai/code URL in a browser (on WSL2 the URL does not auto-open — manual paste into Windows browser; this is irrelevant to the bug, see note below).

1. Watch the worker. It performs many read-only operations (Glob/Grep/Read) successfully — in my session ~34 such calls in total.

1. When the worker decides to write its analysis to a file, the browser UI shows a loading indicator ("Baking…", "Elucidating…", etc.) and never resolves.

1. After ~15–25 minutes, the worker output ends with "Request timed out". The phase transitions to needs_input (visible in ~/.claude/debug/<session>.txt as [ultraplan] phase running → needs_input).

1. The session is still alive. Send a follow-up prompt:

"파일에 쓰지 말고 분석 결과를 그냥 이 chat에 markdown으로 직접 출력해줘."
English equivalent:
"Skip the file write. Output the result directly to this chat as markdown."

1. The worker immediately produces the full plan output as a chat message — proving the worker and its message channel are healthy; only the mutating-tool-response path fails.

Notes:

• The bug reproduces independently of the prompt language (Korean / English).
• It does NOT reproduce when the same Claude Code version + same account + same repo is used on Windows native instead of WSL2.
• It does NOT affect claude remote-control on the same WSL2 host (which also runs against claude.ai/code).
• The browser-not-auto-opening behaviour on WSL2 is unrelated — manual URL paste is documented as supported, the OAuth/session creation step succeeds cleanly in the debug log, and the failure happens much later inside an already-established sandbox session.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.97

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

• Terminal emulator: Warp on Windows 11, connecting into WSL2 Ubuntu where the claude binary runs natively. Selected "WSL" above because the bug is environment-specific (WSL2), not terminal-emulator-specific — confirmed by the fact that the same Claude Code version runs /ultraplan cleanly on Windows native.

• Repository: jaceleedev/blueprint (public). The Claude Code GitHub App is NOT installed on this repo, so the seed bundle path is used ([teleportToRemote] Bundling (reason: github_preflight_failed) in the debug log). The uploaded bundle is also stale — the worker observes HEAD = fafee97 (PR #8) even though the local working tree is at PR #23 — but this is a separate issue from the timeout (read-only exploration still proceeds normally over the stale base).

• Environment selection observation: a bridge environment is provisioned for this project (env_xxx (N:repo:NNNN, bridge) in the debug log) but ultraplan selects an anthropic_cloud environment instead. I don't know whether this is intentional (bridge = remote-control only?) or a selection-logic issue. Possibly related to #34950 (tengu_ccr_bridge).

• Workaround: when invoking /ultraplan on WSL2, include "Output the analysis as markdown in this chat. Do not write to any file." in the prompt. The worker then produces the full result as a chat message, bypassing the mutating-tool-response failure.

• Related issues:
• #44804 — closest in symptom (ultraplan timeout) but reports a 30-minute full-session timeout with output discarded; my session stays alive in needs_input state.
• #44639 — /ultraplan not available on WSL despite meeting all requirements. In my case ultraplan IS available, just times out at the first mutating tool call.
• #34950 — tengu_ccr_bridge server-side feature flag context.
• #35740 — MCP OAuth callback random port breaks in WSL2 (different feature, but precedent for WSL2 networking issues).

I have the full debug log, browser screenshots, and recovered chat-fallback output saved locally and can share any of them on request (the debug log needs minor redaction of internal scaffolding prompt text before posting).