[BUG] "Always allow" fails to persist on avito.ru (works on other domains)

Preflight Checklist

• [x] I have searched existing issues — this overlaps #74715; see "Relationship to #74715" below
• [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?

Claude for Mac 1.22209.3, Claude Code 2.1.215, macOS 25.5.0, Chrome extension fcoeoabgfenejglbffodgkkbkcdhcgfn.

Choosing "Always allow" on the browser permission dialogs — "Allow Claude to navigate to \<domain\>?" and "Allow Claude to read page content on \<domain\>?" — never persists. Every subsequent browser tool call on the same domain raises the dialog again.

Two get_page_text calls on the same page, 35 seconds apart, pressing "Always allow" both times, each raised a prompt and each wrote its own one-time grant:

36c9eb50  22:24:18  duration=once  https://www.avito.ru
c8d24149  22:24:53  duration=once  https://www.avito.ru

Across 18 days of ordinary use, all 60 grants recorded for avito.ru are duration:"once"; zero persistent grants exist. The live permissionStorage array is reset to [] after every grant, so nothing is ever retained.

Relationship to #74715

This is very likely the same defect as #74715, which identifies the root cause: the post-dialog resume handler in assets/mcpPermissions-B0h6Fctz.js hardcodes MT.ONCE when calling grantPermission, discarding the duration the user selected. Close this as a duplicate if you prefer.

The reason for filing separately is the version: #74715 was reported against 2.1.201, and the forensics here are from 2.1.215 — fourteen releases later, unchanged. If that is already known, this issue adds nothing and should be closed.

Correction to an earlier framing

An earlier draft of this report described the bug as specific to avito.ru, based on a control test where example.com appeared to retain the grant. That control was invalid. Per #78315, well-known public domains appear to bypass the permission gate entirely, so example.com was never gated and its apparent "persistence" proved nothing. The defect is domain-independent; avito.ru is simply the only site this user drives through the Chrome extension, because it blocks non-RU IPs and cannot be reached by the built-in browser.

Notes

• The dialog fires even while the session is in "Bypass permissions" mode.
• No settings.json rule affects it: permissions.allow: ["mcp__claude-in-chrome"] has been set since 2026-07-02 and covers the tool, not the domain gate.
• Related but distinct: #67020 (per-action click/type dialogs), #55124 (Cowork JS execution), #30356 (scheduled tasks, closed not-planned).

What Should Happen?

Choosing "Always allow" should write a persistent grant for that domain, so subsequent tool calls on the same domain do not prompt again, and the extension's "Your approved sites" list is populated.

Observed instead: the grant is stored as duration:"once", consumed immediately, and the approved-sites list stays empty regardless of how many times "Always allow" is pressed.

Error Messages/Logs

Grants written to key `permissionStorage` (Chrome extension Local Extension Settings):

  36c9eb50  22:24:18  duration=once  https://www.avito.ru
  c8d24149  22:24:53  duration=once  https://www.avito.ru

Both were "Always allow" presses. Both stored as duration:"once".

Record schema:
{"action":"allow","createdAt":<ms>,"duration":"once","id":"<uuid>",
 "origin":"https://www.avito.ru",
 "scope":{"netloc":"www.avito.ru","type":"netloc"},
 "toolUseId":"<uuid>"}

The live array is reset to [] after every grant. All 60 grants for avito.ru
accumulated over 18 days of normal use are duration:"once"; zero persistent.
No Sync/Managed/IndexedDB storage exists for the extension.

Steps to Reproduce

1. Navigate to a site that is subject to the permission gate (here: https://www.avito.ru) through the Claude Chrome extension.
2. Call get_page_text on that tab. At the prompt, choose "Always allow".
3. Call get_page_text on the same tab again, without navigating away.
4. The permission dialog reappears, and a second duration:"once" grant is written.
5. Inspect the extension's "Your approved sites" list — it remains empty.

Note: example.com is not a valid control, as it appears to bypass the gate entirely (see #78315).

Claude Model

Opus 4.8

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.215

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other — Claude for Mac desktop app 1.22209.3 (not a terminal)

Additional Information

Reproduced in the Claude for Mac desktop app, not a terminal. The dialog is rendered by the app or the extension, not the CLI: the Claude Code 2.1.215 binary at ~/Library/Application Support/Claude/claude-code/2.1.215/claude.app/Contents/MacOS/claude contains none of the dialog's strings — no "Always allow", "Allow once", "read page content on", "netloc", or "permissionStorage".

Version note for triage: which claude on this machine resolves to an unused standalone install at ~/.local/share/claude/versions/2.1.12. The app runs its own copy at ~/Library/Application Support/Claude/claude-code/2.1.215/, confirmed by walking the live process tree. The version reported here is the one actually serving the session.