[BUG] Cowork (claude.ai web, cloud sessions): a message one of my own sessions posts into another of my sessions is silently held ("peer_message_hold", "no-mode-asserted") with no way for the account owner to pre-authorise it

Concerns Cowork cloud sessions on claude.ai (web), not the CLI. CLI-only template fields: not applicable.

What happened

I run several Cowork cloud sessions on one account. A session I was talking to ([id removed]) needed to send a correction to another of my own idle sessions ([id removed]), authenticated as me through my own claude.ai login.

1. POST /v1/code/sessions/[id removed]/events with {"events":[{"event_type":"user","payload":{"type":"user","message":{"role":"user","content":[{"type":"text","text":"..."}]}}}]} returned 200 (sequence_num 569, 7 Oct 2026 00:34:28Z).
2. The target session's worker started: env_manager_log, set_permission_mode bypassPermissions, MCP servers attached.
3. Then this system event, and nothing after it. No turn ran:

{"subtype":"peer_message_hold","cause":"no-mode-asserted","from":"unknown","lane":"stdin","state":"held","message_uuid":"4d2a4477-..."}

1. Several minutes later the session was still idle, the message unanswered.

Why it is a bug, not just a policy

• It fails silently. The POST returns 200, so the sender believes it was delivered. Nothing in the response says the message is held or why.
• The account owner cannot authorise it in advance. Both sessions are mine, on my account, and the write was made with my own authenticated login. There is no account or session setting to say "messages from my own sessions may run", and no documented field for the sender to assert a mode (cause: no-mode-asserted suggests one exists).
• The only release is a manual step. I have to open the target session and let the message through by hand. That defeats coordinating sessions, which is the reason to run several.

I understand why a hold exists: to stop a third-party agent typing into a session as me. But "from: unknown" for a write made with the owner's own credentials, and no way to pre-authorise it, looks like the hold catching the case it was never meant for.

Expected

One or more of:

• A documented way for a session (or the owner's authenticated client) to assert that a message is from the owner or a trusted peer, so it runs.
• An account or project setting: "allow my own sessions to message each other".
• At minimum, a non-200 response, or a held: true field in the POST result, so the sender knows the message did not run, and an indicator in the target session's UI.

Environment

claude.ai web, Cowork cloud sessions, 6 to 7 Oct 2026 (America/Toronto). Org [id removed].