The P1 is right, and it is a real duplicate-send path. Fixed in 04f9df6.

Traced it: createPromptQueueTarget awaits hydratePersistedSettings() before the queue store learns anything, and livePromptQueueActive only consulted promptQueueActive and usePromptQueueUI. promptQueueStartPendingRef is the one thing set synchronously at the start, and nothing read it. So between Cmd/Ctrl+Enter on an idle thread and that await resolving, the thread looked idle and the composer still held the text. A plain Enter or a Send click in that window took the normal send path, then the pending queue started, saw the response running, and dispatched its own copy.

The reservation now records the thread it belongs to, and a live one counts towards livePromptQueueActive. A second submit during the window takes the queue branch instead of the send branch:

• Same text: the reservation key is identical, so startHydratedPromptQueue dedupes on it and the second submit is a no-op. One prompt, queued once.
• Edited text: a different key, so it queues behind the first, in order.

The thread is recorded rather than just counting pending entries because the composer survives thread switches, so a reservation left by another thread must not make this one look like it is queueing.

hasPendingPromptQueueStart is in features/chat/utils/prompt-queue-input.ts with tests for its own thread, another thread, a cancelled reservation, nothing pending, a new chat matching on null, and one live reservation among cancelled ones. Suite is at 2725, tsc -b clean, no new biome errors.

One limit worth stating: the predicate is unit tested, but the wiring into livePromptQueueActive is verified by inspection and typecheck rather than by driving the real composer, since reproducing the window needs the full chat UI with a slow settings hydration.

Correct, and it is the same window the previous fix closed on the plain-text path, left open on this one. queuePastedTextPrompt only reaches startHydratedPromptQueue inside the .then of Promise.all(files.map((file) => file.text())), so for the length of that read nothing marked the thread as queueing.

Fixed in 8a415a0. The intent is recorded in a small pending list before the read begins and dropped when it settles, in a finally so a failed read cannot leave the composer stuck looking like it is queueing. livePromptQueueActive consults that list alongside the reservation map, through the same hasPendingPromptQueueStart predicate, so a submit during the read joins the queue rather than taking the send path.

The entry is pushed after the early returns, so a composer with no pasted-text attachment never registers anything. Tracking is per thread for the same reason as the reservation map: the composer survives thread switches, so another thread's in-flight read must not make this one look busy.

Tests cover concurrent reads on two threads and one finishing while the other stays counted. Suite is at 2726, tsc -b clean, no new biome errors.

Both new points are right, and both are fixed in 2a220ce.

Cancel pending paste reads when clearing queues. Correct, and the gap was wider than the cancelled field. The pending read sat outside every invalidation path at once: cancelPendingPromptQueueFactoriesForStop only walked the reservation map, cancelled was never read, and createPromptQueueTarget captures chatHistoryClearBoundary at its own call time, which is after the read. clearAllChats advances that boundary and then dispatches requestPromptQueueStop() with no thread ids, so it cancels every reservation, but a read in flight carried on and queued its prompt afterwards, recreating a chat the user had just cleared.

The read now registers the same way a reservation does. It carries temporary, so the stop helper can filter it, and it captures both boundaries before the read begins. The stop listener runs the same cancel helper over it, and the resolve path bails on cancelled or on a history boundary that has moved. The local model boundary is threaded into startHydratedPromptQueue as the captured generation, so the check happens where the target is known but against the generation from before the read rather than after it.

Avoid starting another read for an already-pending paste. Correct, and it is the cost of the previous fix. Recording the read as an active queue is what stops a second submit taking the send path, but it routes that submit into the queue branch, which called queuePastedTextPrompt again for the same unchanged attachment. Two reservations with the same key dedupe, so the duplicate needs the first read to have finished its hydration before the second read resolves, exactly as described.

Reads are now keyed and held in a map, so a submit during a read joins the one already in flight and reports handled rather than starting another.

One deliberate choice there: the wait mode is not part of the key. It is recomputed per submit, and if a run starts or ends mid-read the two submits compute different values, which would split one prompt across two keys and bring the duplicate straight back. What identifies the prompt is the thread, the text and the attachments it is assembled from, so those are the key and the first read's wait mode wins.

pastedTextQueueKey is in features/chat/utils/prompt-queue-input.ts with tests for a stable key, a differing thread, text or attachment, reordered attachments, and a null thread not colliding with a named one. Suite is at 2730, tsc -p tsconfig.app.json clean, and eslint on the touched files reports the same counts as the branch tip did before the change.

Scope worth stating: the key is unit tested, but the cancel wiring is verified by typecheck and inspection rather than by driving the real composer, since reproducing the window needs the full chat UI with a Clear all landing inside a File.text() call.

Right, and it is a gap I introduced with the previous commit rather than one that was already there. That commit captured the history clear boundary and the local model boundary before the read and threaded the latter into the reservation, but left the settings epoch and the incognito flag to be taken afterwards. So a queue-relevant setting changed during the read became the reservation's own baseline, and shouldAbortPendingQueueForSettingsChange had nothing to compare against, while an ordinary pending start in the same situation aborts.

Fixed in 05ba402. The read now captures every baseline the reservation would otherwise take: the local model boundary generation, the settings epoch, the incognito flag and the history clear generation. The optional argument on startHydratedPromptQueue is now the whole captured set rather than one generation, and the reservation prefers it when present, so all three checks run against the state as it was when the user made the queue gesture.

Suite is at 2730, tsc -p tsconfig.app.json clean, and eslint on thread.tsx reports the same counts as the branch tip did before these changes.

Right, and it is the cost of the dedupe from the previous commit: the read absorbed the retry as a duplicate and then aborted itself, so the two gestures cancelled each other out and nothing queued.

Fixed in 90fc433. The dedupe now only absorbs a read that is still going to start. pendingPastedTextReadIsStale runs the checks that need no queue target, the cancel flag, the history clear boundary and shouldAbortPendingQueueForSettingsChange, and a read that fails any of them no longer swallows the retry. The retry takes the key, so the stale read still resolves but drops out on the ownership check and only the new one queues. The model boundary check stays with the reservation, where the target is known and usesLocalModel can be evaluated, so the dedupe cannot be stricter than the abort rule and reintroduce the duplicate.

The abort path also no longer passes undefined for onAborted. A queue that is invalidated after the read now says so, matching what the saved-list path already does, so a gesture that queues nothing is never silent.

Suite is at 2730, tsc -p tsconfig.app.json clean, and eslint on thread.tsx reports the same counts as before the change.

Right, and it is the same defect one level up: the previous commit fixed it for the pasted-text read and left the reservation itself turning retries away.

Fixed in ba230a0. pendingPastedTextReadIsStale is now pendingQueueStartIsStale and covers both, with the history clear generation optional since a reservation captures that inside createPromptQueueTarget rather than up front. The duplicate check only refuses a retry when the reservation it collides with is still going to start; an already-invalid one is replaced, and it drops out on the get(key) === reservation check it already had.

The model boundary check deliberately stays out of the predicate. It needs usesLocalModel from the target, so it can only run once the target exists. Keeping it there means the predicate can never be stricter than the abort rule, which is what would let two starts through for the same prompt.

One thing that fell out of this: a superseded reservation used to run onAborted, which after the previous commit would have shown "Pasted text was not queued" even though the retry was about to queue it, and would have reopened the saved-list dialog for the same reason. onAborted now fires only when the reservation is still the one holding the key, so a replacement is quiet and a real abort still reports.

Suite is at 2730, tsc -p tsconfig.app.json clean, eslint unchanged from the branch tip.

Shot this from two isolated installs, BEFORE at the merge base 6f443b5cc and AFTER at the head ba230a083, to see what the change looks like on screen.

One flow covers both halves of the PR. Four prompts are submitted into an idle thread with Ctrl+Enter, then the bottom queued row is walked to the top with ArrowUp on its handle. Model is unsloth/Qwen3-4B-Thinking-2507-GGUF Q4_K_M on both sides.

Both halves are holding the same three rows before anything moves, alpha / beta / gamma, which is the control. After the same two ArrowUp presses the base still reads alpha, beta, gamma and the head reads gamma, alpha, beta.

The header is where the chord shows up, and it is worth saying why it is a number rather than a picture. getPromptQueueUIItemsForRun skips item.dispatched, so a dispatched item leaves the stack, and on an idle thread the chorded prompt dispatches immediately. Both stacks therefore end up showing the same rows, and a row's own label counts the rows on screen rather than the run. Only the header still counts the dispatched one: 0 of 3 on the base means the first prompt was sent outside any queue and only the three that landed while it streamed were queued, against 1 of 4 on the head where all four are one run.

Two things I got wrong first, in case they are useful for the next one of these.

Photographing the chord on its own does not work. My first plan gave it a pair of its own with the model unloaded, so the thread would stay idle throughout. A send with nothing loaded makes Studio auto-load the 270M default, and that load itself reads as a run, so the two sides queue identically.

The queue drains at the speed of the model, and the first run photographed the base holding three rows against the head holding two, purely because the head's opening prompt finished sooner. Two different queues, and it reads as a difference this PR made. The scene now asserts the settled rows are the three expected prompts and retries the flow otherwise. With the 270M default the whole stack is gone before any shot lands, on either side.

Went through this one properly before merging: what changes for a user, whether anything else moves, and how it behaves outside Chrome on Linux. Three commits pushed to the branch, 27dcc075d.

Before and after

Before, queueing was only ever a side effect. handleSubmit queued in one branch, the one guarded by liveThreadIsRunning || livePromptQueueActive || livePreStreamRunActive, so a prompt joined the queue only because a response happened to be running when you pressed Enter. On an idle thread there was no key that meant "stack this", and once rows existed the order was fixed: edit and remove, no move.

After, Cmd/Ctrl+Enter queues whether or not something is running, and a queued row moves by drag or by ArrowUp/ArrowDown on its handle.

The gap is real rather than cosmetic, and the measurement that shows it is the queue's own header, since it counts the item already dispatched. Four prompts submitted in quick succession into an idle thread:

0 of 3 is the old behaviour: the first prompt went out on its own and only the three that landed while it streamed were queued.

Does it break anything

No, and the parts that must not move were measured against the merge base rather than asserted. Same three engines, same script:

There is no hardware path to worry about here. The diff is five files, all under studio/frontend, and it touches no Python, no API route, no localStorage key and no persisted schema, so there is nothing for a GPU, an accelerator or an OS to bite on. The queue lives in a module-level Map and dies with the tab.

Old installs are fine for the same reason, and I checked rather than reasoned: I installed this branch in place over an existing merge-base install carrying real chats. The old password still logs in, so auth.db came through untouched, all 21 threads read back through the upgraded backend, no row count went down, and all ten behaviour checks pass on the upgraded home.

Cross-browser

Driven against a real built Studio in Chromium 151, Firefox 153 and WebKit 26.5, ten checks each, thirty of thirty passing and no difference between the engines: both chords, the two newline combinations, plain Enter, auto-repeat, a drag driven through a real DataTransfer, the keyboard handle twice on the same element, and a file dropped onto a queue row.

Two of those are worth calling out.

The custom drag type survives everywhere. All three report application/x-unsloth-prompt-queue-item back verbatim in types during dragover and through getData on drop. WebKit filters custom drag data by origin, which is a real restriction but not one this can hit, since the drag starts and ends in the same document.

The keyboard reorder keeps focus. This is the one I expected to fail: the HTML spec blanks the document's focused area when a focused node is removed, and moving a keyed row is a remove plus an insert. Measured in all three engines, in both directions, the handle stays focused and the second ArrowUp lands. Worth knowing it holds by React's choice of which row to move rather than by guarantee, so it is a thing to re-check if the stack's markup changes.

What I changed

AltGr no longer fires the chord. Windows reports AltGr as Ctrl+Alt on any layout the browser does not recognise as carrying a real AltGraph modifier, which the UI Events spec allows for explicitly. On those layouts AltGr is held for everyday characters, so the chord could fire on a keypress meant as something else. Alt now disqualifies it, the way Shift already did. The control row above is that fix: Ctrl+Alt+Enter now behaves exactly as it does on the merge base.

The chord no longer arms itself when there is nothing to submit. event.currentTarget.form?.requestSubmit() is a no-op when the textarea sits outside a form, and requestSubmit is missing entirely on Safari before 16. In both cases forceQueueRef stayed armed and the next submit, an ordinary Enter possibly minutes later, queued instead of sending. It is armed only when the call is going to happen now, and disarmed if it throws.

The branch is merged with main. One conflict, in the composer's hook block, where main added the pastedTextMinChars read from #8963 and this branch added the chord ref at the same spot. Both kept. The paste threshold does not change what the queue sees: a long paste still arrives as an attachment isPastedTextFile recognises, which is what canQueuePastedTextPrompt gates on.

One thing that was not this branch's fault. chat-preferences-store.ts imports ../utils/pasted-text without an extension, which node's type-stripping loader cannot resolve, so every test reaching the preferences store died on ERR_MODULE_NOT_FOUND. It fails the same way on main at 2cf7a2888. Fixed here because it takes this branch's suite down with it, and the rest of the files on the test path already carry the extension.

Tests added

An edge file for the predicates and an exhaustive sweep of the reorder math.

The sweep runs every queue length up to seven against every from/to pair and every active slot, and asserts the invariants a queue engine depends on: the result is always a permutation with nothing lost or duplicated, nothing at or before the dispatching slot ever moves, the range check and the reorder never disagree, a move and its reverse restore the queue, the caller's array is never mutated, a frozen array works, and the dispatch-changed flag agrees with the slot it reports on. The reorder math came through all of it unchanged, which is the main thing I wanted to know before trusting a drag to retarget a pending send.

The edge file covers what the DOM hands us on platforms this box cannot run: numpad Enter, every platform's modifier combination, the AltGr shape, a DOMStringList rather than the array Chromium returns, a Map's one-shot values iterator, prompt text that looks like the key's own JSON encoding, and NFC against NFD.

Suite 2900 passing, tsc -b clean, eslint on thread.tsx reports the same 50 pre-existing errors it did before.

Not covered

Real Safari, real Windows and real macOS. WebKit 26.5 under Playwright is the closest stand-in for Safari that a Linux box can run, and the Cmd and AltGr chords were synthesised as key events rather than typed on the hardware. The drags are real DragEvents carrying a real DataTransfer, which is what the app receives, but the browser's own drag initiation from a mouse press is only exercised in Chromium. Cross-run drags, refused by the match.run !== target.run guard, are covered by reading the code rather than by a test.

Codex Review: Didn't find any major issues. 🎉

Reviewed commit: 5c936a2bfe

Codex Review: Didn't find any major issues. Delightful!

Reviewed commit: 517dade9f9

Codex Review: Didn't find any major issues. Delightful!

Reviewed commit: 054adf1405

@codex review