Remote Control never connects: "Cannot read properties of undefined (reading 'session_url')" on desktop app

Additional finding

I isolated this further using the CLI directly (VS Code extension's integrated terminal, same project directory):

• claude remote-control --verbose — connects successfully, creates a brand-new Remote Control session (auto-named e.g. desktop-xxxxx-xxxxx), and I was able to pair it from the Claude mobile app via QR code without any error.
• The bug only reproduces when running /remote-control inside an existing, already-running local session in the Desktop app (or its VS Code extension) — it never affects a fresh session started via the CLI's claude remote-control command.

So the failure seems specific to attaching Remote Control to an existing session process, not to Remote Control connectivity in general (auth, ANTHROPIC_BASE_URL, workspace trust, etc. all check out fine per the docs' requirements list).

Follow-up on the workaround mentioned in my earlier comment ("start a new session via claude remote-control from the terminal").

I tried this workaround today and hit a new failure mode:

1. Started a brand-new session from the mobile side (Claude app) and connected it to a fresh local session via Remote Control. Initially this worked fine — messages sent from mobile were reflected in the desktop app and vice versa.
2. Force-killed the mobile app (task kill), then reopened it and tried to reconnect to the same session. The reconnect appeared to succeed on the surface (session still listed, history visible), but messages sent from mobile were no longer reaching the desktop app.
3. From the desktop side, I tried running /remote-control again to reconnect — this failed with a "cannot reconnect" style error (similar in spirit to the session_url crash reported above, though not identical wording).
4. I then sent a message with a photo attachment from mobile. Instead of being treated as a chat message, it seems to have been swallowed/misrouted — the /remote-control command handling took priority and the conversation became unusable from that point (no further replies were possible in that session).
5. Ended up abandoning that session entirely and starting a new one from the desktop side instead.

So in addition to the original bug (attaching Remote Control to an existing session crashes with the session_url error), it looks like even a freshly created Remote Control session can silently break after the mobile app is backgrounded/killed and reopened — reconnect doesn't restore the link, and in my case it also corrupted the session's ability to accept further messages.

Environment: Windows 11, Claude Code desktop app + VS Code extension, latest version at time of testing (2026-07-19).

Happy to provide more detail/logs if useful.

追記(2026-07-19)

同じマシン・同じWindows環境で、クライアントによって挙動が異なることを確認しました。

• デスクトップアプリ: /remote-control を実行してもURLが表示されず、引き続き本issueで報告した症状が再現する
• VSCode拡張機能: 同じプロジェクトの既存セッションに対して /remote-control を実行したところ、正常に接続用URL(claude.ai/code)が表示され、スマホから問題なく接続できた

この切り分けから、Remote Control機能自体ではなく、デスクトップアプリのクライアント実装固有の不具合である可能性が高いと考えられます。VSCode拡張機能を使えば回避可能なことが確認できました。

+1, reproducing this on Windows 11 Pro (desktop), claude --version = 2.1.207.

/remote-control throws Cannot read properties of undefined (reading 'session_url') on every attempt — the message says "failed to disconnect" even on a fresh connect — across multiple local sessions, and none of them ever become reachable from the mobile app.

Possible pointer to the root cause: in ~/.claude.json, remoteEnabled is null (no registration record), yet the command still takes the disconnect path and dereferences that missing registration. That matches #78786 (a lost/absent registration isn't treated as "not connected"), so the never-connects case here and the post-hibernation case there look like the same unchecked dereference on the disconnect path.

Expected: a missing/null registration should be treated as not-connected — reset local state and offer a fresh registration — instead of throwing a TypeError.

Additional data point (2026-07-23):

The desktop app's "Enable Remote Control by default" toggle in settings had reverted to OFF (I had turned it ON on 2026-07-18). Re-enabled it just now, then started a brand-new session — this time the new session came up with Remote Control ON by default, and I was able to connect from my phone successfully.

Not sure if this is a permanent fix or coincidental/session-specific. The original bug reported here (running /remote-control mid-conversation in an existing desktop app session fails with the session_url error) hasn't been re-tested yet since this toggle change — will follow up if I can retest that specific case.

I experience the same problem on macOS

me too

same problem

Hitting the same error on Windows 11 Pro, latest desktop app, with mobile pairing. Additional repro signal that may help isolate it: /remote-control connects fine in a newly created session — it only fails when invoked inside an existing chat session, and then always with Remote Control failed to disconnect: Cannot read properties of undefined (reading 'session_url'). App restart does not clear it; the same existing session keeps failing while new sessions keep working. Consistent with the unguarded registration-object dereference on the disconnect path described in #78786.

Also hitting this on macOS (not just Windows).

Environment

• macOS 14.x (Darwin 23.1)
• Claude Code desktop app v1.24012.1
• Max plan, individual account (not Team/Enterprise)
• Account created ~40 hours before this attempt

What happened

/remote-control initially did nothing at all — no output, no error. Checking
~/.claude.json, the feature flag showed:

tengu_onyx_plover = {'enabled': False, 'minHours': 24,
'minSessions': 3, 'remoteEnabled': False}

Once the account cleared both minHours: 24 and minSessions: 3, the command
began executing, but now fails immediately with:

Remote Control failed to disconnect: Cannot read properties of
undefined (reading 'session_url')

This is on a first invocation — no prior Remote Control session had ever been
established in this account, so there was nothing to disconnect from. The error
fires on the very first connect attempt, which lines up with the disconnect path
dereferencing an uninitialized registration object.

Tried, no effect: app restart, fresh sessions, re-auth, confirming latest version.

Happy to provide logs if useful.

Confirming this on Windows desktop, with logs — plus a data point that refines the trigger theory in #80826.

Environment: Claude desktop app 1.24012.9 (MSIX), bundled CLI 2.1.219; standalone npm CLI 2.1.220 also on PATH; Windows 11 Home 10.0.26200; Max plan (personal org); first-party api.anthropic.com.

Timeline from %APPDATA%\Claude\logs\main.log (2026-07-25, IDs truncated):

11:20:13 [info] Starting local session local_9b0942b9-… in C:\dev\<project>
11:20:13 [info] [rcAutoEnable] verdict: enable=true source=explicit_pref
11:20:13 [info] Enabling remote control for session local_9b0942b9-…
11:20:14 [info] [remote-control] bridge_state: ready
11:20:14 [info] [remote-control] bridge_state: connected
11:20:21 [info] Disabling remote control for session local_9b0942b9-…
11:20:21 [error] Failed to toggle remote control for local_9b0942b9-…: Cannot read properties of undefined (reading 'session_url')

The Disabling + error pair then repeats at 11:20:44, 11:21:10, and 11:22:30 with no user interaction.

Observations:

1. The spurious disable fires ~8 s after auto-enable, coinciding with the first user message in the session — matching the trigger described in #80826. No toggle was touched manually.
2. Refinement of #80826: only ONE of the two auto-enable settings is on here. rcAutoEnable resolves from the desktop preference (source=explicit_pref), while remoteControlAtStartup is absent from ~/.claude/settings.json (grepping settings*.json for remote returns nothing). So the self-disable-on-first-message does not appear to require both settings — the desktop preference alone reproduces it.
3. The device-level bridge is healthy: [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/… → authenticated, and bridge-state.json shows enabled: true, userConsented: true with an environmentId and remoteSessionId present. What never materializes is the per-session registration's session_url, after which the disable path hits the unguarded read tracked in #77915.
4. Account eligibility is fine: on the same machine and account, standalone CLI 2.1.220 claude remote-control (server mode) passes all eligibility checks and reaches the consent prompt normally. Meanwhile desktop sessions never appear online at claude.ai/code — grey status dot, never connectable, same as OP.
5. Error history on this machine matches the progression in #78484: Remote Control failed to connect: Remote credentials fetch failed — see debug log (2026-07-18) and Session creation failed — see debug log (2026-07-19), before settling into the silent self-disable pattern above.

Happy to pull more log context if useful.

(Diagnostics collected with Claude Code on the affected machine.)

also having this on mac with the latest version for 26.7.26

Hitting this exact error on a fresh /remote-control attempt in Desktop:

Remote Control failed to disconnect: Cannot read properties of undefined (reading 'session_url')

Setup:

• Desktop version: 1.24012.9 (03c61d)
• OS: Claude Desktop for Linux (ARM64)
• Claude Code CLI: 2.1.220 (separate install, works fine via terminal + claude remote-control)

Repro: Launch Desktop, run /remote-control, immediate failure with the above error. No prior successful Desktop RC connection.

One data point that might help narrow it down: checked ~/.claude.json locally — hasUsedRemoteControl is true, but remoteControlSurfacesSeen only ever lists ["mobile"], never "desktop". So on this account, Desktop RC has apparently never successfully registered a session at all, which would explain a disconnect handler crashing on an undefined session object — there's nothing to disconnect from.

Workaround in the meantime: CLI's claude remote-control works fine, connecting from mobile/claude.ai/code.

Possible trigger found: concurrent sessions across multiple machines.

I regularly run Claude Code sessions on more than one computer at the same time, attaching Remote Control across them. It appears my remote-control sessions are being automatically archived when multiple sessions are active concurrently across machines — which would explain the client reading session_url off an undefined/stale session state: the session it's trying to connect to has already been archived server-side.

Repro shape: have active sessions on 2+ machines under the same account, then attempt /remote-control — the session the client references seems to get archived out from under it.