[BUG] Remote Control "enable for all sessions" preference not honored; quota-limit stops also kill the session

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (related: #36261, #55406, #66491 — but none cover these two specific failure modes)
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

---

Summary

Two related failure modes that both require manually re-running /remote-control to restore a remote session:

1. "Enable for all sessions" preference is not honored — the Claude.app setting to activate Remote Control automatically for every new session is silently ignored. After every app restart (or any hard stop), /remote-control must be sent manually to restore the session.

1. Model quota / rate-limit stops kill the remote session — when the model hits a quota or usage-limit pause (the kind that causes Claude to stop mid-response and display a "usage limit reached" message), the underlying Remote Control bridge process exits. When quota clears and a new turn starts, the remote session is gone and must be re-established manually.

---

Environment

• OS: macOS (Darwin)
• Claude Code / Claude.app version: latest
• Remote Control entry point: /remote-control command inside Claude.app session (not CLI claude remote-control)
• App setting: "Enable Remote Control for all sessions" toggled on

---

Current Behavior

Failure mode 1 — "All sessions" preference ignored

1. Open Claude.app, confirm "Enable Remote Control for all sessions" is toggled on.
2. Quit and relaunch the app (or let a quota stop force a session boundary).
3. Start a new chat session.
4. Observe: no remote session is established — the mobile/web client shows no active session.
5. Workaround: manually type /remote-control to re-establish.

Expected: the preference causes Remote Control to be activated automatically at session start, so step 4 connects without manual action.

Failure mode 2 — Quota stop terminates the bridge

1. Run /remote-control; confirm mobile/web client is connected.
2. Hit the model's usage/quota limit — Claude pauses with a rate-limit message.
3. Wait for quota to reset; send a new message from the remote client.
4. Observe: the remote client shows "Remote Control disconnected" or an equivalent error; the bridge is gone.
5. Workaround: send /remote-control again from the main terminal/app session.

Expected: quota pauses are ephemeral — the bridge process should survive a quota hold, either by staying alive in a waiting state or by being respawned automatically when the session resumes.

---

Why These Should Be Treated as a Single Report

Both failure modes have the same root cause from the user's perspective: the remote session does not outlive interruptions that don't originate from an intentional disconnect. The "all sessions" preference promises persistence but doesn't deliver it even for a clean restart; quota stops expose the same gap but via a runtime path.

---

Expected Behavior

• The "all sessions" preference should result in /remote-control being automatically activated at the start of every new Claude.app session, with no manual prompt required.
• A quota/rate-limit pause should not terminate the bridge process. The bridge should either hold the connection open (heartbeat) or re-register its session ID automatically when the quota clears and a new turn begins.

---

Additional Context

• Quota stops are common for Max plan subscribers running long agentic tasks; this means the failure happens regularly during normal use, not just edge cases.
• The "all sessions" preference presumably exists to solve exactly this friction — so its non-functioning is especially confusing.
• Workaround (/remote-control after every disruption) is low-friction individually but breaks automation/unattended workflows that depend on remote sessions being stable.