Skip to content

Selecting an @ thread reference with Tab fails while answering a question-tool prompt #18233

Description

@jackroberts236

What happened

While answering an agent's question-tool prompt in T3 Code, typing @ opens the picker for another thread. Pressing Tab to select it does not insert the reference; instead the text cursor moves back. The user wants to answer: “Speak with @ to figure this out.”

Diagnosis

Investigated against installed commit 8d199b4f7b918079161d5f43e0146c099301be08:

  • ChatComposer.tsx:4513-4515 routes Tab/Enter on an active picker to onSelectComposerItem.
  • The thread-selection branch (:4126-4152) inserts an inline reference into the active text, then adds its structured record to composerDraftTarget, the normal thread message draft.
  • Pending question answers use separate custom-answer state (ChatView.tsx:10362-10403). This callback can refocus the editor when its snapshot differs from the incoming text/cursor, which is relevant to the reported caret movement but does not establish its exact cause.
  • Question submission (ChatView.tsx:10214-10258 and respondToThreadUserInput) sends answers and optional per-question file attachments. It does not carry the normal message's structured thread-context payload.

The report therefore needs both selection/caret handling and preservation/delivery of thread references checked. Source inspection supports a context-delivery gap; the exact UI failure has not been independently reproduced during triage because computer-control access to T3 was unavailable. Provider-specific scope is not yet established.

Steps to reproduce

  1. Have an agent ask a question using its question tool, with a free-text answer allowed.
  2. In the answer composer, type @ and search for another existing thread.
  3. Highlight that thread and press Tab.
  4. Observe that the reference is not added and the caret moves back.

Expected: Tab inserts the selected reference without disrupting the caret; submitting the answer preserves enough thread identity/context for the agent to consult that thread when instructed.

Version

0.0.46-nightly.20261011.2967, commit 8d199b4f7b91; latest published nightly checked during triage.

Environment

T3 Code Nightly desktop, local backend; macOS arm64 25.6.0; Node 26.8.2.

Evidence

User observation: “it appears but I can't press tab to add it to the chat window ... moving the text cursor ... back and doesnt add it.”

No independent UI recording or deterministic automated reproduction was captured. The source references above are pinned to the installed release.

Related issues

#2635 and #2569 describe similar question-answer picker/caret failures for file references and are closed. This report concerns selecting another thread on the current nightly; it is a suspected regression or related gap, not a confirmed identical root cause. #8128 covers the related slash/skill picker path.

Fix applied or workaround

No T3 source changes applied. An unverified fallback is to paste the target thread's reference/link as ordinary answer text and explicitly ask the agent to consult it, or send the instruction through the normal composer after the question is resolved.

Filed by

Codex (GPT-6.1 Sol, medium reasoning) via t3 triage.

Activity

  1. juliusmarminge commented on Oct 11, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    This is a real bug on current main: @ thread picks are offered while answering a free-text question, but selection cannot deliver a usable thread reference through that path.

    What main does

    • ChatComposer.tsx onSelectComposerItem (thread branch) inserts the inline reference into the active text, then always calls addComposerDraftThreadContexts(composerDraftTarget, …) — the normal message draft, not the pending answer.
    • While a question is active, text edits go to custom-answer state, and the editor shows customAnswer.
    • ChatView.tsx onRespondToUserInput only sends answers plus optional attachmentsByQuestionId. The contract has no threadContexts field (file attachments are the documented exception — docs/user/question-attachments.md).

    So even when the chip text lands, the structured thread record never rides with the answer. The Tab/caret glitch matches the pending-answer focusAt-on-snapshot-mismatch path (and a sync effect that can reset the caret), but that UI failure was not reproduced here.

    Related: #2635 / #2569 (file @ in answers; closed, later regression note on #2635); #7805 (open; $ picker in answers); #7818 (closed unmerged; would disable mention pickers in answers); #17673 (open; Back to message — unrelated to thread-context delivery).

    Workaround: Answer in plain text, then @ the other thread from the normal composer after the question clears.

    Fix direction: wire thread context through the answer path, or stop offering thread items in the @ picker while a pending answer is active.

  2. added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions