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.
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.
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.
https://github.com/user-attachments/assets/a4ee32d8-e43a-444d-923e-6c3fc107e9ee
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.
+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.
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 isSendBusy from 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 in ChatView.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.
