[BUG] Cloud session resume after MCP disconnect re-prompts for MCP tools already allowed in committed .claude/settings.json (unattended routine runs hang forever)

[BUG] Cloud session resume after MCP disconnect re-prompts for MCP tools already allowed in committed .claude/settings.json (unattended routine runs hang forever)

Environment

• Claude Code cloud sessions (claude.ai routines, fired via POST /v1/claude_code/routines/<id>/fire)
• Repo checkout with committed .claude/settings.json permission allow-list and project-scoped .mcp.json (HTTP MCP server)
• Runs are API-triggered and unattended (no human watching the session)

Summary

A permission allow rule for an MCP tool (e.g. mcp__facturapp-prod__get_cfdi_portal_context in the repo's committed .claude/settings.json) is honored at session start, but after the MCP server disconnects mid-call and the platform resumes the session, the same tool re-prompts for permission as if it had never been allowed. Because routine runs are unattended, the run hangs on the prompt forever and piles up in "Running" state.

Observed sequence (single run transcript)

1. Session initializes, a repo skill is invoked.
2. First call to mcp__facturapp-prod__get_cfdi_portal_context executes without any permission prompt → the committed allow rule was loaded and matched.
3. Transcript: "The facturapp-prod MCP server disconnected mid-call. Let me check if it's reconnected before retrying."
4. Transcript: "Resumed session".
5. Immediately after the resume, a permission prompt appears: "Allow Claude to use get cfdi portal context (facturapp-prod)?" (Deny / Always allow / Allow once) — for the exact tool that ran promptless minutes earlier in the same session.
6. No human is attached to the run, so it hangs indefinitely; our 30-minute watchdog fires a fresh run, which eventually hits the same disconnect→resume→prompt path, so stuck "Running" runs accumulate (observed ~30-minute spacing matching the watchdog).

Example stuck session: session_01JyWCwLmbtrunfWAiPrNKgV (2026-07-03). Multiple occurrences daily since at least 2026-06-27.

Additional data points

• Clicking "Always allow" on these prompts does not persist across runs — the next run re-prompts again after its own disconnect/resume.
• Ruled out on our side: the allow-list is present on the default branch, entries match the prompted tool exactly (mcp__<server>__<tool> form), and the same rules demonstrably work at session start within the same run.
• A secondary anomaly in the same resume path: the routine's fire text (which always contains the target record id) was not visible to the session at start — the session first summarized "no ID found in the trigger message", and the trigger text only arrived after a later resume.

Expected behavior

Permission rules from committed .claude/settings.json should keep matching after an MCP server reconnect / session resume. An unattended cloud run should never regress from "allowed" to "prompting" for the same tool within the same session.

Possibly related

• #28580 ([BUG] MCP tools prompt for permission even when already authorized in permission settings — closed)
• #36308 (MCP servers should auto-reconnect when disconnected mid-session — closed)

Both are closed, but this reproduces on current cloud sessions as of 2026-07-03/04.