claude --resume permanently fails after session interrupted mid deferred-tool-call / plan-mode boundary

Summary

Sessions that use background/deferred agents (Task tool in background mode) combined with plan-mode approvals can enter a state where claude --resume <id> fails to reattach — permanently, even after following the CLI's own suggested fix.

Environment

• claude --version: 2.1.207
• OS: macOS (Apple Silicon Mac Studio, always-on host, accessed remotely)
• Reproduced identically via a plain interactive ssh shell and via a terminal-multiplexer SSH workspace (cmux) — ruling out the terminal wrapper / SSH multiplexing as the cause.
• Confirmed not related to SSH connection exhaustion (session count on the remote host was low, well under any MaxStartups limit).

Steps to reproduce

1. Start a Claude Code session doing substantial work that spawns background/deferred subagents (Task tool, background mode) and goes through plan-mode approval cycles.
2. Interrupt the session (SSH drop, terminal close, etc.) while a deferred tool call is in flight or near a plan-mode-exit boundary.
3. Run claude --resume <session-id>.

Observed behavior

Bare resume fails almost immediately (~10-15s), with no visible error in normal mode — it just prints:

Resume this session with:
claude --resume <session-id>

and returns to the shell, indistinguishable from a crash/disconnect.

Running the same command with --debug reveals the real cause:

Error: No deferred tool marker found in the resumed session. Either the session was not deferred,
the marker is stale (tool already ran), or it exceeds the tail-scan window. Provide a prompt to
continue the conversation.

Following that suggestion works, but only once:

claude --resume <session-id> "continue"

This resumes the session and it runs for a real amount of time (observed: 9m20s of genuine work in one case), but then dies again with the exact same message once it hits another deferred-tool/plan-mode boundary. Every subsequent resume attempt — with or without a trailing prompt — fails the same way from then on. The session becomes permanently unresumable.

Two independent sessions in the same project hit this and had to be abandoned; in-progress work had to be manually salvaged by reading the raw .jsonl transcript file rather than through any supported resume/export path.

Secondary/cosmetic issue

When the interactive TUI exits via this failure path, xterm SGR mouse-tracking mode (enabled on startup for scroll support) never gets disabled, because it's only disabled during a clean interactive shutdown. This leaves the terminal stuck in mouse-reporting mode afterward — any trackpad/scroll motion sends raw ESC[<button;x;y M sequences into the shell as literal keystrokes, which the shell then tries to execute as garbage commands. Worth disabling mouse tracking unconditionally on this exit path too.

Impact

Any session that relies on background agents + plan mode becomes permanently unresumable after a single interruption at the wrong moment, with no supported recovery path — the user has to manually reconstruct context from the raw transcript file.

Suggested fix direction

• Widen the tail-scan window used to locate the deferred tool marker, and/or make the "provide a prompt" fallback actually clear/resolve the stale marker state instead of just deferring the same failure to the next boundary.
• Ensure terminal mouse-tracking escape codes are disabled on this exit path, not only on clean shutdown.