Repository navigation
Description
What happened
Cite is too slow to pop up after selecting assistant text, and it needs a keyboard shortcut, similar to ChatGPT, Claude and Grok. The user sees the slowness with double-click, triple-click and drag selections.
Diagnosis
Delay. observeSelectionActions in apps/web/src/lib/selectionActions.ts delays the selection callback when event.detail >= 2:
schedule(event.detail >= 2 ? SELECTION_MULTI_CLICK_INTERVAL_MS : 0);
SELECTION_MULTI_CLICK_INTERVAL_MS is 500, so a double-click or triple-click waits 500 ms plus one animation frame. A triple-click waits too, even though no further selection step follows it.
A plain drag uses a 0 ms timer, so the 500 ms wait does not explain the drag report. These are possible causes from reading the code, and none has been reproduced:
- Cite stays hidden for the whole drag and only appears after release.
- A drag that starts soon after a previous click may report
detail >= 2and get the 500 ms wait. - Scrolling cancels the pending callback and reschedules it 150 ms later, so a streaming reply that keeps scrolling may delay Cite further.
Shortcut. Cite has no keyboard shortcut and no entry in the keybindings contract, so users cannot bind one. Pressing a letter while Cite is showing goes to the composer through type-to-focus and drops the selection. Tab then Enter is the only keyboard path, and it still has to wait for the button to appear.
Steps to reproduce
Delay:
- Open a thread with an assistant response.
- Double-click a word. Cite appears after about 500 ms.
- Triple-click a paragraph. Cite appears after about 500 ms.
- Drag-select some text. From the source, Cite should appear on the next frame after release, but the user also finds this slow.
Timings come from the source and were not measured in the app.
Shortcut:
- Select assistant text so that Cite shows.
- Press
R, or any other letter. The letter is typed into the composer instead of citing.
Version
T3 Code Desktop 0.1.5
Environment
macOS, arm64
Evidence
Source reading of v0.1.5. Current main has the same delay and no Cite shortcut. The Cite popup logic runs in the client and makes no server call. Local logs showed nothing related.
Related issues
- PR feat(web): press R to cite selected assistant text #25570 adds an
Rshortcut for Cite. It is open and unmerged, and would cover the shortcut part of this issue but not the delay. - Discussion Press R to cite selected assistant text #16154 proposes that shortcut, and a comment there also mentions the 500 ms wait and suggests right-click to cite.
Fix applied or workaround
No fix applied, and no setting changes either behavior. Drag-selecting avoids the 500 ms wait, and Tab then Enter cites without the mouse once Cite is showing.
Produced by Claude Opus 5.5 through Claude Code in T3 Code.
Activity
andras-gyarmati commentedon Nov 6, 2026
Another case from the desktop nightly (0.1.8-nightly.20261106.4262, macOS 26.6.2): the delay is longest the first time Cite appears in a thread; later selections in the same thread show it faster. This might be work done on first use, such as a lazy-loaded component or a first measurement, separate from the 500 ms multi-click wait. Not confirmed in the code.
magnusrodseth commentedon Nov 13, 2026
Same need here. I select assistant text and cite it many times per session, so a keyboard shortcut would help a lot.
Please make it a command in the keybindings contract (for example
composer.cite), so it can be rebound in Settings → Keybindings. A fixedR, as in #25570, is a good default, but it should not be the only option. Today I useTabthenEnteras a workaround.