[BUG] Cowork queue: queued messages delivered to session but not actioned (no follow-up assistant turn)

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?

Cowork Queue: queued messages delivered to session but not actioned (no follow-up assistant turn)

Summary

In Cowork, when I queue a message while Claude is actively working in a task, the queued message is captured and delivered to the session as a user input — but the orchestrator does not reliably spawn a follow-up assistant turn to process it. The message effectively disappears from the user's perspective: no acknowledgment, no response, no visible failure.

Behavior is inconsistent: sometimes the queued message is silently absorbed into the current in-progress assistant turn (and acknowledged at the end), sometimes it is completely ignored with no follow-up turn generated.

Environment

• Claude Desktop version: 2.1.149
• macOS: 26.3.1 (arm64 / Apple Silicon)
• Plan: Max
• Surface: Cowork tab (not Claude Code)

Steps to reproduce

1. Open a Cowork task.
2. Send a prompt that will take some time to respond to (e.g. asks for a written paragraph).
3. While Claude is actively responding (Send button switches to Queue), type a follow-up that requires distinct additional work and click Queue. Example pair used in repro:

• Initial: Write me a 3-sentence intro paragraph for the About page of stillpoint.studio aimed at fashion brands.
• Queued: When you're done with the above, also write me a one-line tagline for the same page — something punchy under 8 words.

1. Wait for Claude to finish.

Expected behavior

After the initial response completes, the orchestrator should treat the queued message as the next user turn and Claude should respond to it (in this case, by producing the tagline).

Actual behavior

Claude responds to the initial prompt only. The queued follow-up is never addressed. No tagline appears. No acknowledgment. The session ends in success state as if no follow-up existed. The user is left thinking "Claude lost my prompt," but the audit log shows the queue actually delivered the message — Claude just never got a turn to act on it.

Audit log evidence

From ~/Library/Application Support/Claude/local-agent-mode-sessions/<org>/<user>/<session>/audit.jsonl:

10:28:43  user:      intro request
10:28:46  user:      tagline request (QUEUED — DELIVERED to session)
10:28:55  user:      intro request (replay)
10:28:55  assistant: (turn starts)
10:28:58  assistant: "Here's a 3-sentence intro..."  (only addresses intro)
10:28:59  rate_limit_event
10:28:59  result:    success (turn ended — no second turn ever fires)

Queue-operation events (same session's JSONL):

10:28:44.443  enqueue: intro paragraph request
10:28:44.549  dequeue
10:28:46.809  enqueue: tagline request
10:28:59.021  dequeue  ← delivered, but no assistant turn follows

Reference IDs (for backend correlation)

• Org: a8f4f9ef-c011-4bde-8f7d-69f2b5cca982
• User: fe65ad74-3634-4946-b6a6-5d87494cfc40
• Cowork session: local_67025064-89a1-40ee-8c28-5ad034971103
• CLI session: 03f27358-a5f4-4d8a-aebd-0dad59763fbc
• Test event UTC: 2026-05-23 10:28:46 to 10:28:59
• Affected request_id (intro turn): req_011CbKLXtcf6tUwnQY6FbmEn

Hypothesis (from a contributor, not authoritative)

The rate_limit_event firing at the same second as the queue dequeue is suspicious. The dequeue completes (queue mechanism is healthy) but the post-completion handoff to spawn a new assistant turn may be aborted by — or racing with — the rate-limit handler. In other observed runs, the same queue mechanism worked end-to-end (e.g. test marker QTEST-fr8w2k-pls-confirm was queued, delivered, and explicitly acknowledged by Claude in the same response), so the bug appears to be in the orchestrator's "should we start a new turn after this one completes?" logic rather than in the queue itself.

Related UX issue worth fixing

Even when the queue works correctly, there is no visual indicator in the chat that a given assistant response is addressing a queued follow-up. This makes successful queue deliveries indistinguishable from silent absorption, which is why users perceive a broken queue. A small "↳ from queued" badge on the assistant message that originated from a queued user input would dramatically improve trust in the feature.

Severity

Medium-high. The queue feature is documented as a way to keep working alongside Claude on long-running tasks. When queued messages silently vanish, users lose work and lose trust in the surface — defeating the feature's purpose. The intermittent nature makes it especially hard for users to know whether their queued instructions will be honored.

What Should Happen?

After the initial response completes, the orchestrator should treat the queued message as the next user turn, and Claude should produce a separate response addressing it — in this case, the one-line tagline.

Error Messages/Logs

No error surfaced to the user. From the audit log, a rate_limit_event fires at the same moment the queue dequeue for the second message completes, but nothing is shown in the UI:

10:28:59  rate_limit_event
10:28:59  result: success

Steps to Reproduce

1. Open a Cowork task in Claude Desktop.
2. Send a prompt that takes 10–30 seconds to respond to. Example: "Write me a 3-sentence intro paragraph for the About page of stillpoint.studio aimed at fashion brands."
3. While Claude is actively responding (the Send button switches to Queue), type a follow-up that requires distinct additional work, then click Queue. Example: "When you're done with the above, also write me a one-line tagline for the same page — something punchy under 8 words."
4. Wait for Claude to finish.
5. Observe: Claude only addresses the initial prompt. The queued follow-up is never actioned. No tagline appears. No acknowledgment. No visible error. From the user's perspective, the queued message has been silently lost.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.149 (Claude Desktop)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Note: this bug is in Claude Desktop's Cowork feature, not in the Claude Code CLI. The Terminal/Shell field above is filled only because it is required by the bug template — the bug has nothing to do with the terminal.

Additional context: during the same troubleshooting session, a separate Dispatch issue was diagnosed and fixed by manually removing a stale remoteSessionId from ~/Library/Application Support/Claude/bridge-state.json. This is unrelated to the queue bug being reported here, but worth flagging in case the same investigation surface (bridge state, session orchestrator) is relevant.