Remote Control: disabling throws "Cannot read properties of undefined (reading 'session_url')" and leaves the session stuck as connected

Summary

Disabling Remote Control from the Claude Desktop app always fails with:

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

The teardown itself succeeds on the CLI side — only the acknowledgement is malformed. But because the desktop app's error handler does not reset session state on the disconnect path, the session stays permanently marked as connected, so the error repeats on every subsequent attempt.

For users who have ccRemoteControlDefaultEnabled: true, every new session auto-enables Remote Control, which means /remote-control always resolves to "disconnect" and therefore always hits this bug. Starting a fresh session does not work around it.

Root cause

The remote_control control-request handler in the CLI replies with a payload only on the enable path:

// enable
Hn(dt, { session_url: …, connect_url: …, environment_id: … })

// disable
await z.teardown({ reason: "remote_control_disabled" }); … ; Hn(dt)   // no payload

The desktop app dereferences the response unconditionally:

const c = await e.query.enableRemoteControl(o, o ? e.title : undefined);
const l = c.session_url?.split("/").filter(Boolean).pop();

When o === false, c is undefined and c.session_url throws. Note the optional chaining is on session_url, not on c, so it does not protect against this.

Compounding it, the catch only clears state on the connect path:

o ? (e.remoteControlEnabled = false, e.remoteControlAutoEnabled = undefined,
     e.bridgeSessionId = undefined, e.bridgeSessionUrl = undefined,
     emitSyntheticAssistantMessage(e, `Remote Control failed to connect: ${l}`))
  : emitSyntheticAssistantMessage(e, `Remote Control failed to disconnect: ${l}`)

On disconnect failure remoteControlEnabled stays true, so the UI keeps offering "Disconnect" and keeps throwing.

Steps to reproduce

1. Use the Claude Desktop app with ccRemoteControlDefaultEnabled: true (or enable Remote Control manually).
2. Run /remote-control in a session where Remote Control is already active.
3. Observe the error above.
4. Run it again — same error, indefinitely. Opening a new session does not help when auto-enable is on.

Expected behavior

Disabling Remote Control should report success, and the session's remoteControlEnabled state should be cleared.

Suggested fix

Either have the disable branch reply with a payload (for example Hn(dt, {})), or guard the dereference with c?.session_url on the desktop side. Independently, the catch should clear remoteControlEnabled / bridgeSessionId / bridgeSessionUrl on the disconnect path too, so a failure cannot wedge the session.

Environment

• Claude Desktop 1.24012.9
• Bundled claude-code 2.1.219 (build 2026-07-24T03:24:19Z, commit 7006c4c3acac98e554d3997baeda6a7fa4d1ff7c)
• macOS 15 (Darwin 25.5.0), arm64

Secondary note

Related but separate: /remote-control invoked from a non-interactive surface (the desktop app before Remote Control is active) is rejected with /remote-control isn't available in this environment. That message gives no hint that the command is terminal-only, which makes the whole feature hard to discover from the desktop app. A message pointing at the terminal — as the sibling gate already does with "Run it from the Claude Code terminal instead" — would help.