[M0xoo]

Problem

If a queued message starts while you are editing it, because the turn ended or another client started it, T3 Code moves your unsaved edit into the composer and says "Your unsaved edit was kept in the composer."

On web and desktop, that move carried only the prompt, images and files. Thread mentions and other context stayed behind in an orphaned queued-edit: draft, and their chips were stripped from the text. If you then sent the message, the agent never got that context. Expected: the whole edit is kept, as on mobile, where exitQueuedRunEdit already moves context.

Steps: hold a turn on an approval, queue a message, click Edit queued message, add an @thread mention, then approve so the queued message starts mid-edit.

Change

moveComposerPromptAndImages becomes moveComposerContent (recoverQueuedMessageEdit is its only caller). It now moves every context type the prompt still references, and clears them from the source, so the edit draft goes away.

• A mention you typed over stays out, matching referencedThreadContexts on the send path.
• A chip with no record is stripped, so it can't come back as a dead chip.

Scope and approval

No prior issue or discussion. This is a small, focused fix for an obvious bug: the toast says the edit was kept while part of it is dropped, and mobile already keeps it. It solves that one problem in one web store action, with no contract, server or settings changes.

Related open PRs, which I left out of this one:

• fix(web): editing a queued message keeps its thread mention chips #30889 seeds the context a queued message already had into the edit draft. This move then carries it. That PR also clears the edit draft after the move, so whichever lands second may need a small rebase.
• fix(web): cancelled queued-message edits release their staged uploads #29570 covers releasing uploads on a discarded edit.
• fix(web): removing a queued message's attachment counts as an edit when its run starts #29601 covers removing an existing attachment counting as an edit.

Verification

Real app with the Replay provider, using the steps above. Both builds show the "kept" toast; only the fixed one still has the mention.

	main	This PR
Composer	text only, 0 chips	text and mention chip
Thread draft	threadContexts: 0	threadContexts: 1
Orphan queued-edit: draft	stays in storage with threadContexts: 1	none

Two cases in queuedMessageEdit.test.ts, both failed before their fix:

keeps context added to an edit when another client starts the queued run
AssertionError: expected [] to deeply equal [ Array(1) ]

leaves out a mention typed over and a chip with no record when keeping an edit
AssertionError: expected [ Array(1) ] to deeply equal []

With the fix:

• queuedMessageEdit.test.ts and composerDraftStore.test.ts: 83 passed
• useQueuedRunEdit.browser.test.tsx: 7 passed
• vp run check:changed: all steps pass

Not checked: the real run used @thread only, so the other context types go through the same code but were not each run in the app. Mobile is unchanged and was not run.

Model: Claude Opus 5.5, harness: Claude Code in wisp.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at c0304cb

Macroscope's review found this PR approvable — Queued-message edits now retain their referenced context when recovered into an empty composer. The change remains within draft recovery, preserves attachment safeguards, and does not automatically submit the recovered content.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

When queued-edit recovery keeps an edit, it moves all composer content. The store retains inline references only when their context records are eligible to move, then clears the source prompt and context records.

Changes: Queued edit content recovery

Layer / File(s)	Summary
Filter and move composer content apps/web/src/composerDraftStore.ts, apps/web/src/lib/composerContextReferences.ts	The store moves eligible content and matching context records. It filters inline references by transferable context IDs, then clears the source prompt and context arrays.
Use content transfer during queued-edit recovery apps/web/src/components/chat/queuedMessageEdit.ts, apps/web/src/components/chat/queuedMessageEdit.test.ts	When recovery keeps an edit, it moves composer content. Tests cover retaining references with matching context records and excluding references without matching records.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related issues

• pingdotgg/t3code#15611 — The change handles queued-edit recovery and preserves context still referenced by the prompt. It does not establish that the queue-dispatch behavior described in the issue is fixed.

Suggested reviewers: maria-rcks

Merge Risk: Minimal · up to 39573

No merge-blocking issue was established for queued-edit recovery; the change is ready for normal checks.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly summarizes the main change: queued-message edit recovery keeps added context when the run starts.
Description check		The description includes all required sections. It explains the problem and change, justifies the scope, and reports verification results and limitations.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 934c7f8
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 335edc63-dc25-48f8-ae75-19dd5d527072

Commits

Reviewing files that changed from the base of the PR and between c0304cb and 395733e.

Files selected for processing: 3

• apps/web/src/components/chat/queuedMessageEdit.test.ts
• apps/web/src/components/chat/queuedMessageEdit.ts
• apps/web/src/composerDraftStore.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Merged current main (merge commit, no rebase) to clear the conflict in queuedMessageEdit.test.ts. Both sides kept: this PR's two context-recovery tests and main's removed-attachment test from #29601, which still passes with moveComposerContent. No other changes. vp run check:changed and the two touched test files pass.

[github-actions]

This PR conflicts with main. Rebase it or merge main into it. If it still conflicts after 7 days with no activity, it will be closed automatically.

See the conflict window.

[juliusmarminge]

Thanks for this. Before a bug fix is taken further, the bug is reproduced on current main, and here it did not appear.

I ran your steps in the web app on current main (5f29d87). The active turn was held on a command approval, one message was queued behind it, and I opened Edit queued message with the normal composer empty. I added an @ mention of another thread, selected the chip and typed over it while keeping the rest of the edited text, then approved the turn so the queued run started before I saved.

The composer had already dropped the removed mention's thread record when I typed over the chip, so there was nothing stale left to carry over. After approval, the composer said the unsaved edit was kept. The recovered draft held the edited text with no thread records, and the edit draft was cleared. I also tried two mentions, deleting one with Backspace and keeping the other: the recovered draft kept the prompt with the remaining chip and only that one record.

I couldn't find a way in the app to end up with a mention chip that has no record behind it, and the screening on this PR didn't find one either. So I can't reproduce the remaining difference this PR targets on main. If you have a sequence in the app that leaves a stale or orphaned mention after a queued edit is recovered, please share it and we'll take another look.

Closing this pull request. If it still happens for you, please open an issue with the exact steps, what you see, and the version and platform you are on; a fix is picked up from there.