bypassPermissions + allow rules ignored for reconnected MCP server tools; per-call permission dialogs

Summary

After the Claude Code desktop app restarts (or an MCP server such as the claude-in-chrome extension reconnects mid-session), every tool call to that server raises a permission dialog, even though permissions are configured to allow them at every scope.

Configuration (verified on disk while reproducing)

• ~/.claude/settings.json: "defaultMode": "bypassPermissions" and "mcp__claude-in-chrome__*" in the allow list
• project .claude/settings.local.json: individual allow entries for each claude-in-chrome tool used (tabs_context_mcp, get_page_text, read_page, find, computer, form_input, browser_batch)

Observed behavior

• Every mcp__claude-in-chrome__* call prompts. The dialog renders while the composer visibly shows "Bypass permissions" mode (screenshot available on request; not attached because it contains private session content).
• Dialogs are per-call: "Allow once" does not stop the next call to the same tool from prompting.
• "Always allow" does not persist across the next reconnect.
• Restarting the app does NOT clear the state; after restart the prompts resume on the first browser tool call.
• Built-in tools (Bash, Read, Edit, Write) respect the config and never prompt. Only reconnected MCP server tools are affected.

Reproduction

1. Set defaultMode: bypassPermissions plus a server wildcard allow rule.
2. Start a session, use any claude-in-chrome tool (no prompt, as expected).
3. Restart the desktop app and resume the session (MCP servers disconnect and reconnect).
4. Call any claude-in-chrome tool: permission dialog appears on every call.

Impact

First observed 2026-08-14, reproduced 4 separate times since across app restarts. Repeated dialog storms during time-sensitive interactive work; in our case the session had to abandon browser automation entirely mid-task.

Environment

• macOS (Darwin 25.5.0)
• Claude Code desktop app, resumed interactive sessions
• MCP server: claude-in-chrome (Chrome extension); also observed rule-matching loss for other reconnected MCP servers (scheduled-tasks) on 8/14