[BUG] Remote Control "disconnect" always fails with "Cannot read properties of undefined (reading 'session_url')" (toggle-off path missing null guard)

i got the same error. I was enabling/disabling the remote control from claude code desktop. however, it does stop the remote control even though the error message prompted

Confirmed on macOS as well (issue is currently labeled platform:windows only):

• Claude Desktop 1.21459.3 (macOS, Darwin 24.6.0, Apple Silicon) + Claude Code CLI 2.1.211, claude.ai auth
• 4/4 disable attempts across 2 different local sessions today failed with the identical error; enable succeeded every time (bridge_state: ready → connected).

2026-07-16 13:12:52 [info] Remote control enabled: https://claude.ai/code/session_01C…
2026-07-16 13:12:52 [info] Disabling remote control for session local_9dcf…
2026-07-16 13:12:53 [error] Failed to toggle remote control for local_9dcf…: Cannot read properties of undefined (reading 'session_url')

Two details from reading the shipped bundles on macOS that may help triage:

1. The bridge does get torn down. The CLI-side handler for the remote_control disable request tears the bridge down before replying (…await Q.teardown(), Q = null… in the CLI binary), and the reply simply carries no response payload — which is exactly what the app-side a.session_url read then trips on. So the disconnect itself succeeds and the failure is app-side bookkeeping only. This matches the earlier comment ("it does stop the remote control even though the error message prompted") rather than the bridge staying live.

1. **Why it looks like it stays connected:** in the toggle handler's catch, only the enable branch resets state; the disable branch just emits the synthetic assistant message and leaves remoteControlEnabled / bridgeSessionId / bridgeSessionUrl untouched. So the UI keeps showing the session as connected, and every retry reproduces the same error until the app restarts.

A fix likely needs both: a?.session_url (or special-casing the empty disable reply), and resetting the bridge fields in the disable catch branch so the UI state can't wedge.

Confirming on macOS, with logs and mobile-side evidence for a consequence I don't think is captured yet: sessions affected by the failed disable become permanently unreachable, and the bad state survives app restarts and a full reboot. So this isn't only cosmetic bookkeeping — it has been breaking Remote Control for me for several days.

Environment: macOS (Darwin 24.6.0, Apple Silicon), Claude Desktop, Claude Code 2.1.209 (app bundle) / 2.1.210 (CLI), claude.ai OAuth, Max plan, ANTHROPIC_BASE_URL unset/default.

The two failures are distinct log events

The session_url TypeError only ever fires on the disable path, exactly as reported here:

2026-07-18 07:16:24 [info]  Disabling remote control for session local_5f010add…
2026-07-18 07:16:24 [error] Failed to toggle remote control for local_5f010add…:
                            Cannot read properties of undefined (reading 'session_url')

But enable fails separately, with different error text, and repeatedly on the same session IDs:

2026-07-17 00:02:40 [error] Failed to toggle remote control for local_667d9e24…: Session creation failed
2026-07-17 00:02:47 [error] Failed to toggle remote control for local_5f010add…: Remote credentials fetch failed
2026-07-17 00:14:31 [error] Failed to toggle remote control for local_5f010add…: Remote credentials fetch failed
2026-07-17 00:16:11 [error] Failed to toggle remote control for local_a812d5a4…: Session creation failed
2026-07-17 00:17:02 [error] Failed to toggle remote control for local_a812d5a4…: Remote credentials fetch failed

Why this may present to users as "enabling throws session_url"

Speculative, offered because the user-visible symptom and the log text don't match. Subjectively I am clicking to enable a stale session and getting the session_url error; the log records the event as Disabling. That would follow if the toggle state is read as "connected" and the click is therefore routed to the disable handler — intent is "start", code path taken is "stop".

Caveat against my own theory: there are only 2 Disabling events across 60 enables in three log files, which is fewer than my failed attempts. So either most attempts predate the available log window, or the routing explanation is wrong and something else produces the error at enable time. Flagging it as a lead, not a finding.

Mobile-side confirmation: sessions accumulate and never recover

The mobile session list shows the other end of this: 19 sessions, 11 of them Disconnected. Six projects appear as an exact-name pair — one live record and one or more stranded twins on the same repository.

Names below are redacted, but the mapping is consistent: project-a is the same repository everywhere it appears, and rows sharing a name share an identical name in the original.

| Session name | Repo | Connected | Disconnected |
|---|---|---|---|
| ProjectA Opus | project-a | 58m | 12h |
| ProjectA Sonnet | project-a | 12h | 23h |
| ProjectB Opus | project-b | 24m | 1d |
| project-c | project-c | 12h | 1d |
| project-e | (none shown) | 12h | 1d |
| project-d | project-d | 12h | 1d, 1d |

This is not age-based expiry. Five of the six live records are themselves 12h old, sitting alongside dead twins of the same name. Records are being superseded: each failed disable leaves the old session alive but unreachable, and the next enable on that project mints a new record beside it rather than reclaiming it. New sessions connect fine — the failure is that a superseded session is unreachable forever, with no way to clear or revive it. Over several days this accumulates into a list that is mostly dead entries.

Separately, and possibly related: the Devices panel reads "No recently connected devices" while eight sessions in the same view simultaneously report Connected. The device registry and the session registry disagree.

Orphan accumulation

Across three log files spanning Jul 12–18: 60 Enabling remote control events against 2 disable attempts, both of which failed. Nothing is being torn down. Alongside that, repeatedly:

[remote-control] bridge_state: failed — Transport closed: this connection is no longer
                 the active worker for the session (code 4090)

Multiple workers contending for one session — which looks like the upstream cause of the Session creation failed / Remote credentials fetch failed enable errors above, and matches the cascade in #78333 and #78484.

The bad state is not client-side, and there is no known workaround

Worth flagging for anyone triaging: restarting the app does not clear this, and neither does rebooting. I have quit and relaunched the desktop app repeatedly, rebooted the machine, and taken at least one update over the period the failures persisted.

That rules out in-memory client state. It also isn't persisted client-side: ~/.claude.json contains no remote-control registration record of any kind (only remoteControlUpsellSeenCount), so there is nothing local for a restart to clear in the first place. The stuck state appears to live server-side in the account's session records.

If that's right, no client-side fix — null guard included — will recover already-affected sessions. Those need server-side cleanup, or a client path that can force-reset a session's remote-control registration.

Suggestion

The null guard fixes the visible symptom, but the toggle state also needs reconciling on failure: a disable that throws leaves the UI asserting "connected" against a bridge the CLI already tore down, with no user-facing way back. Treating a missing/undefined registration as "not connected" and clearing state (as proposed in #78786) would cover the crash — but please also consider how already-orphaned server-side sessions get reaped, since that's the part users can't work around.

Adding another confirmed trigger + recovery path for this crash, observed on the
desktop app (Windows), with a root cause that never gets surfaced to the user.

Environment

• OS: Windows 11 Home (build 10.0.26200)
• Claude Desktop app: v1.22209 (Microsoft Store)
• Bundled Claude Code CLI: v2.1.209
• Auth: claude.ai account login
• Project path contains non-ASCII (Japanese) characters — possibly relevant to #73269

Trigger

The workspace had never been trusted via the CLI trust dialog. In that state, every
/remote-control attempt in the desktop app failed with:

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

The actual cause was only visible when running the bundled CLI directly:

> claude remote-control --verbose
Error: Workspace not trusted. Please run `claude` in <project dir> first to review
and accept the workspace trust dialog.

So the init failure (untrusted workspace) leaves a half-initialized session object,
and the disconnect/cleanup path then crashes on the missing session_url — consistent
with the missing null guard described in this issue. Related: #77716 (trust error not
surfaced), #78333 (broken session state accumulating after this crash).

Stale state until full app restart

Notably, after accepting the trust dialog via the CLI (root cause removed),
the desktop app kept failing with the same error on every /remote-control
attempt. Only a full quit + restart of the desktop app cleared it; afterwards
/remote-control worked normally.

Confirmed recovery steps

1. Run the bundled CLI once in the project folder and accept the workspace trust dialog.
2. Fully quit and restart the desktop app.

Two fixes suggested by this case:

• Surface the real initialization error (workspace not trusted) in the desktop app UI.
• Don't retain the failed session object across attempts (or null-guard the cleanup path)

so recovery doesn't require an app restart.

Follow-up to my 2026-07-16 comment: still reproduces on the latest builds — Claude Desktop 1.22209.3 (macOS, Darwin 24.6.0, app auto-updated 2026-07-19) + Claude Code CLI 2.1.214. The shipped bundle still has the unguarded read (now in index.chunk-BpE94K1E.js): const a = await e.query.enableRemoteControl(i, …) followed by a.session_url with optional chaining on .split but no guard on a itself.

Two details I don't see in the thread yet:

1. Manual toggling is not required — the auto-disable path hits the same crash.
Typing a message in the desktop app into a session that was handed off from claude.ai/code triggers an automatic disable, which crashes identically:

12:20:33 [info] handoff: publishing session_016U…
12:20:44 [info] LocalSessions.sendMessage: sessionId=local_5788…, messageLength=15
12:20:44 [info] Disabling remote control for session local_5788…
12:20:46 [error] Failed to toggle remote control for local_5788…: Cannot read properties of undefined (reading 'session_url')

Identical sequence observed on 2026-07-16 (previous app version) and 2026-07-19 (1.22209.3).

2. The failed disable wedges the session — reconnecting becomes impossible until app restart.
In the catch for the disable direction, remoteControlEnabled is not reset (only the enable direction resets state on error). The app keeps believing RC is on while the CLI side has already disabled, so every subsequent toggle re-enters the disable branch and crashes again — the enable branch is unreachable. From my logs: auto-disable failed at 12:23:36; a manual toggle at 12:32:04 failed identically.

On my machine the wedged flag is in-memory only — the session registry JSON (claude-code-sessions/<acct>/<org>/local_*.json) contains no remoteControlEnabled/bridgeSession* state for the affected session — so a full quit + relaunch clears it and RC can be re-enabled. (That differs from @misterbisson's restart-surviving variant, which may be the server-side session accumulation tracked in #78333 / #78484.)

Suggested fix remains as in the OP, plus one addition: guard the response (a?.session_url) and reset remoteControlEnabled in the disable-direction catch, otherwise a single transport hiccup permanently wedges the toggle for that session.

Also seeing this on macOS, Claude Code 2.1.207: Remote Control failed to disconnect: Cannot read properties of undefined (reading 'session_url') when disconnecting Remote Control from the CLI side.

Also reproduces on Linux, standalone CLI (not the desktop app) — adding as a datapoint since most reports here are Windows/macOS desktop:

• OS: Linux 7.0.0-27-generic (Ubuntu-based VPS, headless)
• Claude Code CLI: 2.1.198 (native installer, ~/.local/share/claude/versions/2.1.198)
• Error, verbatim, when disconnecting Remote Control from the CLI side:

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

The unguarded session_url read is present in the shipped 2.1.198 binary as well. Restarting the CLI session clears the state, consistent with the recovery path others described.

I'm hitting this multiple times a day (roughly 6x) on macOS desktop. Each time,
Remote Control just stops working with this error and there's no way to recover
it from the phone — I have to physically go back to my Mac and restart Claude
Code to get it working again. This defeats the whole point of remote work for
me; I can't rely on it right now.

Happy to share logs/repro details if useful.

Confirming from two additional Windows machines (same account), with a pinpointed regression window and one extra variant:

Regression window: Code tab Remote Control worked normally on Desktop 1.18286.0.0. Both machines silently auto-updated to 1.24012.1.0 — on the primary machine at 2026-07-21 20:13 local time (WindowsApps package folder creation time; no bootstrapper entries in ClaudeSetup.log, so it came via the in-app updater). The session_url error started immediately after on both machines — so the shallow null guard described in the OP is still shipping in 1.24012.1.0.

Enable-path variant: here the crash also fires when toggling Remote Control ON in a brand-new Code tab session — consistent with the OP's root cause if the app believes a stale/orphaned session is still enabled and runs the disable branch first. Context: this account has orphaned RC sessions whose owner processes died non-gracefully (PC restarts / forced process kills).

Local state ruled out: grepped %USERPROFILE%\.claude.json and all 8,823 transcripts under ~/.claude/projects + ~/.claude/sessions for session_url / remoteControl — zero records. Whatever stale reference the toggle trips on is app/server-side.

Unaffected: standalone terminal CLI v2.1.218 on the same machines — /remote-control enable + disconnect both work cleanly. Workaround we're using: Remote Control from the terminal only.

Another trigger for this on macOS, worth flagging because it needs no manual
toggle at all — a configuration combination makes a session disable itself.

Environment

• Claude Desktop 1.24012.1 (prod, commit 0adcaed, built 2026-07-21)
• Bundled Claude Code CLI 2.1.217 / Homebrew CLI 2.1.218
• macOS, Darwin 25.5.0, Apple Silicon, claude.ai auth

Trigger: both auto-enable settings on at once —

• ccRemoteControlDefaultEnabled (desktop app preference, Settings → Claude Code →

"Enable remote control by default")

• "remoteControlAtStartup": true in ~/.claude/settings.json (the CLI-side key,

labelled "Remote Control for all sessions" in the terminal /config panel)

A new desktop session then connects normally, and the first message you send
produces an unprompted disable, which lands on exactly the unguarded read pinpointed
in an earlier comment here:

12:39:29 [info]  [rcAutoEnable] verdict: enable=true source=explicit_pref
12:39:29 [info]  Enabling remote control for session local_a01809db-…
12:39:31 [info]  [remote-control] bridge_state: ready
12:39:31 [info]  Remote control enabled: https://claude.ai/code/session_01XdFNTR…
12:39:31 [info]  [remote-control] bridge_state: connected
12:39:33 [info]  LocalSessions.sendMessage: sessionId=local_a01809db-…, messageLength=15
12:39:33 [info]  Disabling remote control for session local_a01809db-…   <-- unprompted
12:39:33 [error] Failed to toggle remote control for local_a01809db-…: Cannot read
                 properties of undefined (reading 'session_url')

Nothing was toggled by hand at any point in that session. Removing
remoteControlAtStartup from settings.json stops it; with only the desktop
preference set, the same app connects and stays connected:

12:25:07 [info]  [rcAutoEnable] verdict: enable=true source=explicit_pref
12:25:07 [info]  Enabling remote control for session local_e94a5ae3-…
12:25:09 [info]  Remote control enabled: https://claude.ai/code/session_016gpbrf…
12:25:09 [info]  [remote-control] bridge_state: connected

So separately from the missing null guard, there's a second question here: why is a
disable issued at all? The two settings look like they both act as owners of Remote
Control for the same session — the app resolves its own preference first
(source=explicit_pref) and only falls through to the settings layers when that
preference is unset (source=explicit_settings), so with both set, two paths race
for one session. That part is inferred from log ordering and the app's rcAutoEnable
resolution order, not from instrumenting the CLI side.

Happy to split this into its own issue if you'd rather keep this one scoped to the
null guard — say the word.

Still reproduces on a much newer build — desktop app 1.24012.9.0 (bundled CLI 2.1.219), Windows 11. Confirming the root cause above from that bundle, and adding two details that explain the follow-on symptom in #81228 ("stuck until app restart") and the common report that remote control then won't re-enable on any chat.

1. The failed disconnect leaves bridgeSessionUrl set, which makes later enables silently no-op.

The catch only clears state on the enable branch:

catch (c) {
  const l = c instanceof Error ? c.message : String(c);
  logger.error(`Failed to toggle remote control for ${t}: ${l}`),
  n ? (e.remoteControlEnabled = !1, e.remoteControlAutoEnabled = void 0,
       e.bridgeSessionId = void 0, e.bridgeSessionUrl = void 0,
       ...`Remote Control failed to connect: ${l}`)
    : ...`Remote Control failed to disconnect: ${l}`
}

On the disable branch nothing is reset, so remoteControlEnabled stays true and bridgeSessionUrl stays populated even though the CLI did process the disable. The guard at the top of the toggle then fires:

const n = r?.desired ?? !e.remoteControlEnabled;
if (r?.desired !== void 0 && r.desired === !!e.bridgeSessionUrl)
  return this.emitSessionUpdated(e), { ok: !0 };

A subsequent "turn it on" (desired: true) matches !!bridgeSessionUrl and returns ok: true without doing anything — reporting success against a bridge that is already dead. A plain toggle computes !remoteControlEnabled → false → attempts disconnect again → same TypeError. So one failed toggle-off wedges that session permanently for the rest of the app run, in both directions.

2. The wedged state is in-memory only — restarting the app is a complete workaround.

saveSession is only reached on the enable branch, so neither field is persisted. Session JSON under %APPDATA%\Claude\claude-code-sessions\... carries only bridgeSessionIds (the cleanup history) — no remoteControlEnabled, no bridgeSessionUrl:

bridgeSessionUrl      => 0 of 170 session files
remoteControlEnabled  => 0 of 170 session files
bridgeSessionId(s)    => 7 of 170 session files

So a restart clears every wedged session. Until the null guard lands, the workaround is: never toggle remote control off — close or end the chat instead — and restart the app if you already did.

Log excerpt from this build, showing disable failing and enable succeeding a minute later on a fresh chat:

07:06:28 [info]  Disabling remote control for session local_df8dba9e-…
07:06:28 [error] Failed to toggle remote control for local_df8dba9e-…: Cannot read properties of undefined (reading 'session_url')
07:07:10 [info]  Enabling remote control for session local_3c3d6348-…
07:07:12 [info]  [remote-control] bridge_state: ready
07:07:12 [info]  Remote control enabled: https://claude.ai/code/session_…
07:07:12 [info]  [remote-control] bridge_state: connected

The fix on the disable path needs both halves: c?.session_url for the throw, and clearing remoteControlEnabled/bridgeSessionUrl in the catch's disable branch so a failure can't wedge the session.

Confirming on macOS against current builds, and adding three things I don't think are in the thread yet: the exact producer-side code behind the undefined, a fix that repairs already-installed clients without an app update, and a scope note.

Everything already established here — the catch wedge, the desired === !!bridgeSessionUrl short-circuit, the in-memory-only state — I re-confirmed and won't repeat.

Environment: macOS (Darwin 25.5.0, Apple Silicon), Claude Desktop 1.24012.9, bundled CLI manifest 2.1.219 (commit 7006c4c3…), locally installed CLI 2.1.220 — the latest published version as of today. The disable branch is identical in 2.1.219 and 2.1.220, so this is not fixed on either side of the wire.

The undefined originates in the CLI, not the app

@jeremy9682 described this behaviorally above ("the reply simply carries no response payload"). The exact code, for whoever picks this up — the success responder in the CLI's control-request handler always sets response from its second argument:

let Hn = function(req, payload) {
  q.enqueue({type: "control_response", response: {subtype: "success", request_id: req.request_id, response: payload}})
}

The enable branch passes a payload; the disable branch calls it with one argument:

if (dt.request.enabled) {
  …
  Hn(dt, {session_url: tw(xr.bridgeSessionId, xr.sessionIngressUrl), connect_url: …, environment_id: …})
} else {
  if (z) { …await z.teardown({reason: "remote_control_disabled"}), Lwo(null), z = null, V = !1, mMe(!1) }
  Hn(dt)                                   // ← payload undefined, key dropped by JSON.stringify
}

The SDK client returns that payload directly:

async enableRemoteControl(t, r) { return (await this.request({subtype: "remote_control", enabled: t, …})).response }

So c is already undefined by the time the app reaches c.session_url — the app-side read is the crash site, but the contract mismatch is upstream of it. Worth stating explicitly because it makes the failure unconditional: every successful disable produces this, which is why the reported failure rate is 4/4, 2/2, 100%. Hibernation, an untrusted workspace, or the remoteControlAtStartup collision in the comments above are all just ways of arriving at a disable — they don't change the outcome.

A one-line CLI fix repairs every already-installed desktop build

The app-side fixes specified above (c?.session_url plus clearing state in the disable catch) are both correct and still needed. But they only reach users after a desktop release. Since the empty payload is the CLI's, the CLI can also fix it alone:

} else {
  if (z) { …teardown… }
  Hn(dt, {disconnected: true, was_connected: z !== null})   // never respond with an empty payload
}

Any non-empty object makes c.session_url evaluate to undefined instead of throwing, so shipped desktop builds stop wedging as soon as they pick up a new bundled CLI — which moves independently of the app release train. Given how many open duplicates this has, the fast path may be worth taking alongside the proper client-side guard rather than instead of it.

Related: the disable branch replies success even when z === null and it tore nothing down. If session reaping keys off that reply, it's a candidate for the orphan accumulation @misterbisson documented — a was_connected: false reply would at least make that state distinguishable.

Scope: the terminal REPL is unaffected

This is desktop app + any SDK client calling enableRemoteControl(false). The terminal REPL has its own disconnect handler that drives the in-process bridge and prints REMOTE_CONTROL_DISCONNECTED_MSG directly — there is no control-response payload for it to dereference, so /remote-control in a plain terminal session never hits this. That may be useful for labeling, and it gives affected users a workaround beyond "restart the app": disconnect from a terminal session instead.

Analysis is from reading the shipped bundles on disk (/Applications/Claude.app/Contents/Resources/app.asar and ~/.local/share/claude/versions/2.1.{219,220}); identifiers are minified, control flow and strings are verbatim.

Confirming on Windows 11 with current builds — Claude Desktop 1.24012.9.0 (Store install) + CLI 2.1.219, claude.ai OAuth — and adding a few traced details that I don't think are captured yet. I hit this today and dug through the shipped bundle plus logs while recovering a wedged session.

1. @misterbisson's routing theory is correct — confirmed from the toggle handler

The slash-command/toggle path computes the direction from in-memory state: desired ?? !session.remoteControlEnabled. With remote control auto-enabled at session creation ([rcAutoEnable] verdict: enable=true source=explicit_pref), a later /remote-control typed with intent "turn it on / reconnect" is routed to disable — intent is "start", code path taken is "stop", exactly as speculated. That disable then dies on the missing null guard:

2026-07-28 11:49:14 [info]  Remote control enabled: https://claude.ai/code/session_01HS…
2026-07-28 11:57:42 [info]  Disabling remote control for session local_20bd…
2026-07-28 11:57:43 [error] Failed to toggle remote control for local_20bd…: Cannot read properties of undefined (reading 'session_url')

2. Why the wedge never self-heals within an app run

The only code that resets the stale fields (remoteControlEnabled / bridgeSessionId / bridgeSessionUrl) outside the toggle itself is teardownQuery — which runs when the session's CLI worker exits. But the idle-pause path skips pausing sessions whose remoteControlEnabled is true (debug-level log: "Skipping pause for session … - remote control is active"). So a wedged session is also exempted from the one lifecycle event that would clear the wedge. It sits warm indefinitely: enable no-ops (early return when desired === !!bridgeSessionUrl), disable re-crashes, forever.

Also worth noting for triage: none of the stale fields are persisted — the per-session JSON on disk only stores the bridgeSessionIds history array. In my case a plain app restart would have cleared the wedge (the survives-restart reports, e.g. #80013, may be a compounding auth issue rather than this state).

3. Server-side consequence — matches the "Disconnected twins" on mobile

After the failed disable, the claude.ai side of the bridge is left archived (the CLI tears the bridge down before replying, so the worker-side disconnect did go through). Opening the old session URL shows the transcript read-only with an "Unarchive" banner, and the unarchive call fails:

POST /v1/sessions/session_01HS…/unarchive → 409 Conflict

i.e. the stranded rows accumulate server-side and can't be revived from the web/mobile UI, consistent with the session-list table above.

4. No-restart recovery (workaround for wedged sessions)

1. Wait until the session is idle (no in-flight turn/background agents — killing the worker settles them as dead).
2. Kill that session's CLI worker process (pid is in the session-registry JSON under the config dir). teardownQuery resets the wedged fields.
3. Reopen the session and type /remote-control in the composer — state is clean, so the toggle takes the enable path and mints a fresh bridge/URL. Verified working; the session reappears on claude.ai/code immediately.

Fix-wise I'd echo the earlier comment, with one addition: besides the ?. guard and resetting bridge fields in the disable catch, the idle-pause exemption means any future variant of a stuck-enabled flag is unrecoverable without process death — so resetting the fields on any toggle failure (not just enable) seems worth doing defensively.

Confirming on macOS, and adding a trigger path I don't think is in the thread yet: the bridge gets evicted server-side with websocket code 4090, with no user action at all. That matters here because it's how users arrive at the toggle-off that crashes.

Everything already established — the always-empty disable payload, the catch wedge, the desired === !!bridgeSessionUrl short-circuit, the idle-pause exemption — I re-confirmed and won't repeat.

Environment: macOS 15.6.1 (arm64), Claude Desktop 1.24012.9, bundled CLI 2.1.219. Relevant detail: this machine never sleeps (pmset -g → sleep 0, prevented by Claude/coreaudiod; no Sleep/Wake events in pmset -g log), so this is not the hibernation path from #78786.

1. The eviction, and what precedes it by two seconds

05:18:03 [remote-tools-device] rotating (drain_wait_ms=0 inflight=0)
05:18:04 [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<org>_<device>/mac-localdomain/bridge
05:18:05 [remote-tools-device] authenticated
05:18:07 [remote-control] bridge_state: failed — Transport closed: this connection is no longer the active worker for the session (code 4090)
05:18:13 [remote-control] bridge_state: failed — … (code 4090)
   … 12 more, through 05:19:35

14 failures across every remote-controlled session in ~90 seconds, starting 2s after the device bridge rotated its socket and re-authenticated. The rotation runs roughly every 30 minutes and is usually harmless, so it reads as a race rather than a deterministic kill — with drain_wait_ms=0, the replacement connection claims the session worker slot while the incumbent is still registered, and the incumbent is evicted.

2. Nothing retries — but the client clearly can

The evicted sessions are never retried. The next [remote-control] line of any kind is at 08:12:57, three hours later, and it is an auto-enable on a different, newly created session (local_d7c7ff77…) — nothing ever went back for the ones that were evicted. That's not a general inability to recover; the JWT path recovers fine on the same build:

2026-07-27 16:38:05 [remote-control] bridge_state: reconnecting — JWT expired — refreshing
2026-07-27 16:38:07 [remote-control] bridge_state: connected

So there is a reconnect path. 4090 just terminal-fails into it instead of re-registering.

3. Frequency, and a negative result on the restart workaround

88 occurrences across 30 bursts, Jul 17-29, single machine. Clustered overnight, which is why it presents as "every morning all my remote sessions are disconnected." Through all of it the desktop UI still shows remote control enabled for those sessions while mobile shows them gone.

Correcting something in my original comment: I first read the morning Enabling remote control entries as me re-registering dead sessions by hand. They are not — each is preceded by [rcAutoEnable] verdict: enable=true source=explicit_pref, i.e. the app auto-enabling on a newly created session because enable-by-default is on. The evicted sessions were simply abandoned. That distinction matters for triage: with enable-by-default, a fresh session always gets a working link, which masks the eviction and makes it look like recovery.

More usefully, it lets me test #78878's "full restart restores it" against this machine, and it did not hold here. App restart at 20:51 on Jul 28, with several sessions evicted earlier that day:

20:51:03 [Restore] Skipping local_ditto_<redacted> — live session already in memory
20:51:03 [Restore] Skipping local_162968cd… — live session already in memory
20:51:03 [Restore] Skipping local_5bc22f46… — live session already in memory
20:51:03 [Restore] Skipping local_f9e9f69a… — live session already in memory
20:51:05 [rcAutoEnable] verdict: enable=true source=explicit_pref
20:51:05 Enabling remote control for session local_9db79cf7…      ← one session, the new one

No disable->enable pass ran for the restored sessions — they were skipped as "live session already in memory." I then hand-enabled seven of them at 21:14:49, 21:15:02, 21:15:11, 21:15:17, 21:15:29, 21:16:09 and 21:16:24, none preceded by an rcAutoEnable verdict. So on macOS 1.24012.9 the restart path is not a reliable workaround; whether #78878's Windows build restores differently, or whether the difference is that its sessions were cold rather than in-memory, I can't say from here.

4. Why this belongs on this issue

The null guard specified above is correct and needed, but it fixes the crash, not the user-visible failure. The realistic sequence is:

1. bridge evicted (4090) — no user action, no notification
2. session is dead on mobile, still shows enabled on desktop
3. user toggles off to recover — lands exactly on this crash
4. per the catch wedge and the idle-pause exemption documented above, the session can't self-heal

To be precise about what's diagnostic and what isn't: as established earlier in the thread, the disable branch always replies with an empty payload, so the crash is unconditional and its presence does not prove an eviction happened. I'm reporting 4090 as the thing that sends users to the toggle in the first place — a no-user-action entry point into this failure, distinct from hibernation (#78786) and /compact (#78482).

5. Suggestion

Treat 4090 as retryable rather than terminal — re-register the session worker on eviction, the way the JWT path already reconnects — and drain the incumbent connection before the rotated one claims the worker slot (drain_wait_ms=0 today). If the eviction is better tracked as its own issue against the bridge/rotation rather than here, happy to split it out.

Log excerpts are verbatim from ~/Library/Logs/Claude/main.log; org and device identifiers redacted.

Same bug on macOS (Darwin 25.5.0), Claude Code desktop app, v2.1.220 (native install).

• Error shown in session: Remote Control failed to disconnect: Cannot read properties of undefined (reading 'session_url')
• Reproduces every time the user toggles /remote-control; happened mid-turn while background tasks were running (the /remote-control command was queued behind an active turn).
• Auth: claude.ai OAuth (no API key, no custom base URL, no disable flags in settings/env).
• Full app restart clears the stuck state temporarily, matching #81228.

Confirming on Windows, and adding one thing that I think corrects a conclusion earlier in this thread: the wedged state _is_ persisted client-side, in a file that hasn't been mentioned yet. There is a workable client-side reset.

Environment

• Windows 11 Pro 10.0.26200
• Claude Desktop app 1.24012.9, bundled Claude Code CLI 2.1.220 (native install, auto-update on)
• claude.ai OAuth

Disable failure rate: 7/7, across 3 days and 4 distinct sessions

Counting every toggle event in the four rotated main*.log files (Jul 26 – Jul 31):

| event | count |
|---|---|
| Enabling remote control | 33 |
| Disabling remote control | 7 |
| Failed to toggle remote control … 'session_url' | 7 |

Zero successful disables, ever. Consistent with the null-guard analysis in the issue body.

The state that survives restarts: bridge-state.json

An earlier comment in this thread noted that ~/.claude.json holds no remote-control registration, and concluded from that the stuck state must live server-side only. On Windows the registration is persisted somewhere else entirely:

%APPDATA%\Claude\bridge-state.json      (macOS: ~/Library/Application Support/Claude/)

{
  "<appId>:<accountId>": {
    "enabled": true,
    "userConsented": true,
    "environmentId": "env_01…",
    "remoteSessionId": "cse_011PuaA5…",
    "localSessionId": "local_ditto_<appId>",
    "processedMessageUuids": [],
    "pendingProcessedAcks": []
  }
}

This entry has been sitting at enabled: true since Jul 29 for a cse_* session that no longer exists server-side. Every app launch reloads it and retries forever:

11:10:30 [info]  [sessions-bridge] Reconnecting persisted session cse_011PuaA5…
11:10:31 [info]  [sessions-bridge] Session cse_011PuaA5… reconnected successfully
11:10:32 [info]  [sessions-bridge] Connecting transport for session cse_011PuaA5…
11:10:32 [error] [sessions-bridge] Failed to connect transport for session cse_011PuaA5…:
                 Request failed with status code 404
11:10:48 …same, ~15s apart, indefinitely

Note the sequence: the session "reconnects successfully" at the registry level and then 404s at the transport level — the two layers disagree about whether the session exists.

The file's mtime is direct evidence for the missing-teardown analysis. bridge-state.json was last written at 11:10 (app launch). Four disable attempts at 17:39:53 / :54 / :57 and 17:45:49 left it untouched — the exception aborts before the state write, so nothing is ever cleared.

Cross-machine symptom this produces

I run two Windows machines on the same account. The failure is asymmetric and confusing in a way worth capturing for triage:

• Turn Remote Control off → the session disappears from the other machine's list (server side does drop it)
• → but the originating machine keeps showing it connected, and can never re-enable it

Users will read that as "the other machine's copy is fine, mine is broken," when it's one failure: server teardown succeeds, local bookkeeping doesn't.

Client-side workaround (untested end-to-end — see caveat)

With the app fully quit:

Get-Process Claude -EA SilentlyContinue | Stop-Process
Copy-Item "$env:APPDATA\Claude\bridge-state.json" "$env:APPDATA\Claude\bridge-state.json.bak"
Set-Content "$env:APPDATA\Claude\bridge-state.json" '{}'

Caveat: I have verified the file's contents, its mtime behaviour, and the 404 loop it drives, but I have not yet verified that clearing it restores the toggle — doing so requires quitting the app I'm working in. Offering it as a lead for anyone who can test it, not as a confirmed fix. Editing the file while the app runs is pointless; it gets rewritten.

If it does hold, then the recovery story is better than this thread currently assumes: orphaned server-side records may well need reaping as described above, but the local wedge — the part that blocks re-enabling on the affected machine — looks clearable without a server-side fix.

Suggested fix, adding to the null guard

Beyond a?.session_url and resetting the bridge fields in the disable catch branch: the persisted bridge-state.json entry should be dropped when a transport connect returns 404. A remote session the server says is gone should not be retried every 15 seconds for days.

Follow-up to my comment above — I've now tested the bridge-state.json reset. It works, but only for half the problem, and the half it doesn't fix is the half users actually notice. Correcting my own framing, and this ends up confirming the earlier server-side analysis in this thread rather than contradicting it.

Verified: the reset does clear the local wedge

Quit the app on both machines, replaced %APPDATA%\Claude\bridge-state.json with {}, relaunched. Before, every launch produced this every ~15 seconds, indefinitely:

[sessions-bridge] Reconnecting persisted session cse_011PuaA5…
[error] [sessions-bridge] Failed to connect transport …: Request failed with status code 404

After: startup reaches [sessions-bridge] account-change reevaluate: <none> → <ids> and stops there. ~1,100 log lines and 3+ minutes with zero reconnect attempts, and the file stays {} — the app does not resurrect the dead entry. So the persistent local retry loop is genuinely client-side and genuinely clearable.

(Not yet verified: whether the toggle itself is usable again afterwards. No enable/disable attempted since the restart.)

Not fixed: the orphaned session record itself

The session that was stuck showing as connected is still listed. It belongs to my other machine — I have two Windows boxes on one account — and I confirmed it exists in no local store on the machine I cleaned: it is absent from all 60 local session records (include_archived: true), and grep finds its title nowhere under %APPDATA%\Claude\claude-code-sessions\.

So the orphan lives server-side, exactly as described earlier in this thread. No amount of local file cleanup reaches it. My earlier comment implied otherwise; that was wrong. The two failures are separable:

| | lives where | cleared by bridge-state.json reset |
|---|---|---|
| 15s 404 reconnect loop | client (bridge-state.json) | yes |
| session stuck "connected" in the list | server-side record | no |

A possible reaping path for the orphans

One lead for the server-side half, from the app's own logs — archiving a local session does request teardown of its remote-control bridge sessions:

[LocalSessionManager] Requested CCR archive of 1 Remote Control bridge session(s)
                      for archived session local_a881d78d…
[LocalSessionManager] Requested CCR archive of 3 Remote Control bridge session(s)
                      for archived session local_7f89b09c…

These fire cleanly, with no session_url error — a different code path from the toggle. If it also reaps records whose disable already failed, then "archive the local session on the machine that owns it" is a user-reachable recovery for orphans, and worth documenting. I can't test it here because the affected session is on my other machine, and archiving is destructive enough that I'd rather not guess at it on a session I still want.

Cross-machine detail worth keeping

Because the orphan is server-side but the wedge is client-side, a two-machine setup splits the symptom in a way that reads as two unrelated bugs: the session vanishes from the other machine's list while the originating machine keeps showing it connected and can't re-enable it. Anyone triaging from a single-machine repro will only ever see the second half.

Confirmed: archiving the session reaps the orphaned server-side record. This closes the loop on the lead in my previous comment, and I think it means this thread's "no known workaround" is no longer accurate.

Tested on the orphan I described — a session on machine B whose disable had failed days earlier, still showing as connected, unreachable, and untouched by any local cleanup on machine A. Archiving that session on the machine that owns it removed it. It's gone from the list.

So both halves now have a user-reachable recovery:

| symptom | lives where | recovery |
|---|---|---|
| 15s 404 reconnect loop, toggle wedged "on" | client (bridge-state.json) | quit app, write {} to the file, relaunch |
| session stuck "connected", unreachable forever | server-side record | archive the session on its owning machine |

The archive path works because it doesn't go through the broken toggle. It emits [LocalSessionManager] Requested CCR archive of N Remote Control bridge session(s) and completes without the session_url throw — so it can tear down a registration that the disable handler died before reaching.

Two caveats before anyone leans on this:

• It's destructive to the session. You archive the conversation to reclaim the record. Fine for the stale ones piling up, not a fix you'd want for a session you're still using.
• Whether it also clears the superseded twins reported earlier in this thread (dead records sharing a name with a live one, where the live record is the one you want to keep) is untested. My case was a single orphan with no live twin.

That still leaves the underlying bug: users shouldn't need to destroy a session to undo a toggle that failed. But for anyone currently sitting on an accumulated list of dead entries with no way to clear them, this works today.

Still reproduces on macOS, Claude desktop 1.24012.9 (OP reports 1.21459.0.0), driving CLI 2.1.220.

The root cause in the OP is correct and I won't restate it. Two things from the same bundle that seem missing here, because together they explain the "toggle stuck ON until app restart" reports being filed as separate issues (#78336, #81228, #82567):

1. The catch resets state on the connect branch only.

catch (c) {
  const l = c instanceof Error ? c.message : String(c);
  return n.logger.error(`Failed to toggle remote control for ${t}: ${l}`),
    o ? (e.remoteControlEnabled = !1, e.remoteControlAutoEnabled = void 0,
         e.bridgeSessionId = void 0, e.bridgeSessionUrl = void 0,
         i || this.emitSyntheticAssistantMessage(e, `Remote Control failed to connect: ${l}`, …))
      : i || this.emitSyntheticAssistantMessage(e, `Remote Control failed to disconnect: ${l}`, …),
    this.emitSessionUpdated(e), { ok: !1, error: … }
}

o truthy clears four fields; o falsy clears none. The assignments that would clear them on disable live in the success path (o ? (…=!0…) : (e.remoteControlEnabled=!1, e.remoteControlAutoEnabled=void 0, e.bridgeSessionId=void 0, e.bridgeSessionUrl=void 0)), which the throw skips. So after a failed disconnect the session still reads remoteControlEnabled === true with a live bridgeSessionUrl.

2. That stale bridgeSessionUrl is what makes it unrecoverable without a restart. Near the top of handleRemoteControlCommand:

const o = r?.desired ?? !e.remoteControlEnabled;
if (r?.desired !== void 0 && r.desired === !!e.bridgeSessionUrl) return this.emitSessionUpdated(e), …

With bridgeSessionUrl still set, an explicit enable (desired: true) short-circuits as already-on and does nothing, while an explicit disable re-enters the same throwing path. Cycling the toggle cannot clear it — exactly the loop described in #81228. Only an app restart drops the in-memory state.

A fix needs both halves. c?.session_url stops the crash but leaves the toggle stuck, because the state reset is still inside the o ? branch of the success path. Hoisting the disable-side reset so it also runs in the catch — or resetting before the await and restoring on failure — is what makes toggle-off actually recoverable.

Confirming this matches what we see too: the crash itself (session_url) was a one-off, but the "toggle stuck ON until app restart" pattern from this analysis happens to us regularly on macOS — once a disconnect attempt fails, re-enabling/disabling Remote Control silently no-ops until the app is fully restarted. Matches the root cause described above (disable-path state reset only lives in the success branch, not the catch).

Confirming on macOS, Claude Desktop 1.24012.9.

Same signature: enabling works and mints a session URL, disabling always throws Cannot read properties of undefined (reading 'session_url').

My main.log has 35 occurrences across 6 days (Jul 21, 25, 28, 29, 30 and Aug 1), interleaved with successful enables — so the enable path is unaffected here too. Retrying after a failure reproduces the same error, matching the wedged-UI-state description above.

[error] Failed to toggle remote control for local_...: Cannot read properties of undefined (reading 'session_url')

Confirming on Windows 11 Pro (10.0.26200) with both CLI and Desktop app fully up to date, so this is not a stale-version issue:

• Claude Code CLI: 2.1.220 (@anthropic-ai/claude-code, latest via npm at time of testing)
• Claude Desktop app: 1.24012.9.0 (Anthropic.Claude, installed via winget; winget upgrade reports no newer version available)

Symptom matches the reports above exactly:

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

Reproduces consistently when toggling Remote Control off from the desktop app. Toggle state stays stuck as if still connected, matching the root-cause analysis above (disable branch not resetting remoteControlEnabled / bridgeSessionId / bridgeSessionUrl on the app side). No workaround found other than restarting the app, which only clears the UI state temporarily.

Also hit this on macOS (darwin 24.6.0), Claude Code v2.1.220, zsh. /remote-control disconnect threw "Cannot read properties of undefined (reading 'session\_url')" twice in a row.