[BUG] 1Password for Claude: autofill_credential always tab_unavailable / agenticModeNotEnabled from Claude Code sessions in the desktop app (14/14, 0 filled)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 17, 2026

Summary

With 1Password for Claude paired and healthy, request_credentials succeeds (approved, and list_granted_credentials lists the item), but every autofill_credential call from a Claude Code session in the desktop app returns tab_unavailable. The desktop-app log shows the fill's tab attach being immediately compensated by a detach ("ended session"), and 1Password's extension reporting partnerCode: 'agenticModeNotEnabled'.

14 of 14 fill attempts ever logged on this Mac (8/11, 8/16, 8/17) settled tab_unavailable / agenticModeNotEnabled; zero status: 'filled'. Re-pairing the connector today (pairing succeeded { partnerId: 'onePassword' } at 11:03) did not change the outcome — pairing was never the failing half.

This is a different symptom from #79976 (that one fails at pairing with not_connected); here pairing and consent work and only the fill fails.

Environment

  • macOS 26.6.1, Apple Silicon
  • Claude desktop app 1.30096.5 (Claude Code session inside the desktop app; Chrome tools via mcp__claude-in-chrome__*)
  • Claude in Chrome extension 1.0.85 (current Web Store version)
  • 1Password for Mac 8.12.33; 1Password Chrome extension 8.12.32.33 (≥ 8.12.28 required); extension integrated with the desktop app, "Integration status: Connected"
  • 1Password settings.json shows appPairing.agenticAutofill.pairedApps = Claude; single Chrome profile active; personal (individual) 1Password account, no business policy
  • The Claude extension and the 1Password extension are in the same Chrome profile

Steps to reproduce

  1. In a Claude Code session (desktop app), call request_credentials for a login item (e.g. huckberry.com), before navigating. → {"status":"approved"} after clicking Approve in the 1Password prompt.
  2. tabs_context_mcp {createIfEmpty:true} → new tab in the MCP group → navigate to https://huckberry.com/account/loginread_page confirms the login form (email field) is present. Tab is frontmost and the only tab in the group.
  3. autofill_credential (no credentialId). → {"status":"tab_unavailable"}. Retrying returns the same. (no_active_tab also seen on 8/16 when trying from the built-in Browser pane instead of the Chrome tab.)

Log (~/Library/Logs/Claude/main.log, today, UUIDs redacted)

11:07:20 [grand-prix] credential request dispatch { entries: 1, requestedAheadOfNavigation: true }
11:07:23 [grand-prix] ext request settled { entries: 1, status: 'approved' }
11:07:44 [grand-prix] ext fill dispatch { explicitItem: false, tabId: 661742065, hasOrigin: true }
11:07:44 [grand-prix] fill: re-relaying tab attach { sessionId: 'local_<uuid>', tabId: 661742065 }
11:07:44 [grand-prix] fill: compensating detach for ended session { sessionId: 'local_<uuid>', tabId: 661742065 }
11:07:44 [grand-prix] ext fill settled { status: 'tab_unavailable', partnerCode: 'agenticModeNotEnabled', tabId: 661742065 }
11:07:56 [grand-prix] ext fill dispatch { explicitItem: false, tabId: 661742065, hasOrigin: true }
11:07:56 [grand-prix] fill: re-relaying tab attach { sessionId: 'local_<uuid>', tabId: 661742065 }
11:07:56 [grand-prix] fill: compensating detach for ended session { sessionId: 'local_<uuid>', tabId: 661742065 }
11:07:56 [grand-prix] ext fill settled { status: 'tab_unavailable', partnerCode: 'agenticModeNotEnabled', tabId: 661742065 }

grep -c "status: 'filled'" ~/Library/Logs/Claude/main*.log → 0 across all rotated logs.

Reading of the log

1Password's extension only enters Agentic Mode while the Claude extension holds a live browser session attached to the tab. From a Claude Code session the browser session appears to end when each tool call returns (the Chrome banner "Waiting for Claude to finish the current task…" flickers per call), so the fill's re-relaying tab attach is immediately followed by compensating detach for ended session, and 1Password reports agenticModeNotEnabled. Nothing user-side (versions, pairing, profile, permissions) changes this.

Expected

autofill_credential returns filled on the approved item's login page, as it does in Cowork / claude.ai flows.

View original on GitHub ↗