[BUG] Ctrl+C stops interrupting in a long, heavy background-agent session (macOS TUI, v2.1.161); concurrent fresh sessions interrupt fine

Summary

In one long-running TUI session, Ctrl+C no longer interrupts the agent (can't escape the in-flight turn / stop the model). On the same machine and terminal app, other claude sessions running concurrently interrupt with Ctrl+C normally. So this is per-session degradation, not a global terminal/keybinding problem.

Environment

• Claude Code 2.1.161 (native install, ~/.local/bin/claude)
• macOS 15.7.7 (Darwin 24.6.0), Apple Silicon
• Launched with --dangerously-skip-permissions
• ~14 node MCP subprocesses attached (MCP servers: claude.ai, playwright, etc.)

Observed (live ps at time of failure)

• 6 concurrent claude processes (ttys000–006). The affected session is ~19–20h old (etime 20:28:52 / 19:26:31); the sessions that interrupt fine are minutes-old.
• The long-lived sessions show high CPU even while idle/S+ (~14–23%); fresh sessions are near-idle.
• No process in D (uninterruptible sleep) or zombie state — not a kernel-level hang.

The apparent differentiator: this session's load
Many hours of heavy multi-agent orchestration — multiple Workflow-tool fan-outs (each spawning 12–21 subagents), many background subagents (Agent with run_in_background), and many background shell watchers (Bash run_in_background poll loops, several of which exited non-zero). Very large accumulated conversation context. The fresh sibling sessions did none of this.

Hypotheses / angles

1. Interrupt/SIGINT handling starves or blocks under a large set of tracked async/background tasks — the interrupt path may contend with or wait on background-task bookkeeping.
2. TUI/event-loop saturation or memory pressure in a very long, large-context session (note the high idle CPU) leaving the input/interrupt handler unresponsive.
3. Interaction with still-alive run_in_background shell poll-loops in the session's process group altering/consuming SIGINT delivery.
4. MCP-subprocess teardown contention on interrupt (~14 node procs).

Ruled out

• Not a global terminal/keybinding issue — sibling sessions on the same terminal app interrupt fine.
• Not a D-state kernel hang.

Repro
Not deterministic — emerged after many hours of heavy background-agent/Workflow usage in one session. Suggested investigation: interrupt responsiveness under (a) high background-task/agent count and (b) long-lived large-context sessions.

Possibly related (not exact dupes)

• #53011 — "Ctrl+C does not interrupt" (but /rewind-specific)
• #50665 — "Stop unresponsive… cannot interrupt in-flight actions" (Windows)
• #58662 / #41461 — background tasks/agents cannot be stopped
• #64744 — state persists after Ctrl+C

— Claude