Desktop: Submitted Message Becomes "Queued" and Is Lost or Mishandled

Corrected 2026-08-29. The first version of this report claimed the message was never enqueued and could therefore never fire. That was wrong, and it was built on the wrong session. What the reporter actually observed is below: the message does reach the chip on Enter, it is delivered late, and it arrives behind input typed after it. The measurements have been re-run on the full transcript corpus rather than the 2 percent slice the first version used. Both errors are described at the end.

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?

A message typed into the composer and submitted with Enter goes to the N message queued chip
instead of the conversation. It then takes a long time to enter the chat flow, and when it does
it lands behind messages typed after it. Submission order and delivery order do not match.

Three things are wrong at once, and the third is the one that costs real work:

1. The delay is unbounded and unexplained. The chip shows a count and a truncated preview.

It does not say what it is waiting for or how long it has waited.

1. Delivery is out of order. A message sitting in the chip is overtaken by later input. The

later message gets answered first, in a context that does not yet contain the earlier one.

1. Waiting and lost are the same picture. Nothing distinguishes a message that will arrive

in ten seconds from one that will not arrive at all, so the only way to find out is to wait
and see whether the instruction was ever acted on.

Out-of-order delivery is worse than plain delay. A queued correction that lands after the work
it was meant to redirect is not merely late. The model acts on the later message first, and the
earlier one then arrives looking like a fresh instruction rather than the correction it was.

Measurements

Sessions record queue activity as first-class transcript events, which makes the normal case
measurable:

{"type":"queue-operation","operation":"enqueue","timestamp":"...","content":"..."}
{"type":"queue-operation","operation":"remove","reason":"absorbed_mid_turn","content":"..."}

Normal absorption is fast. Two sessions, same app instance, same minute, both mid-turn:

20:30:19.091  enqueue  "You should be adding a table at the end of every cycle"
20:30:19.130  remove   absorbed_mid_turn        <-  39 ms
20:30:32.755  enqueue  "You should be adding a table at the end of each cycle"
20:30:32.775  remove   absorbed_mid_turn        <-  20 ms

But latency in the same app across the same few minutes spans three orders of magnitude:

20 ms   plain typed message
39 ms   plain typed message
27 s    batch of 13 cross-session messages
34 s    batch of 2 cross-session messages

There is no single expected wait a user could learn. The chip in this report stayed up far
longer than any of these, through more than eight minutes in which the session worked normally,
opened two pull requests, and produced more than fifty assistant turn boundaries.

What I could not confirm from logs is the eventual delivery. Searching the full local corpus
for two verbatim fragments of the chip's own preview text returns nothing:

corpus: 16,384 transcripts across 6 profile directories, recursive, no sampling
  "do you know what I mean"   -> 0 files
  "why are you not doing it"  -> 0 files
  "end of each cycle"         -> 4 files   <- CONTROL, proves the probe fires

The control matters. A probe that returns zero everywhere is indistinguishable from a broken
probe, so the third pattern is one that must fire, and does. The reporter watched the message
enter the conversation eventually. I am reporting that I could not corroborate that from the
transcripts, not that it failed to happen.

What Should Happen?

1. Delivery order should match submission order. A message queued first should be delivered

first, ahead of anything typed after it.

1. The chip should say what it is waiting for and how long it has waited.
2. There should be a way to deliver the message now rather than waiting an unbounded time.
3. If a queued message cannot be delivered, that should surface rather than leaving a chip that

implies it is safely waiting.

Error Messages/Logs

No desktop log is available, which is worth reporting on its own. The Windows MSIX build at this
version writes none I can find:

• %APPDATA%\Claude\logs\main*.log exists, nothing written since 2026-08-28.
• %LOCALAPPDATA%\Claude\Logs\main.log likewise.
• No log of any type newer than 2026-08-28 anywhere under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\.

Older rotated logs do contain [LocalSessionManager] flushed held steers and
cancelQueuedMessage ... -> cancelled, so this logging exists and is not landing for this
build. Without it a user cannot see which queue holds a waiting message, or why it is waiting.

Steps to Reproduce

No deterministic repro, and I would rather say so than invent one. The conditions:

1. Twelve local desktop sessions open in one app instance, each in its own git worktree of the

same repository, several of them exchanging cross-session messages.

1. The target session was mid-turn, making continuous tool calls, and had already absorbed

several queued inputs during that same turn in tens of milliseconds.

1. A plain sentence was typed and submitted with Enter. No slash command, no ! prefix, no

session switch.

1. It went to the chip, stayed a long time, and arrived behind messages typed after it.

The cross-session message traffic may be a factor. Those batches are the only inputs measured
here that took tens of seconds rather than milliseconds, and the affected session was receiving
them throughout.

Claude Code Version

Bundled CLI 2.1.251, desktop app 1.37937.0 (MSIX Claude_1.37937.0.0_x64__pzs8sxrjxfjjc)

Platform

Claude Desktop app

Operating System

Windows 11 Pro, build 10.0.26200

Additional Information

Related, none of them this report:

• #73661 asks for queued messages to be processed sequentially, one message per turn, FIFO.

That request and this bug are the same underlying complaint about ordering.

• #87037 asks for the ordering rule to be documented, noting that plain prompts fold into the

running turn. This was a plain prompt that did not fold in, while an almost identical one in a
sibling session did, 13 seconds earlier.

• #73118 covers long turns blocking queued messages. Adjacent, but does not cover order.
• #81582 covers the chip becoming undismissable when cancelQueuedMessage falls through every

strategy because the uuid "exists in none of the manager's queues". Possibly the same desync
seen from the cancel side.

• #77010 and #77451 cover queued messages lost across a session switch. No switch here.

On the two errors in the first version of this report, since both are the kind that survive
review by looking measured:

The first was scope. I searched 321 transcripts and reported a zero. The real corpus is 16,384
across six profile directories, so I had covered about two percent of it while presenting the
result as a corpus-wide census.

The second was attribution. I read the queue events of the wrong session, found the message
absent, and concluded it had never been enqueued anywhere. It had been enqueued in a different
session and absorbed in 20 milliseconds. A zero from the wrong file reads exactly like a zero
from the right one.

content, operation, reason, sessionId, timestamp, type

remove, has_content=True,  reason=(none)             3875
remove, has_content=True,  reason=absorbed_mid_turn   419
remove, has_content=False, reason=(none)              138
remove, has_content=False, reason=absorbed_mid_turn    13   <-- this bug