[BUG] Remote Control auto-enable (rcAutoEnable) flipped from enable=true to enable=false with no local config change

Status Fixed / completed
Maintainer reply None cached
Activity 0 comments · opened Sep 15, 2026 · closed Sep 15, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Remote Control for a local Claude Code session worked automatically and reliably every day from 2026-09-06 through 2026-09-14 (confirmed via main.log, [remote-control] bridge_state: "connected" recurring daily). Starting 2026-09-15, it stopped connecting, and my phone shows the session as offline with no way to re-enable it from the UI.

Checked main.log and found the relevant internal decision log line changed:

Every prior day (2026-09-06, 09-10, 09-11, 09-12): [rcAutoEnable] verdict: enable=true source=gb_default trigger=first_turn (or trigger=warm_send)
2026-09-15 06:05:51: [rcAutoEnable] verdict: enable=false source=gb_default trigger=warm_send

source=gb_default suggests this is decided by a feature-flag default rather than any local app setting, and I couldn't find any manual toggle for it anywhere in the app's UI or in any of its log files (main.log, main-window.log, unknown-window.log, claude.ai-web.log) — every occurrence of this decision, in both directions, is tagged the same way, with no alternate/manual source ever logged.

Expected: Remote Control continues working as it had been, or there's a way to manually re-enable it if the automatic flag turns off.

Actual: No way found to re-enable it; appears entirely controlled server-side.

Details:

Session ID: local_2246359a-d224-432e-8c0b-4cfc65b55ecc
Org ID: 85d10db2-906f-45b8-a2e6-0dc16cd6b69a
Desktop app install: C:\Users\yossi\AppData\Local\Claude
Platform: Windows 10

What Should Happen?

Remote Control for a local Claude Code session worked automatically and reliably every day from 2026-09-06 through 2026-09-14 (confirmed via main.log, [remote-control] bridge_state: "connected" recurring daily). Starting 2026-09-15, it stopped connecting, and my phone shows the session as offline with no way to re-enable it from the UI.

Checked main.log and found the relevant internal decision log line changed:

Every prior day (2026-09-06, 09-10, 09-11, 09-12): [rcAutoEnable] verdict: enable=true source=gb_default trigger=first_turn (or trigger=warm_send)
2026-09-15 06:05:51: [rcAutoEnable] verdict: enable=false source=gb_default trigger=warm_send

source=gb_default suggests this is decided by a feature-flag default rather than any local app setting, and I couldn't find any manual toggle for it anywhere in the app's UI or in any of its log files (main.log, main-window.log, unknown-window.log, claude.ai-web.log) — every occurrence of this decision, in both directions, is tagged the same way, with no alternate/manual source ever logged.

Expected: Remote Control continues working as it had been, or there's a way to manually re-enable it if the automatic flag turns off.

Actual: No way found to re-enable it; appears entirely controlled server-side.

Details:

Session ID: local_2246359a-d224-432e-8c0b-4cfc65b55ecc
Org ID: 85d10db2-906f-45b8-a2e6-0dc16cd6b69a
Desktop app install: C:\Users\yossi\AppData\Local\Claude
Platform: Windows 10

Error Messages/Logs

Steps to Reproduce

???

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Version 1.52386.6 (612f3f)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗