1Password credential-request (Claude in Chrome) fails with 'not_connected' despite healthy 1Password app/extension

Same issue here — sharing my environment and some extra debugging detail in case it helps.

Environment

• macOS (Darwin 25.5.0), Apple Silicon
• Claude desktop app 1.24012.9 (Max plan)
• Claude in Chrome extension 1.0.81 (current Web Store version), signed in to the same account as the desktop app
• 1Password for Mac 8.12.28, unlocked; 1Password Chrome extension 8.12.28.25 in the same Chrome profile
• 1Password extension setting "Integrate with the 1Password desktop app" = ON, integration status: connected
• Claude Settings > Connectors shows 1Password as connected (Desktop); 1Password's settings.json contains the appPairing.agenticAutofill.pairedApps record for com.anthropic.claudefordesktop

Symptom

• From a Claude Code session, request_credentials always returns {"status":"transport_error","reason":"relayUnavailable"} (fails within ~1 second, ~10+ attempts over 2 days).
• From a Cowork task (the officially documented test path), the credential request fails with local_browser_unavailable at the login page.
• Disconnect/reconnect of the connector, Chrome restart, Claude app restart, and a full macOS reboot did not change anything. op desktop integration and normal 1Password autofill work fine.

Debugging detail that may help

• Claude's main.log shows [grand-prix] credential request dispatch followed immediately by ext request settled { status: 'transport_error' } on every attempt.
• 1Password's log shows its agentic-autofill local HTTP server listening and a mycelium channel being created/joined at Claude session start, so the 1Password side appears healthy.
• The Claude in Chrome extension's local storage contains no partner extension IDs (nothing matching the 1Password extension ID aeblfdkhhhdcdjpifhhbdiojplfjncoa), which looks consistent with the relay failing with no_target — as if the partner extension-ID config pushed via pushExternalConfig never arrives for this account/surface.

Happy to provide more logs if useful.

Confirming this on a current stack, and independently reproducing @ksato-tech's missing-partner-ID finding — still present nine extension versions later. Flagging because the issue is marked stale but reproduces on current versions of everything.

Environment

• Claude desktop app 1.44121.4 (Electron 42.10.0); Cowork session linked to a local Mac
• macOS 26.4.1, Apple Silicon
• Chrome 152.0.7977.77; Claude in Chrome extension 1.0.90
• 1Password desktop app and Chrome extension installed in the same profile, healthy throughout

Symptom

Matches the local_browser_unavailable variant @ksato-tech reports from Cowork. Both request_credentials and list_granted_credentials return {"status":"unavailable","reason":"local_browser_unavailable"}. No consent prompt is ever displayed, so this fails earlier than #87365 (where consent succeeds and only the fill fails).

Pairing is not the failing half. Before approving the Connect banner the call returned not_connected with actionable text. Immediately after approving, every call returns local_browser_unavailable. The handshake lands; everything downstream of it fails.

Identical result across every configuration tested:

• the desktop app's built-in Browser pane
• Claude in Chrome, remote machine's browser selected
• Claude in Chrome, local machine's browser selected (verified genuinely local via AppleScript — see #78096)
• after a fresh switch_browser re-pair handshake

With Chrome fully closed the error changes to transport_error/decode, then transport_error/retryable on retry — which places the failure in the Chrome-extension relay rather than the desktop app.

Reproducing the missing partner extension ID on v1.0.90

Same check @ksato-tech describes, against the Claude extension's Local Extension Settings:

CL=fcoeoabgfenejglbffodgkkbkcdhcgfn
OP=aeblfdkhhhdcdjpifhhbdiojplfjncoa
strings "$HOME/Library/Application Support/Google/Chrome/Default/Local Extension Settings/$CL"/* | grep -c "$OP"

Result: 0.

Meanwhile strings … | grep -oiE 'partner[A-Za-z]*|externalConfig|agentic[A-Za-z]*' returns 14 hits, all agentic. So agentic-mode config is present but no partner extension ID accompanies it — consistent with the relay failing no_target.

Possible unifying reading

If the partner ID never reaches the Claude extension, 1Password is never told Claude is a partner. That would also explain #87365, where 1Password reports partnerCode: 'agenticModeNotEnabled' — each surface failing at whatever stage it happens to reach, from one missing piece of config.

Worth noting that nothing user-side moves this: re-pairing, restarting Chrome, restarting the app, switching browsers, and updating versions all leave it unchanged, which is consistent with config that is never delivered rather than config that is delivered and corrupted.

Correction to my comment above — the root cause I proposed was wrong.

I attributed this to the missing 1Password partner extension ID, reading it as the relay failing no_target. That observation was real, but it is not what causes the failure: the credential request completes fine while that ID is still absent.

The actual cause is now filed as #91969. The consent prompt is dispatched to a Chrome window the user cannot see, so it renders unseen, is never answered, and lapses. Opening the Claude side panel reveals a separate "Claude for Chrome" window showing "Waiting for permission request..." — after which request_credentials returns {"status":"approved"} on the first attempt with no other changes.

That also accounts for the one detail I could not explain: retryable and decode alternating non-deterministically across identical calls. That is a single unanswered consent request timing out differently, not two distinct transport faults. Reading them as transport faults is what sent me looking at 1Password, which is healthy throughout.

Two further corrections to what I wrote here: the failure is not Cowork-specific — it reproduces in claude.ai web chat — and 1Password itself is not implicated at any point.

If you are stuck on this issue: open the Claude side panel before making the credential request. Please follow #91969 for the root cause.