[BUG] Cowork Dispatch send_message no longer delivers to existing Cowork sessions (worked 461 times until Aug 10)

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)
• [x] I am using the latest version of Claude Code

What's Wrong?

This is about the Cowork Dispatch agent in Claude Desktop, not the Claude Code CLI.

Until 10 August, Dispatch could deliver messages into any of my existing local Cowork sessions via send_message. I used it daily to steer manually created per-project orchestrator chats from my phone. Now it refuses every target Dispatch did not spawn itself, while list_sessions and read_transcript still work on those same sessions - only writing is blocked.

From the Dispatch session own transcript:

• 468 send_message calls, 461 successful, across 11 distinct sessions
• only 12 start_task/start_code_task calls in the whole history, so most successful targets were never children
• local_02ac95d7-2049-4082-a851-e70b0e10dd47, created by hand in the UI, received 293 successful messages
• last success into a manual chat: 2026-08-10 17:30:52 UTC; first refusal: 2026-08-21 10:08:50 UTC

The error text changed too (below). The old wording pointed at list_sessions, i.e. any local session was a valid target.

What Should Happen?

send_message should keep delivering to any local Cowork session that list_sessions reports, as it did until 10 August.

If restricting it to spawned children is intentional, it should be documented, and there should be a supported way to address an existing session. Feature request #41273 asks for exactly this and was closed as not planned - my logs show the capability already existed then.

Error Messages/Logs

Before (up to 26 July 2026):
Session "..." not found. Use list_sessions to see available sessions.

Now (from 21 August 2026):
Session "..." not found. Valid session_ids are the ones returned by your start_task or start_code_task calls.

Steps to Reproduce

1. In Claude Desktop, create a Cowork chat by hand in the UI (not through Dispatch).
2. In Dispatch, run list_sessions - the chat appears with is_child: false.
3. read_transcript on that session id works.
4. send_message to the same id fails: Session not found / valid ids are the ones returned by start_task.
5. A session created from the same Dispatch via start_task accepts send_message normally.

Reproduced on two Macs running 1.34493.1.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.26832.0 (Claude Desktop)

Claude Code Version

Claude Desktop 1.34493.1 (desktop app, not CLI)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Versions on this machine between last success and first refusal (from [updater] Version changed since last launch): 1.28929.0 (13 Aug), 1.30096.1 (14 Aug), 1.30096.5 (15 Aug), 1.32352.1 (18 Aug), 1.32885.1 (20 Aug), 1.34493.1 (21 Aug). I made no send attempts in that window, so I cannot narrow it further; release notes for 1.34493.0 and 1.34493.1 list no Cowork changes of this kind.

Support (Fin) called it an intentional restriction on Dispatch rather than a regression, while stating it had no information on whether it was a documented planned change. Note that the cross-session messaging docs it cited describe a different subsystem - ListAgents/SendMessage between CLI sessions over inbox sockets.

I have a CSV of all 468 calls (timestamps, target ids, titles, result text; no message content) available on request.