Claude in Chrome: stale per-session domain deny persists with no re-prompt; survives Chrome restart, machine restart, re-pair and permission revoke/re-allow

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?

The Claude in Chrome extension's navigate tool returns "Navigation to this domain is not allowed" for riverside.com / riverside.fm in a session where the domain had previously been used successfully, and no approval prompt is ever surfaced to the user again.

Observed on 7+ attempts across three permission states (allowed, revoked-clean, re-allowed). The deny survived: new windows/tab groups, site logout/login, revoking and re-allowing the domain, full Chrome quit/restart, a full machine restart, and a fresh extension pairing (new device id). list_connected_browsers showed exactly one healthy paired instance throughout, so calls were reaching the live browser.

Workaround that fixed it: quit Chrome, move the extension's storage dir (~/Library/Application Support/Google/Chrome/Default/Local Extension Settings/fcoeoabgfenejglbffodgkkbkcdhcgfn) aside, relaunch, re-pair. The domain then navigated cleanly.

KEY DETAIL: the fix appears to be per app-session. After the storage rebuild, the Claude Code session that made the next touch navigates the domain freely, while a DIFFERENT concurrent session's navigate calls to the same domain still return the identical deny, also with no prompt. Before the storage move, strings over the extension's LevelDB showed riverside entries present, consistent with a stored approvals/deny record that navigation attempts consult but never re-prompt on.

What Should Happen?

A domain that is not currently approved should surface the approval prompt (needsPrompt: true) rather than a silent hard deny, and a user-initiated revoke/re-allow or a full restart should clear any stale deny state. Users should never be in a state where nothing ever asks them for approval and no UI exists to clear the block.

Error Messages/Logs

Steps to Reproduce

1. Use Claude in Chrome (extension 1.0.81) paired with Claude Code Desktop (macOS, July 2026) in a session where a domain (here riverside.com) has an entry in the extension's stored site approvals.
2. From an agent session, call mcp__claude-in-chrome__navigate to that domain.
3. Observe "Navigation to this domain is not allowed" with NO approval prompt shown in Chrome.
4. Try: new tab group, logout/login on the site, revoke + re-allow the domain, quit and restart Chrome, restart the machine, re-pair the extension. Repeat step 2 after each — same silent deny every time.
5. Quit Chrome, move the extension's Local Extension Settings folder aside, relaunch, re-pair, retry: the session that touches the domain next now navigates fine, but other concurrent sessions may still receive the same silent deny.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code Desktop app (macOS), July 2026 build, with Claude in Chrome extension 1.0.81 — issue is in the extension/desktop pairing, not the CLI

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment: Claude Code Desktop on macOS (Darwin 25.5.0), Claude in Chrome extension 1.0.81 (fcoeoabgfenejglbffodgkkbkcdhcgfn), Google Chrome, July 2026.

Impact: the affected session's browser automation is dead for that domain with no user-visible recovery; we cycled logins and restarts for a morning because nothing ever prompted. Deleting extension storage (losing all site approvals and pairing) was the only local fix found, and it only heals the session that touches the domain next.

Note: the claude.ai settings page referenced in some related issues (claude.ai/settings/browser-extension) does not exist on this account's plan, so no UI route to inspect or clear per-domain state was available. Happy to provide further diagnostics.