Ultraplan: sustained failures (API timeout, partial response, container fails to start)

Summary

Repeated Ultraplan plan-refinement failures on 2026-04-28, plus an earlier instance the same day. Four consecutive failed attempts across the two sessions filed below; the user fell back to local execution after the third failure.

Failed sessions

• session_01AT3eHAxuV6u6qxXxYFKQV5 — terminated error_during_execution mid-run, ExitPlanMode never reached
• session_01JAZdg7u68B38JxtgntH7Ye — UI showed "Starting Claude Code on the web…" but the remote container never spun up; session sat idle for 90 minutes before terminating with the same error

Earlier the same day, a separate plan-mode handoff for the SHAPE phase of an unrelated brief also failed on first attempt (~90 min timeout) and succeeded on retry. Pattern feels persistent rather than transient.

Reproduction

1. From plan mode, exit with a non-trivial plan (in the failing cases: ~10K-token plan files at C:\Users\Joshua\.claude\plans\*.md)
2. The Ultraplan handoff fires; UI prints ◇ ultraplan · Starting Claude Code on the web…
3. Container either:

• Fails to start (no progress for 90 min, then errors)
• Starts but returns partial response and times out
• Returns mid-execution error before reaching ExitPlanMode

Workaround

Retry. Some attempts succeed on the second try (precedent earlier in the same day). Sustained failures (4+ consecutive) require falling back to local execution. When the local plan was already grounded against the target files, local execution worked cleanly.

Impact

Each failed attempt costs ~30-90 min of wall time. The "sit idle for 90 min before erroring" failure mode is the most disruptive — no progress signal, no early termination. Users running Ultraplan for actual plan-quality refinement lose the value of the remote pass when this happens.

Environment

• Claude Code CLI on Windows 11
• Bash shell (Git Bash)
• Both sessions filed on 2026-04-28 EDT, ~30 min apart

Suggestion

A heartbeat / progress signal during the "Starting Claude Code on the web…" phase would help operators distinguish transient slowness from a stuck container, and could let the client time out earlier when the container hasn't started after, e.g., 5 minutes.