[BUG] Resumed cloud routine session: connector tools de-registered and never restored (the MCP half of #81822)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [ ] I am using the latest version of Claude Code — the failure is in a cloud routine session, so the local CLI version (2.1.41) is not the executing version; I have no way to see the cloud-side build.

What's Wrong?

In a resumed session on a cloud routine, an enabled connector (Linear) reports as connected but none of its tools are reachable. The session never recovers — the empty tool index persists for the life of the session. A fresh run of the identical routine works normally.

Environment: Claude Desktop, macOS. Cloud routine ("Auditor"), daily schedule, Linear connector enabled at routine level, network access Full. Model Sonnet 5, High.

Repro

1. Cloud routine with a remote HTTP MCP connector (Linear).
2. Resume an existing session for that routine — header shows "Resumed session".
3. Ask for any task requiring the connector's tools.
4. No connector tools are reachable. Retrying, rephrasing, and starting new turns in the same session all fail identically.
5. Trigger the same routine via Run now — header shows "Initialized session", 15 Linear tool calls succeed, task completes.

What Should Happen?

A resumed session should re-establish MCP tool registration, or surface a recoverable error. Currently the connector reports connected, the tool index is empty, and there is no recovery path from inside the session.

Relationship to #81822 — this is the MCP half of the same resume-time drop

#81822 documents plugin agents de-registering on session resume, and contains a transcript of the MCP side of that same moment:

• 14:32:48 on resume — deferred_tools_delta: −259 claude.ai connector tools
• 14:33:18 on reconnect — deferred_tools_delta: +190

That issue treats the MCP reconnect as the working control case ("MCP servers reconnect; plugin agents should have an equivalent"). But 259 tools were removed and only 190 came back — the MCP restore path is itself lossy, by 69 tools, in the very transcript used as the healthy comparison.

This report is the degenerate case of that same asymmetry: the resume-time drop occurred and the restore returned nothing usable. That suggests the fix for #81822 ("agents need a reconnect path like MCP has") is built on a path that does not reliably work either, and that both should be treated as one class of bug: registry state is rebuilt on resume without verification that it matches pre-resume state.

Not a duplicate of #79319

#79319 is a different failure: connectors explicitly enabledInChat: false, correctly diagnosed and reported by the model. Here the connector reports connected, and the tool index is silently empty.

Additional notes

• /context in the broken session showed System tools (deferred) at 17.2k — low for the connector set. Context was at 17% of 967k, so this is not budget exhaustion.
• Scheduled runs are unaffected (each initialises fresh). Seven consecutive scheduled runs completed successfully during the period the resumed session was broken.
• This is a registration failure, not a tool-search failure. Verified by contrast in a healthy session of the same shape (deferred tool loading, connector attached, connector directory present): searches for the connector name, for a tool name, and for a name-filtered query all returned the correct tools. When the index is populated, lookup works fine.

Asks

1. Verify post-resume tool registration against pre-resume state, and retry or fail loudly on mismatch — do not leave a silently short index.
2. Surface a recoverable error, or a re-scan command, so a resumed session is not dead for its lifetime.
3. Log the removed/restored tool counts somewhere inspectable; the −259/+190 asymmetry in #81822 was only visible through transcript archaeology.