session_info MCP tools (list_sessions, read_transcript) missing from Cowork sessions since 9/22–23

[Mackspower]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

A recurring nightly scheduled Cowork task depends on two in-session MCP tools, mcp__session_info__list_sessions and mcp__session_info__read_transcript, to archive the day's Cowork chat sessions to an Obsidian vault. These tools were available and working through 2026-09-22. Starting 2026-09-23 they stopped appearing entirely — not loaded, not in the deferred tool list, not returned by ToolSearch under any keyword phrasing tried.

This affects both scheduled Cowork task sessions and interactive Cowork sessions on the same account. Confirmed missing in a live interactive session as recently as today, 2026-09-28, run repeatedly over roughly two hours with identical results each time.

What Should Happen?

The session_info MCP tools should be available in Cowork sessions the same way they were before 2026-09-22, letting a session list and read transcripts of the account's own Cowork sessions for archiving purposes.

Error Messages/Logs

No error is returned. ToolSearch simply reports "No matching deferred tools found" for every phrasing tried, and the tool never appears in the session's deferred-tool list even as other MCP servers (Gmail, Google Calendar, Google Drive, remote-devices) visibly connect and disconnect throughout the same session. Example:

ToolSearch(query: "session_info list_sessions read_transcript", max_results: 10)
→ "No matching deferred tools found"

Steps to Reproduce

1. In a Cowork session on this account (scheduled or interactive), call ToolSearch with a query for session_info, e.g. query: "session_info list_sessions read_transcript".
2. Observe the result: "No matching deferred tools found" — no partial match, no "connecting" state, nothing in the deferred tool list.
3. Compare against other MCP servers in the same session (Gmail, Google Calendar, Google Drive, remote-devices), which do appear, connect, and reconnect normally over the course of the same session.
4. Repeat on a different day/session — result is identical every time since 2026-09-23.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A (Cowork, not Claude Code CLI) — last confirmed working the night of 2026-09-22

Claude Code Version

N/A — this is Cowork (claude.ai), not the Claude Code CLI, so claude --version doesn't apply. For reference, the linked desktop app build is 2.9939.2 (dated 2026-09-24 per Anthropic's own changelog).

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Timing lines up with the Cowork/chat merge rollout (announced 2026-09-16, app build 2.9939.2 dated 2026-09-24 in Anthropic's changelog) — this outage started 2026-09-23, one day before that build. Two other open issues describe the same pattern (a tool/connector that works in interactive sessions but is missing or stripped down in scheduled/headless sessions) from the same rollout window, on different tools:

• Scheduled cloud routines / cowork (headless) expose only a partial MCP connector toolset #79746 — scheduled cloud routines exposing only a partial MCP toolset
• claude.ai-hosted MCP connectors intermittently expose zero tools in headless launchd/claude -p sessions #96106 — hosted MCP connectors exposing zero tools in headless sessions

Also reported via in-app Cowork support (Get Help → Fin); the ticket was escalated to a human agent, conversation ID 215476138448139. That channel has no status tracking or ETA, hence filing here as well.

Note: several fields above (Claude Code Version, Terminal/Shell) don't cleanly apply since this is Cowork, not the Claude Code CLI — answered N/A or left at template default where forced.

[stonianua]

Useful regression note — especially the hard cut after 2026-09-22 and ToolSearch returning “No matching deferred tools found” while Gmail / Calendar / Drive / remote-devices still connect in the same Cowork session. A few peer checks that have helped on similar “tool vanished after Cowork/chat merge” cases:

1. Confirm whether session_info is still registered as a connector at all, vs only stripped in Cowork. In an interactive non-Cowork Claude.ai chat on the same account, run the same ToolSearch (session_info, list_sessions, read_transcript). If it appears there but never in Cowork (scheduled or interactive), this is a Cowork-surface allowlist / merge regression, not an account-wide connector drop. If it is missing everywhere, look for a silent connector uninstall or rename in Settings → Connectors after the 9/22–23 window.

2. Differentiate “deferred but unloaded” from “not in the catalog.” When other MCP servers flicker connect/disconnect in the session UI, note whether session_info ever shows a row (even disconnected / 0 tools). Your write-up already says it never appears in the deferred list — that usually means the host never offered the server to that session type, not that ToolSearch failed to hydrate a deferred entry.

3. Cross-check the two sibling patterns you linked. Scheduled cloud routines / cowork (headless) expose only a partial MCP connector toolset #79746 (partial MCP toolset in scheduled cloud routines) and claude.ai-hosted MCP connectors intermittently expose zero tools in headless launchd/claude -p sessions #96106 (hosted MCP connectors exposing zero tools in headless sessions) are the same family: interactive attach looks healthy, headless/scheduled/Cowork surfaces get a reduced catalog. If list_sessions / read_transcript still work from a normal Code session but not Cowork, call that out — it pins the bug on session-class filtering rather than Obsidian / vault-side code.

4. Avoid relying on ToolSearch alone for the bug report. If you can, paste one redacted session startup snippet (or connectors panel screenshot description) from a failing Cowork session showing the other four servers present and session_info absent. That is stronger than keyword misses, which can also happen when a tool was renamed or moved behind a different MCP server id.

5. Interim archive path. Until session_info returns, the practical workaround people have used is exporting/copying from the Cowork UI history (or any official export) on a manual cadence, and keeping the nightly job’s “archive” step fail-loud when ToolSearch returns zero matches — so SUCCEEDED/empty does not look like a clean archive night.

If you get one interactive non-Cowork hit where list_sessions still works after 9/23, that single A/B is the highest-signal note for whoever owns the Cowork merge allowlist.

[Mackspower]

Thanks — working through each point:

1 & 3 (test from non-Cowork chat / Claude Code CLI): Can't cleanly test either. My account is under the Cowork/chat merge already linked in this issue (announced 9/16, "Cowork and chat into one Claude"), so there may not be a distinct non-Cowork surface left to test against. And I don't run Claude Code CLI — Cowork only. If someone with CLI access wants to check list_sessions/read_transcript there, that'd be a useful data point I can't generate myself.

2 (deferred-but-unloaded vs. not-in-catalog): Confirmed — session_info has never shown a row at all (connecting, 0 tools, disconnected) across ~10 checks over two days, while other servers visibly cycle through connect/disconnect/reconnect in the same session.

4 (concrete evidence over keyword misses): Here's a real example from tonight's session:

153 deferred tools are available again (MCP server reconnected — names announced earlier in this conversation): mcp__Gmail__* (30), mcp__Google_Calendar__* (9), mcp__Google_Drive__* (11), mcp__remote-devices__* (103).

Fired multiple times as those four servers reconnected. session_info was never in any reconnect announcement, and ToolSearch right after each one still returned "No matching deferred tools found."

5 (fail-loud archiving): Already in place — the nightly task has logged an explicit "BLOCKED" note every night since 9/23 rather than a silent empty success.