Problem
In the Claude Code desktop/web app, messages typed while Claude is working are queued — but they all flush at the next LLM pause, not at true end-of-turn. That includes pauses between tool calls, after a subagent returns, or any intermediate stop. In practice this means queued messages often get injected mid-task and derail whatever Claude was doing.
Why it matters
This breaks long autonomous sessions. Codex lets you stack 5 prompts, walk away for an hour, and come back to finished work. In Claude Code, there's no reliable way to line up follow-ups because you can't predict when the queue will flush.
Request
An "end-of-turn only" queue mode (setting, flag, or per-message toggle) so queued messages wait until Claude has fully completed the current task before the next one is sent.
Workarounds today
- Bundling everything into one mega-prompt (fragile, no course-correction).
- Stop hooks that inject from a file (hacky, per-user setup).
/loop (not really the same thing).
None of these match the ergonomics of a proper message queue.
Problem
In the Claude Code desktop/web app, messages typed while Claude is working are queued — but they all flush at the next LLM pause, not at true end-of-turn. That includes pauses between tool calls, after a subagent returns, or any intermediate stop. In practice this means queued messages often get injected mid-task and derail whatever Claude was doing.
Why it matters
This breaks long autonomous sessions. Codex lets you stack 5 prompts, walk away for an hour, and come back to finished work. In Claude Code, there's no reliable way to line up follow-ups because you can't predict when the queue will flush.
Request
An "end-of-turn only" queue mode (setting, flag, or per-message toggle) so queued messages wait until Claude has fully completed the current task before the next one is sent.
Workarounds today
/loop(not really the same thing).None of these match the ergonomics of a proper message queue.