Skip to content

Remote Control on the macOS desktop app stops working after a day and won't recover, while the standalone CLI works from the same account #78771

Description

@NumerousJLs

Preflight Checklist

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

What's Wrong?

Remote Control in the desktop app worked for a few days, then stopped overnight and won't come back. It fails with Session creation failed, and later Remote credentials fetch failed. I fully quit the app (confirmed the old PID was gone) and relaunched, logged out and back in on both desktop and mobile, and updated — none of it changed anything.

At the same time, /remote-control from the standalone CLI on the same machine and same account works and pairs with my phone over the QR code. So this isn't my auth, network, or plan. It's the desktop app's bridge, or a stale server-side registration that a local restart can't clear.

The credential path degraded over about 8 hours with no config change on my side: it was connecting fine, then a JWT refresh got a 401, then session creation started failing, then it couldn't fetch credentials at all. That progression matches #57715 (stale/zombie bridge registration) and #72199 (same session-creation error). It is not #64070 — that one is App Store billing, and I'm web-billed through Stripe.

What Should Happen?

A stale or expired Remote Control registration should refresh or re-register on its own, so a normal quit-and-relaunch recovers it. The documented workaround for #57715 is to register from a different machine, which shouldn't be necessary.

If it does fail, the error should say why. Right now see debug log points at a log that only repeats the same bridge_state: failed line with no status code or request id, and the desktop app has no --verbose equivalent.

Error Messages/Logs

# ~/Library/Logs/Claude/main.log — connected fine, then degraded over ~8h with no config change:
07-16 22:12  [remote-control] bridge_state: connected                 <- last success
07-16 21:39  bridge_state: failed - JWT refresh failed after 401
07-17 05:32  bridge_state: failed - Session creation failed - see debug log
07-17 06:31  bridge_state: failed - Remote credentials fetch failed - see debug log
07-17 06:40  bridge_state: failed - Session creation failed - see debug log

# Every attempt targets the same local_<uuid> desktop session.
# "see debug log" is a dead end: main.log just repeats the bridge_state line, no HTTP status or request id.

Steps to Reproduce

  1. Use Remote Control from the macOS desktop app for a few days ("Enable Remote Control for all sessions" on).
  2. Leave it running / let the credentials cycle overnight.
  3. Try to enable Remote Control again from the desktop app. It fails at Session creation failed, then Remote credentials fetch failed, and stays failed.
  4. Fully quit the app (check the old PID is gone), relaunch, log out and back in, update — the failure persists.
  5. In a terminal on the same machine and account, run claude and /remote-control. It connects and pairs over QR. Only the desktop app is broken.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

It worked on this exact desktop build the day before (app 1.22209.0, bundling claude-code 2.1.209), then broke with no version change on my side. So it reads as a server-side change rather than a client bump, which lines up with #72199 and the zombie registration in #57715.

Claude Code Version

Standalone CLI: 2.1.212 (this works) Desktop app: 1.22209.0, bundling claude-code 2.1.209 (this fails)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Things I checked so it's clearly not a local or auth problem:

What would fix it, in order of usefulness to me: auto-clear a stale bridge registration so a local relaunch recovers (#57715); log the real server status and request id instead of see debug log (#57712); refresh an expired credential instead of hard-failing on the 401.

Related: #57715, #72199, #57712 look like the same underlying thing. #64070 is a different (App Store) case, noted so it isn't mistaken for this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:desktopbugSomething isn't workinghas reproHas detailed reproduction stepsplatform:macosIssue specifically occurs on macOS

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions