A Desktop Chat conversation used as an orchestrator cannot be woken by anything

Summary

A Chat/Cowork conversation in Claude Desktop makes a good orchestrator: it dispatches work to Claude Code sessions through a local stdio MCP server, reads back their state, and gates. What it cannot do is learn that the work finished. Nothing can cause that conversation to start a new turn, so a human has to sit at the machine and press Enter for every completion.

Both plausible wake-up paths are closed, for different reasons, and neither is a configuration problem.

What I measured

1. MCP server-to-client notifications produce no host reaction.

A local stdio MCP server sent notifications/message and notifications/tools/list_changed to Claude Desktop. Neither produced any observable host behaviour — no turn, and no unprompted tools/list that would show the host had even read the notification. The host log records only the resources/read it requested itself.

2. An MCP Apps (io.modelcontextprotocol/ui) frame runs, paints, and can call tools — but still cannot cause a turn.

The frame reported hostInfo.name=Claude, negotiated protocol 2026-01-26, displayMode=inline, visibilityState=visible, and after a ui/message round trip painted=true with rafCount=142. It calls tools/call autonomously every ~2s and its results reach the server reliably. So a completion is detectable from inside the host, and can be displayed — it just cannot make the conversation act on it.

3. Cross-session messaging does not apply to a Chat conversation at all.

ListAgents / SendMessage address Claude Code sessions, which register on disk and bind an inbox socket. A Desktop Chat conversation binds no socket and appears in no agent list, so it is not addressable. Opening a Code session in Desktop makes that session addressable, but the orchestration context lives in the Chat conversation, so this does not help.

Notably this is not an OS difference: since cross-session messaging is unavailable on native Windows, one might expect the Linux Desktop build to behave differently here. It does not — the blocker is Chat vs. Code, not the platform.

Why this matters

The docs describe the desired behaviour for Code sessions: "When the receiving session is idle, Claude Code starts a new turn with the message." That is exactly what an orchestrator needs. There is no equivalent for a Chat conversation, which leaves an orchestrator built on one structurally dependent on a human keystroke — even though the completion signal has already arrived inside the host and been rendered.

The only workaround is to move the orchestrator into a Claude Code session, which gives up the Chat/Cowork surface (Dispatch, artifacts) for what is otherwise a Chat-shaped task: dispatching, reviewing, and gating rather than writing code.

Possible directions

Any one of these would be enough:

• Let a Chat/Cowork conversation be a cross-session messaging target, so SendMessage can reach it and the existing idle-starts-a-turn behaviour applies.
• Define an opt-in host behaviour for a server-initiated MCP notification: an MCP server the user has already installed and connected could request a turn, subject to the same approval model as any other inbound message.
• Let an MCP Apps frame request a turn in its host conversation, since it already runs as a live client there and can call tools.

Environment

• Claude Code 2.1.228
• Claude Desktop 1.26832.0 (Linux beta; the same MCP behaviour is expected on Windows, since the limitation is protocol-level rather than platform-level)
• Local stdio MCP server, zero dependencies, negotiated protocol 2026-01-26