[BUG] Desktop app Browser pane: read tools blocked with "requires per-action approval" even though domain is in launchPreviewAllowedOrigins, restart does not clear it

Environment

• OS: macOS Darwin 25.5.0
• Claude Code CLI: 2.1.215
• Claude desktop app (Electron), installed at /Applications/Claude.app
• Permission mode: bypassPermissions (confirmed via session state file)

Summary

Browser pane MCP tools (mcp__Claude_Browser__*) behave inconsistently for a domain explicitly listed in the desktop app's site allowlist:

• preview_start / navigate to the domain succeeds.
• Every read/interact tool (computer screenshot, read_page, get_page_text, read_console_messages) fails with:

> This site requires per-action approval; Browser read tools are not available on it.

• No approval prompt/card ever renders anywhere in the app for this domain.

Steps to reproduce

1. Add a local-network-only custom domain to Settings → Allowed sites (e.g. http://internal-host.example, https://proxy.internal-host.example). Confirm entries appear in the dialog.
2. Confirm the entries are persisted to ~/Library/Application Support/Claude/claude_desktop_config.json under preferences.launchPreviewAllowedOrigins (verified present, correct, exact match to what's typed in the UI).
3. Call preview_start or navigate to that origin from an active session — succeeds, tab opens, title/URL correct.
4. Call computer (screenshot), read_page, or get_page_text on that tab — fails every time with the error above.
5. Fully quit the app (Cmd+Q) and relaunch. Confirm new process start time is after the config file's last-modified time (i.e. this is not a stale-startup-cache issue). Repeat step 3-4 — same failure.

Expected behavior

If a domain is listed in launchPreviewAllowedOrigins, Browser pane read/interact tools should work on it without per-action prompting — matching what the "Allowed sites" UI copy states ("Claude can use its Browser tools on these sites without a permission prompt").

Actual behavior

Navigation is allowlisted and works; every subsequent read/interact call on that same tab is unconditionally blocked with no prompt ever offered, regardless of permission mode (tried bypassPermissions) or app restart.

Evidence collected

• Config key confirmed correct: preferences.launchPreviewAllowedOrigins contains the exact origins used in reproduction (four entries: two hostnames, each with an http and/or https variant).
• Session state file (~/Library/Application Support/Claude/claude-code-sessions/.../local_<id>.json) confirms "permissionMode":"bypassPermissions" for the session making these calls.
• Restart does not help — main Claude.app process start time (14:57:24) is after the config write time (14:52:02), ruling out startup-time cache staleness.
• Behavior is consistent across fresh tabs (tabs_close + tabs_create + navigate), ruling out per-tab stale state.

Related issues

• #78315 — near-identical report, closed as "invalid" / "doesn't seem to be related to Claude Code," no redirect to correct repo given.
• #61611, #53630, #57219 — related but describe the separate Claude in Chrome browser-extension permission system (real Chrome, chrome.debugger.attach), not the desktop app's built-in preview/Browser pane used here. Root cause identified there (PermissionManager race) does not appear applicable to this subsystem.

Ask

Given #78315 was closed as out-of-scope without redirection, please advise the correct repo/tracker for desktop-app Browser-pane preview-tool bugs if this one isn't it.