[Bug]: Terminal "Add to chat" is silently dropped while editing a queued message #36107

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web (seen in apps/desktop)

Steps to reproduce

1. Open a thread with the integrated terminal visible and start a turn so the thread is running.
2. Send a follow-up so it is queued, then click Edit on the queued message. The composer switches to the queued-message edit (Update queued message).
3. In the terminal, select some output, right-click, and choose Add to chat.

Control: with no queued edit open, the same selection and Add to chat inserts a Terminal 1 line N reference into the composer as expected.

Expected behavior

The terminal reference is inserted into the queued message being edited and saved with it on Update. If terminal context can't be attached to a queued edit, the action should be disabled or show a message.

Actual behavior

Nothing is added. The queued-edit composer is unchanged, no toast or error appears, and the terminal selection is cleared, so it looks as if the action worked. The selection is not added to the thread's normal draft either: it is dropped.

Root cause

While a queued message is being edited, the composer's draft target is a synthetic DraftId string rather than the thread ref:

• useQueuedRunEdit.ts#L98-L100 builds queued-edit:<env:thread>:<runId>, and L218-L219 returns it as draftTarget. ChatView.tsx#L522 passes it to the composer as composerDraftTarget.

The terminal's Add to chat calls the composer handle's addTerminalContext, which calls insertComposerDraftTerminalContext(composerDraftTarget, …) and returns silently on false (L3126).

In the store, insertTerminalContext needs both a draft key and a thread id. For a string target, resolveComposerThreadId only looks in draftThreadsByThreadKey. The queued-edit: id is never registered there, so it returns null, and the insert returns false before writing anything. addTerminalContexts has the same !threadId guard (L3169).

Meanwhile the terminal clears its selection right after calling the handler (ThreadTerminalDrawer.tsx#L825-L826), which is why the failure is invisible.

Plain-text drafts work on the same target because setPrompt and the other text and record setters only need the draft key, not a thread id. Only the terminal-context path needs the thread id.

Verified on main (ed05c0e)

I added this case to the existing useQueuedRunEdit.browser.test.tsx harness, which uses the real hook and the real store. It opens a queued edit with beginEdit, then makes the same insertTerminalContext(draftTarget, …) call that ChatComposer makes:

const target = requireHook(hook).draftTarget; // "queued-edit:env-1:thread-a:run-1"
const inserted = useComposerDraftStore.getState()
  .insertTerminalContext(target, "original @terminal-ref", context, 0);
expect(requireHook(hook).isEditing).toBe(true);
expect(inserted).toBe(false);                                  // passes: rejected
expect(draft?.prompt).toBe("original");                        // passes: unchanged
expect(draft?.terminalContexts).toHaveLength(0);               // passes: nothing stored
// control: same call on the thread ref
expect(store.insertTerminalContext(THREAD_A, "x @terminal-ref", context, 0)).toBe(true); // passes

vp test run --project browser … -t REPRO → 1 passed. A unit-level variant against composerDraftStore gives the same result.

Possible fix

Let the queued-edit target resolve to its thread. Options: register the edit draft in draftThreadsByThreadKey, have resolveComposerThreadId parse the queued-edit: id, or pass the thread id from ChatComposer (it already has activeThread.id). submitQueuedRunEdit already sends content.terminalContexts through buildMessageContext, so once the insert works the context should save with the edit. ChatComposer should also show a toast when the insert still returns false, rather than returning silently.

Impact

Minor bug or occasional failure

Version or commit

T3 Code (Beta) desktop 0.1.9. Source verified on main at ed05c0e43b64631f9780ad538fb4db1f0e0cd66d.

Environment

macOS (Apple Silicon), desktop app, integrated terminal.

Related reports

• [Bug]: Terminal "Add to chat" inserts into a hidden message draft while answering a question #24745 (closed): Terminal Add to chat while answering a question wrote to a hidden draft. Its fix added an info toast for that mode only. This report covers editing a queued message, a different composer mode where the insert is dropped silently.
• Queued message sends its original text while being edited #15611, Editing a queued message while a question is open submits the edit as the question answer #25434, [Bug]: Unsaved queued-message edits are lost when switching projects #23960: other queued-message edit bugs, but none cover adding context while editing.