Remote Control: session hangs indefinitely after ~10 minutes of active use

Summary

When Remote Control is connected to a Claude Code session, the session works normally for the first few minutes but then becomes unresponsive after roughly 10 minutes — tool calls stop returning, output never appears, the UI hangs indefinitely until Remote Control is disconnected (or the session is force-killed).

Reproduction

1. Launch a Claude Code session in a terminal.
2. Connect Remote Control (/remote-control).
3. Use the session normally — issue prompts, run tool calls (Bash, Edit, Read, etc.).
4. After ~10 minutes of activity, an arbitrary tool call hangs.
5. From that point forward no output is produced; subsequent tool calls also hang.
6. Disconnecting Remote Control restores the session's ability to make progress (sometimes; in worst cases requires a fresh session).

Symptoms

• Bash tool calls launched after the freeze never complete and never report exit status.
• The harness sometimes reports Tool result missing due to internal error for in-flight calls.
• Background tasks (started with run_in_background: true) appear to keep running on the host (their output files keep growing) but completion notifications never arrive in the session.
• The model-side text generation continues briefly but the session as a whole stalls because tool results never come back.

Expected behavior

Remote Control should not introduce a time-bounded failure mode; long sessions (well over 10 minutes) should remain responsive whether or not Remote Control is connected.

Environment

• Platform: macOS (Darwin 25.2.0, arm64)
• Claude Code: native install, opus-4.7 1M context
• Shell: zsh 5.9
• Reproduced today across multiple sessions in the same workspace.
• Coincides with heavy background command usage (cargo build, yarn dev:app) and parallel agents.

Workaround

Avoid /remote-control for sessions expected to run longer than ~10 minutes; or disconnect proactively before that window.

Notes

• The reported 10-minute threshold is approximate; the failure is consistent in shape but the exact timing varies a few minutes either way.
• Happy to capture more detailed diagnostics (logs, traces) if there's a specific switch / debug flag to enable on the next reproduction.