Claude Code web: cloud session permanently stuck at "14 running tasks" (empty Background tasks panel, input ignored, survives restart)

Summary

In the Claude Code web app (Research preview), a cloud session became permanently wedged: it shows "14 running tasks" indefinitely, the Background tasks panel is empty (so nothing is actually running), and any message typed into the session is never processed. The stuck state is server-side and survives client upgrade, full machine restart, and archive/unarchive.

Environment

• Claude Code web (Research preview), model Opus 4.6, "High", plan: Max
• Also reproduced viewing the same session in the desktop app
• OS: Windows 11 Pro
• Cloud session tied to GitHub branch Gusdmo/GusmoAFR
• Affected session id: session_01M7GaVTPMy2ubRAgFvdt7DC (title: fx-feature-discovery)

Steps to reproduce

1. Run a cloud session that spawns background/sub tasks during a turn.
2. At some point the turn stops progressing (worker appears to die mid-turn).
3. The session is left displaying "14 running tasks" at the bottom of the conversation.

Expected

• If the worker/turn dies, the running-tasks counter should reset/reconcile and the session should accept new input.

Actual

• Counter is frozen at "14 running tasks" permanently.
• Background tasks side panel shows "Background work appears here" (empty) — i.e. there are no actual running tasks; the counter is phantom/stale.
• Every subsequently typed message is appended to the transcript but never gets a response (the session behaves as if still mid-turn and won't start a new turn).
• Esc does not interrupt the stuck turn.
• Clicking "14 running tasks" only opens the (empty) Background tasks panel; there is nothing to cancel.
• State persists across: app upgrade, full machine restart, and archive → unarchive.

Workarounds found

• × (dismiss) on the session chip hides it from the panel, but this only hides — it does not reap the server-side stuck state (reappears on unarchive).
• claude --teleport <session_id> successfully pulls the session's context into a fresh local terminal process (bypassing the wedged cloud worker), but the web/cloud session remains wedged and still shows the phantom counter — teleport does not sync state back or reap the cloud session.

Impact

• A cloud session can become permanently unusable with no client-side way to recover or clear it.
• Concern: if any of the "running" tasks were ever genuinely executing, there is no user-facing way to confirm they were stopped / not billing.

Ask

• A way to interrupt/reap a wedged cloud turn from the UI, and/or server-side reconciliation so a dead worker resets the running-tasks counter and re-enables input.