[Bug]: Account sync rejects with "live connector credentials conflict" when two Claude keychain items hold different MCP tokens; blocks Claude launches and usage badge #27334

Activity

1. jjongsta commented on Oct 10, 2026

   

   jjongsta

   on Oct 10, 2026

   Author

   More actions

   Follow-up with the actual pair that conflicts, after two experiments:

   1. Deleting the seven per-config-dir keychain items (Claude Code-credentials-<hash>) did NOT stop it: the next sync tick (3 minutes later) rejected again with only the legacy keychain item left.
   2. Moving the plaintext file ~/.claude/.credentials.json aside DID stop it: 0 rejections in the 6 minutes after the move, against one every 3-5 minutes before.

   That file was last written at 17:42Z while the legacy keychain item kept being refreshed by the running sessions (connector tokens for the same MCP servers differ between the two). Orca's claude-runtime-auth/system-default-auth.json carries credentialsJson, legacyKeychainCredentialsJson and scopedKeychainCredentialsJson, so I take it the merge compares the file store with the keychain stores and refuses when their mcpOAuth entries differ.

   Suggested fix stays the same: per connector key, take the token with the latest expiresAt (or prefer the keychain on macOS, where Claude Code writes), and never let a connector-token disagreement block account switching or the usage fetch.
2. santidevhmo commented on Oct 11, 2026

   

   santidevhmo

   on Oct 11, 2026

   More actions

   Same bug here on Orca 1.4.224, macOS 26.4.1 (arm64). It started after a force quit and a reboot, and every Claude launch failed with "Couldn't launch Claude — the terminal did not start" plus this conflict error. Adding a second data point, because moving the plaintext file aside was not enough on my machine, and a workaround that did fix it.

   What I found

   1. I moved ~/.claude/.credentials.json aside first, as suggested above. Its last write was the day before, and it held 19 mcpOAuth entries. Launches still failed afterwards.
   2. Two keychain items remained: the legacy Claude Code-credentials (refreshed today by running sessions) and the per-config-dir Claude Code-credentials-6fb7661b, where 6fb7661b is sha256("$HOME/.claude")[:8] (last written the evening before).
   3. Comparing their mcpOAuth maps, without printing tokens, showed 6 of 19 connectors with different grants: atlassian, linear-server, cloudflare, context7, mobbin and supabase. In every case where both sides had an expiresAt, the legacy item's was later. The per-dir item's tokens had already expired.

   That matches resolveCredentialField in src/main/claude-accounts/shared-credential-fields.ts (added in #21931): when two live sources both differ from the baseline for the same server key and from each other, it throws instead of choosing one. So any drift between the stores eventually blocks every launch.

   Workaround that fixed it

   Back up the stale per-dir item, then overwrite it with the legacy item so both stores agree. Launches worked right after.

   # Run with: python3 -I sync_claude_keychain.py
   # Replace the suffix with your own: printf '%s' "$HOME/.claude" | shasum -a 256 | cut -c1-8
   import re, subprocess
   
   L, S = "Claude Code-credentials", "Claude Code-credentials-6fb7661b"
   B = S + "-backup"
   
   def acct(s):
       r = subprocess.run(["security", "find-generic-password", "-s", s], capture_output=True, text=True, check=True)
       return re.search(r'"acct"<blob>="([^"]*)"', r.stdout).group(1)
   
   def pw(s):
       r = subprocess.run(["security", "find-generic-password", "-s", s, "-w"], capture_output=True, text=True, check=True)
       return r.stdout.rstrip("\n")
   
   a, old = acct(S), pw(S)
   subprocess.run(["security", "add-generic-password", "-U", "-s", B, "-a", a, "-w", old], check=True)
   assert pw(B) == old, "backup mismatch, stopping before overwrite"
   subprocess.run(["security", "add-generic-password", "-U", "-s", S, "-a", a, "-w", pw(L)], check=True)
   print("items identical now:", pw(S) == pw(L))

   Caveats: this only syncs the stores for now. Running sessions keep refreshing just the legacy item, so the two drift apart again and the script has to be re-run. It also passes the credential JSON as a security argument, so it is briefly visible in ps on the local machine.

   Fix suggestion

   +1 to resolving per server key instead of throwing. When candidates conflict, keep the grant with the latest expiresAt (the access/refresh pair stays atomic because the whole grant object is chosen), and log the disagreement. A connector conflict should never block a launch, because the claudeAiOauth login agreed across all stores in my case too. Happy to test a build.
3. ggbdpq commented on Oct 11, 2026

   

   ggbdpq

   on Oct 11, 2026

   Contributor

   More actions

   For anyone landing here from a search: the rejecting comparison does not exist on current main anymore. It came in with #21931 (shared-credential-fields.ts, "resolve per server key or throw"), and the per-account folders re-land #26801 (Oct 9) removed that module and the shared-credential sync entirely, so main has no "live connector credentials conflict" throw left. Builds cut before the re-land (including 1.4.223/1.4.224) still carry it. If you can reproduce this on a build that includes #26801, please comment with the version and I or someone else can reopen the investigation.

   👍React with 👍1Reacted by Santiago Aguirre
4. nwparker commented on Oct 11, 2026

   

   nwparker

   on Oct 11, 2026

   Last edited by nwparker

   Contributor

   More actions

   Already fixed on main by #26801 , which removes the code that throws. It ships in the next release.

   Sorry for the issues!
5. nwparker

   closed this as completedon Oct 11, 2026
6. Jinwoo-H

   marked [Bug]: Cannot switch Claude accounts: live connector credentials conflict; existing authorizations were preserved #28118 as a duplicate of this issue on Oct 13, 2026