Claude desktop app: private-network browser permission grants don't persist (regression since ~2026-08-20/21)

Note: this is about the Claude desktop app (Claude.app, version 1.34493.1), not the claude CLI — filing here since it's the repo I was pointed at; happy to have it redirected if there's a more appropriate tracker.

Bug: Private-network browser permission grants don't persist, since ~2026-08-20/21 update

Summary

Since a Claude desktop app update around 2026-08-20/21 (confirmed installed version 1.34493.1,
downloaded 2026-08-20 17:46:36 per ~/Library/Logs/Claude/main.log), the embedded Browser
pane's permission prompts for private-network / local-network targets (RFC1918 IPs, tailnet
IPs, plain hostnames like bigbrain) no longer persist, even when the user has explicitly
granted access. Every single browser action against such a host re-prompts, regardless of
prior grants. This makes any workflow that inspects a self-hosted/internal web app through the
Claude Browser pane (reading page content, clicking, typing, or even just navigating) generate
a fresh permission dialog on every single call.

Environment

• macOS, Claude desktop app version 1.34493.1
• Config store: ~/Library/Application Support/Claude/claude_desktop_config.json

(preferences.launchPreviewAllowedOrigins, launchPreviewPrivateNetworkReadOrigins,
launchPreviewPrivateNetworkReadPins)

Reproduction

1. Navigate the Browser pane to any private-network origin (e.g. http://bigbrain:1703,

a plain hostname resolving via /etc/hosts or mDNS to a LAN/tailnet address).

1. When prompted "Allow Claude to access <host>?", click "Allow once" (or, on a subsequent

read-content prompt, "Always allow reads on this host").

1. Confirm the origin is now recorded: `~/Library/Application Support/Claude/

claude_desktop_config.json → preferences.launchPreviewAllowedOrigins contains the exact
origin string (e.g. "http://bigbrain:1703"`).

1. Fully quit the app (Cmd+Q) and relaunch it.
2. In a new session, navigate the Browser pane to the same origin again.

Expected: no prompt, since the origin is already recorded as allowed.
Actual: "Allow Claude to access <host>?" fires again, identical to step 2, despite the
origin being present in launchPreviewAllowedOrigins.

The same failure reproduces for the read-content permission specifically:

1. Grant "Always allow reads on this host" for an origin (confirmed added to

preferences.launchPreviewPrivateNetworkReadOrigins, and self-pinned in
preferences.launchPreviewPrivateNetworkReadPins).

1. Fully quit and relaunch the app.
2. Read page content again on the same origin.

Expected: no prompt (per the dialog's own copy: "Saved for this site until you revoke it
in Settings").
Actual: "Allow Claude to read page content on <host>?" fires again, sometimes with the
"Site-level permissions are disabled for this site. You'll be asked for each action." variant
that offers no persistent option at all, on the exact same origin that was previously granted.

What I ruled out

• Not a .claude/settings.json (Claude Code CLI config) issue — no field in the full settings

schema governs browser/site permissions at all.

• Not a missing grant — directly inspected the preference store and confirmed the target

origins are present in every relevant list (launchPreviewAllowedOrigins,
launchPreviewPrivateNetworkReadOrigins, launchPreviewPrivateNetworkReadPins).

• Not a separate/competing permission store — checked the Browser pane's own Chromium session

partition (Partitions/launch-preview-static/Preferences) and its native
content_settings.exceptions; both empty. Checked the renderer's own LocalStorage/IndexedDB
in both browser-related partitions; no relevant keys found anywhere.

• Not fixed by manually editing the preference file to add missing grants and self-pins,

even combined with a full app restart — re-prompted immediately on the next navigation to an
origin that was already listed before the edit.

Impact

Any workflow that relies on visually inspecting or interacting with a self-hosted internal
tool through the Browser pane (rendering/regression checks against an internal app, reading
live debug state, clicking through an internal admin UI) now generates a permission dialog on
every single action, with no way to reduce the frequency. For a session doing repeated
visual-verification passes against one internal host, this can mean dozens of prompts in a
single work session, all requiring a manual click, with no working "always allow" option
despite the UI explicitly offering and appearing to record one.

Suggested area to investigate

The mismatch between "origin is recorded in preferences.launchPreview*" and "the runtime
permission check still fires" suggests either: (a) the enforcement code path reads from a
different source than what claude_desktop_config.json's preferences block persists to
(e.g. a session-scoped or in-memory-only check that isn't durably wired to the stored grant),
or (b) the grant-write path silently fails/doesn't reach whatever data structure the
enforcement path actually consults.