[BUG] Remote Control: reattach checks the shared ~/.claude.json account instead of the session's own, splitting sessions on claude.ai

Status Open
Reported on v2.1.246
Maintainer reply None cached
Activity 2 comments · opened Oct 1, 2026

Preflight Checklist

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

What's Wrong?

My personal and my work account both run Claude Code sessions on the same Mac at the same time, under one macOS user and one ~/.claude, much like #98526. No session ever switches accounts, yet Remote Control sessions keep splitting in two on claude.ai. When a session restarts, for example after I edit and resend a message, it reconnects as a new remote session, and the old one stays in the claude.ai sidebar as a second entry with the same title. Opening that entry asks me to sign in again. Each time, the transcript gets a history-suppression row with "cause":"restored_owner_mismatch".

The reattach is checked against the wrong account. A session's persisted bridge-session pointer records ownerAccountUuid from the oauthAccount cached in the shared ~/.claude.json, and on restart it's compared with whatever that field names by then. Each session writes its own account into that field when it refreshes the profile, so with two accounts in use it keeps changing hands, and any Remote Control session whose pointer was persisted under the other value is vetoed. Neither value is necessarily the account the session runs under, which the desktop app already passes to Claude Code in CLAUDE_CODE_ACCOUNT_UUID.

Counted from my transcripts: 76 vetoes on 26 days between 2026-08-29 and 2026-09-30, on versions 2.1.246 through 2.1.284. In 51 of them a session was refused against the very account it runs under, because its pointer had recorded my other account. The check reads the same in 2.1.286.

What Should Happen?

A session's Remote Control reconnect should be judged against the account that session runs under, so a login or another account's session elsewhere on the machine doesn't split it.

Error Messages/Logs

# One of the transcript rows
{"type":"history-suppression","sessionId":"491e27ec-…","cause":"restored_owner_mismatch","vetoedAgainstAccountUuid":"2411…","ts":"2026-09-05T10:48:52.307Z"}

# The warning this path logs, as it reads in the 2.1.286 binary
[bridge:repl] Host-directed reattach vetoed: the credential store account changed since this conversation's pointer was persisted — minting fresh, history channels suppressed

Steps to Reproduce

The counts above come from everyday use. These are the steps I'd expect to reproduce it, not run in this exact form:

  1. In the desktop app, signed in as account A, open a Code session with Remote Control on and send a message
  2. In a terminal, sign claude in as account B with /login, which rewrites oauthAccount in ~/.claude.json (in my setup the other account's sessions do this on their own when they refresh the profile)
  3. Back in the desktop app, edit and resend a message in that session
  4. The transcript gets the restored_owner_mismatch row, and claude.ai lists the session twice

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.284 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

The sessions run in the Claude desktop app (2.16120.0), which bundles Claude Code 2.1.284.

#98526 is the same shared oauthAccount read as a session's own account, there for skills sync.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗