bypassPermissions + wildcard allow rule still ignored on the first MCP tool call after a desktop app restart (follow-up to #87358)

Follow-up to #87358, which the stale bot closed on 2026-09-19 with no maintainer response. The bot asked for a new issue if it is still relevant. It is: a reduced form reproduced on 2026-09-18.

What still happens

After the desktop app restarts and a session is resumed, the first tool call to a plugin / connector MCP server shows a permission dialog, even though the session is in bypassPermissions and (in one of the two cases) a matching wildcard allow rule exists.

What improved since #87358

The per-call dialog storm no longer reproduces. For the two servers named in #87358 (claude-in-chrome, scheduled-tasks) I measured 176 calls across resumed sessions since 2026-09-12, none waited on a dialog, including calls made minutes after an app restart. The prompt now appears once per server, not once per call.

Environment

• Claude desktop app 2.2553.1, macOS 26.6.2 (25G83)
• Log line at startup: [CCD] Initialized with version 2.1.271
• ~/.claude/settings.json: "defaultMode": "bypassPermissions", allow list includes mcp__plugin_google-tasks_google-tasks__*

Timeline (local time, 2026-09-18)

| time | event |
|---|---|
| 08:34:18 | app restarted (Starting app), existing session resumed |
| 08:36:07 | mcp__plugin_google-tasks_google-tasks__list_all_incomplete called. A permission dialog appeared. The call waited 54 s and was declined (tool result: "The user doesn't want to take this action right now"). This tool is covered by BOTH bypass mode and the wildcard allow rule above. |
| 09:08:05 | list_task_lists and create_task on the same server: 1 s and under 1 s, no dialog |
| 09:31:10 | first call to a claude.ai remote connector (not in the allow list, bypass mode only): waited 98 s on a dialog, approved |
| 09:32:52 | second call to that same connector, different tool: 1 s, no dialog |

Expected

No dialog in either case. bypassPermissions should cover every tool, and a matching allow rule should cover the plugin server's tools regardless of whether the server reconnected after an app restart.

Why it matters

A resumed long-running session that works unattended stalls on that first call until someone clicks. Built-in tools (Bash, Read, Edit, Write) never prompt in the same session.

How this was measured

Approved and declined dialogs leave no line in main.log, so silence in the log is not evidence of absence (I initially misread it that way). I measured the gap between each MCP tool_use and its tool_result in the session transcripts: 373 MCP calls since 2026-09-12, median under 2 s for every server, and exactly these two dialog-shaped waits (54 s, 98 s), both being the first call to their server after the restart. Other waits over 30 s were network timeouts on a different server, in 60 s multiples.

Ask

Honor bypassPermissions and matching allow rules on the first call to a reconnected plugin / connector MCP server after an app restart. If a dialog is intentional for connectors, log the reason it was shown so it can be told apart from a permissions bug.