[shivamhwp]

Closes #18805

Problem

Stop holds the queue so nothing starts on its own. If you then send a new message on the idle thread, it starts right away but the hold stays. The message you queued before Stop never runs. The thread sits idle and the only ways out are Resume or deleting and resending the message.

Fix

• A message the user sends from a client (web, desktop or mobile) now releases the held queue. The new message runs first, then the queued ones run in order.
• Agent, scheduled and server-sent messages (such as the usage-limit "Continue where you left off") leave the hold alone, so Stop still means nothing starts on its own.
• Every guard in startNextQueuedRun still runs when the queue continues, so a failed provider, a disabled provider or a usage limit holds the queue again as before.
• The mobile queue sheet said "Queue held after restart" even when the hold came from Stop. It now says "Queue paused".
• docs/user/composer.md says Stop holds the queue too, and that sending a message continues it.

The web queue panel still doesn't show that a queue is held. #14617 covers that.

Related: #18792 handles messages queued behind a new run that pick up an old hold. It keeps Stop holds until Resume, so it doesn't fix this case. The two changes don't overlap.

Evidence (POCO F4, Android 14, Claude)

Same steps both times: send a message, queue a second one while it runs, press Stop, send a new message.

Before (main)	After
Full video. "new" runs and finishes, "queued" stays stuck in the queue.	Full video. "new" runs, then "queued" runs on its own.
Queue sheet after Stop: "Queue held after restart".	Queue sheet after Stop: "Queue paused".

After the fix both messages answered. The queued reply shows above "new" because the timeline sorts runs by when they were queued. That ordering is unchanged here.

Tests

• New ThreadStop.test.ts case: after Stop, a user message releases the held queue and an agent message doesn't. It fails on main.
• ThreadStop, runtimeLayer, RestartContinuation, BackgroundWorkStop, DelegatedCompletionDelivery, ProjectionRecovery, ThreadLaunchService, RunCompletionReads: 227/227 pass.
• Server and mobile typecheck pass.

Claude Opus 5.5, Claude Code harness in T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at bae3d5f

Macroscope's review found this PR approvable — This is a focused queue-handling bug fix: an explicit user message resumes held queued work, while automated and server-originated messages remain paused. The behavior is covered by a targeted regression test, with the remaining changes limited to UI copy and documentation.

^{You can add or adjust custom eligibility rules. Learn more.}

[juliusmarminge]

Note

This comment is posted by Julius' dot

Closing because sending a new message now releases work held by Stop, failure or restart, replacing the explicit Resume workflow. #18805 has no maintainer approval for that behavior change, which the prior-approval rule requires. The recordings demonstrate the change, and the misleading paused-state label is a useful bug report. Please agree on the resume behavior with maintainers first, or submit the label fix while preserving existing holds.