Repository navigation
Queued message sends its original text while being edited #15611
Description
What happens
If the active turn finishes while I'm editing a queued message, T3 sends the original queued text before I save. The message is no longer available to update.
Reproduce
- Start a turn that takes long enough to queue another message.
- Queue a message, then click its pencil to edit it.
- Change the text without saving.
- Let the active turn finish while the editor is still open.
Expected: the queued message waits until I save or cancel the edit. Save sends the updated text when the queue can continue; Cancel keeps the original text.
Actual: the original message starts while the edit is still in progress.
Investigation
Reported on Windows. Source inspection against 253dea360 shows that entering edit mode changes client state but leaves the run eligible for server-side queue dispatch. The server does not know an edit is underway. This is shared queue behavior, not a provider-specific failure.
I have a focused fix ready and will link the PR here. Its regression tests drive turn completion while the message is held for editing. Removing the new dispatch guard makes both Save and Cancel cases fail because the message becomes starting instead of remaining queued.
Activity
Andrew-Forster commentedon Oct 4, 2026
Fix is up in #15612. The server now holds the queued message before the editor opens, and Save or Cancel releases that hold. Focused tests cover the completion race, queue ordering, stale edits, and existing queue pauses. The PR is draft while I add the manual recording.
PrivateVictories-Main commentedon Oct 11, 2026
+1, I run into this fairly often on macOS with both Codex and Claude threads.
I usually queue the next instruction while a turn is running. Sometimes I think of something to add, click the pencil, and start typing or dictating with voice-to-text. If the running turn finishes during that edit, the original text gets sent before I'm done, and my additions don't make it in.
A suggestion: it would be really nice if T3 held a queued message while it's being edited, and sent it once I save. That could be a setting, since some people might prefer the current behavior of sending right away and queuing another message for anything extra. Something like "While editing a queued message: Wait until I save / Send right away." I'd personally pick waiting, but either way a setting would let everyone choose.
Also noting that #15612 had a fix for this but was closed during the PR cleanup, so it may still be open on main.
adrianorocha-dev commentedon Oct 28, 2026
Possibly related: #26609. When the follow-up is queued by the idle "compact, then send" flow, the edit can't be saved at all. The "Update queued message" button inherits
isSendBusyfrom the still-pending compact-then-send local dispatch, so it shows a spinner and stays disabled until compaction ends. Then the original text is sent, as described here. A fix here (holding a queued run while it's being edited) would avoid losing the edit, but the stuck save button probably needs its own fix inChatView.tsx/ComposerPrimaryActions.tsx.Seen on 0.1.4-nightly.20261028.3824 (Linux server, Claude provider).
Posted by Claude Code (claude-opus-5-5) via
t3 triage.xkjjx commentedon Nov 8, 2026
Reproduced on macOS 27.0.1, T3 Code (Beta) 0.1.2, Claude thread. A queued message was sent while its edit was still open. The edited text was then sent as a separate message afterward.
Dropje97 commentedon Nov 8, 2026
Still happens on
0.1.8-nightly.20261106.4275, web client, Linux server. I reproduced it on afresh instance with a Codex thread, Follow-up behavior set to Queue:
sleep 45in the shell).The server started the queued run 85 ms after the active run completed, with the original text.
The client showed "Queued message is no longer queued. Your unsaved edit … was kept in the
composer." While the edit was open, the client sent no
queued-run.*command, so the server hadno way to know about it. The same happened in a real Claude thread: the user edited a queued
reply, and the turn ended during the edit and sent the original. They sent it again, edited again,
and the next turn end sent the original a second time. The third attempt arrived only because
they promoted it to a steer.
On current
mainthis is still the intended design:packages/client-runtime/src/queuedRunEdit.tsends an edit "when its run leaves the queue", and the server has no command that holds a run.
#18631's server-side hold would fix it.
Investigated by Claude Code (claude-opus-5-5) for the user.