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

[ShokuSo-GitHub02]

Description

Running /remote-control in a local Claude Code session (Desktop app) fails with:

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

This happens both on connect attempts and disconnect attempts — the error message says "failed to disconnect" even when no connection was ever established, suggesting the client is trying to read session_url from an undefined state object.

Steps to reproduce

1. Open Claude Code Desktop app, start/continue a local session
2. Enable "Enable Remote Control by default" in Settings → Claude Code
3. In the session input, type /remote-control
4. Error appears: "Remote Control failed to disconnect: Cannot read properties of undefined (reading 'session_url')"

Troubleshooting already done

• Confirmed app is on latest version (update check: "no updates available")
• Restarted app and tried in a brand-new session — same error
• Confirmed via claude.ai "Code" tab that this is not a "no environment published" issue (that case gives a different, expected error: "isn't available in this environment")
• Auth token list in settings shows successful past Claude Code connections, so account login itself is not the issue

Note: not the same as #78336

Unlike #78336 (where disconnect actually succeeds despite the error), in my case the connection has never succeeded even once — the mobile app's "Code" tab has never shown this session as connectable. This looks like a distinct failure mode (connection never establishes) sharing the same error message, not just a stale-UI issue after a successful disconnect.

Environment

• Platform: Windows 11 Pro
• Claude Code Desktop app, latest version
• Attempting to connect from Claude mobile app "Code" tab

Expected behavior

/remote-control should generate a session URL / QR code for pairing with the mobile app, and the mobile app's "Code" tab should show the session as connectable.

[ShokuSo-GitHub02]

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).

[ShokuSo-GitHub02]

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.

[ShokuSo-GitHub02]

追記(2026-07-19)

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

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

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

[cloverthe-ai]

+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.

[ShokuSo-GitHub02]

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.

[larsza]

I experience the same problem on macOS

[dragerz]

me too

[Backdrop9019]

same problem