feat: setting to anchor sent messages at the top of the timeline

[connorch]

When you send a message, the timeline pins to the bottom and the reply streams in right above the composer. Reading a long answer that way means watching the bottom edge. T3 Code already holds the first message of a thread near the top so its turn reads downward; there was no way to get that for every message.

This adds a client setting, Settings → General → Sent message position (Bottom / Top, default Bottom). With Top, every direct send reuses the existing first-message anchoring: the message holds at the top of the viewport and the reply streams below it. Mobile gets the same choice as a device-local switch under Settings → Thread behavior → Sent messages at top.

Behavior notes:

• Messages that queue behind a running turn keep the current position; they aren't the live turn.
• The anchor still releases on tool activity, exactly as the first-message anchor does today (fix(web): stop tool calls from leaving a blank page in threads #7971 upstream), so this is "first-message behavior for every send".
• resolveChatListAnchoredEndSpace now matches the anchor at any index; it was the only place encoding the first-message rule.

Made by Fable 5.1 using Claude Code.

🤖 Generated with Claude Code

[connorch]

Filed against the wrong repo by mistake; this belongs on the connorch fork.

[macroscopeapp]

🟡 Medium components/ComposerPromptEditorTiptap.tsx:1021

Large copied thread transcripts are staged as pasted-text.txt instead of becoming transcript draft cards. ComposerPromptEditorTiptap receives paste events through onPasteCapture, but onComposerPaste calls preventDefault() and stopPropagation() for pastes at least 32 KiB or exceeding the prompt limit before handlePaste reaches onPasteTranscripts at line 1021. The capture handler must allow transcript extraction to run before folding these pastes into attachments.

Also found in 1 other location(s)

apps/web/src/components/chat/ChatComposer.tsx:6910

onPasteTranscripts cannot receive a large transcript paste because the editor's onPasteCapture first runs onComposerPaste, which folds text at 32 KiB (or when the prompt limit would be exceeded), calls preventDefault()/stopPropagation(), and stages it as pasted-text.txt. Thus realistic long copied threads never reach the transcript extractor and are sent as an attachment rather than transcript cards.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ComposerPromptEditorTiptap.tsx around line 1021:

Large copied thread transcripts are staged as `pasted-text.txt` instead of becoming transcript draft cards. `ComposerPromptEditorTiptap` receives paste events through `onPasteCapture`, but `onComposerPaste` calls `preventDefault()` and `stopPropagation()` for pastes at least 32 KiB or exceeding the prompt limit before `handlePaste` reaches `onPasteTranscripts` at line 1021. The capture handler must allow transcript extraction to run before folding these pastes into attachments.

Also found in 1 other location(s):
- apps/web/src/components/chat/ChatComposer.tsx:6910 -- `onPasteTranscripts` cannot receive a large transcript paste because the editor's `onPasteCapture` first runs `onComposerPaste`, which folds text at 32 KiB (or when the prompt limit would be exceeded), calls `preventDefault()`/`stopPropagation()`, and stages it as `pasted-text.txt`. Thus realistic long copied threads never reach the transcript extractor and are sent as an attachment rather than transcript cards.

[macroscopeapp]

🟡 Medium chat/ChatComposer.tsx:5667

Stashing a draft after onPasteTranscripts drops composerTranscripts from the stash and leaves those transcripts attached to the cleared live composer, so restoring the stash loses the transcript while a later prompt can still send it unintentionally. Update the stash serialization and draft-clear path to persist and remove composerTranscripts alongside the other draft content.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/chat/ChatComposer.tsx around line 5667:

Stashing a draft after `onPasteTranscripts` drops `composerTranscripts` from the stash and leaves those transcripts attached to the cleared live composer, so restoring the stash loses the transcript while a later prompt can still send it unintentionally. Update the stash serialization and draft-clear path to persist and remove `composerTranscripts` alongside the other draft content.

[macroscopeapp]

🟡 Medium components/RightPanelTabs.tsx:1151

Hovering an open device tab now shows only title, so users cannot see the selected device's host label or OS/version from the tab bar. The replacement tooltip at this path removed the DeviceTabTooltip content, which was the only tab-bar access to that identifying information; restore DeviceTabTooltip for device tabs.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/RightPanelTabs.tsx around line 1151:

Hovering an open device tab now shows only `title`, so users cannot see the selected device's host label or OS/version from the tab bar. The replacement tooltip at this path removed the `DeviceTabTooltip` content, which was the only tab-bar access to that identifying information; restore `DeviceTabTooltip` for device tabs.

[macroscopeapp]

🟠 High vcs/GitVcsDriverCore.ts:3101

provisionContextDirectory overwrites a tracked .context/_.txt with an empty file, immediately dirtying the new worktree and losing that worktree's checked-out contents. The ignore entry does not protect tracked files; only write the placeholder when it does not already exist.

   const contextDirPath = path.join(worktreePath, WORKTREE_CONTEXT_DIRECTORY_NAME);
-    yield* fileSystem.writeFileString(
-      path.join(contextDirPath, WORKTREE_CONTEXT_PLACEHOLDER_FILE),
-      "",
-    );
+    const placeholderPath = path.join(contextDirPath, WORKTREE_CONTEXT_PLACEHOLDER_FILE);
+    if (!(yield* fileSystem.exists(placeholderPath))) {
+      yield* fileSystem.writeFileString(placeholderPath, "");
+    }

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/vcs/GitVcsDriverCore.ts around lines 3101-3106:

`provisionContextDirectory` overwrites a tracked `.context/_.txt` with an empty file, immediately dirtying the new worktree and losing that worktree's checked-out contents. The ignore entry does not protect tracked files; only write the placeholder when it does not already exist.

[macroscopeapp]

🟡 Medium components/Sidebar.drag.ts:221

Dragging a multi-row pinned/active worktree card into settled computes its gap 46px too short, shifting every row below the target to the wrong position. For the active member, memberIndex is undefined, so line 221 uses the destination fallback (slimHeight, 36px) instead of the source card-row height (82px); use the active member's source-section height for that term.

-              return sum + (memberRect?.height ?? fallback) + 1;
+              return sum + (memberRect?.height ?? (key === active.key && (active.section === "pinned" || active.section === "active") ? cardHeight : fallback)) + 1;

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/Sidebar.drag.ts around line 221:

Dragging a multi-row pinned/active worktree card into `settled` computes its gap 46px too short, shifting every row below the target to the wrong position. For the active member, `memberIndex` is undefined, so line 221 uses the destination `fallback` (`slimHeight`, 36px) instead of the source card-row height (82px); use the active member's source-section height for that term.

[macroscopeapp]

🟡 Medium components/ComposerPromptEditorTiptap.tsx:150

Pasting the same <thread_transcript> twice creates duplicate drafts with the same serialized id, so ComposerTranscriptCards renders duplicate React keys and removing either card deletes both; if left in place, sending includes the transcript twice. Deduplicate transcript IDs before passing them to onPasteTranscripts (or in addTranscripts) so each ID produces only one draft.

Also found in 1 other location(s)

apps/web/src/composerDraftStore.ts:3883

addTranscripts removes existing entries whose IDs occur in the input but then appends the entire input unchanged. Pasting the same <thread_transcript> block twice yields two drafts with the same embedded ID; React renders duplicate keys, one remove action deletes both cards, and sending appends the transcript block twice instead of treating the ID as one transcript.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ComposerPromptEditorTiptap.tsx around line 150:

Pasting the same `<thread_transcript>` twice creates duplicate drafts with the same serialized `id`, so `ComposerTranscriptCards` renders duplicate React keys and removing either card deletes both; if left in place, sending includes the transcript twice. Deduplicate transcript IDs before passing them to `onPasteTranscripts` (or in `addTranscripts`) so each ID produces only one draft.

Also found in 1 other location(s):
- apps/web/src/composerDraftStore.ts:3883 -- `addTranscripts` removes existing entries whose IDs occur in the input but then appends the entire input unchanged. Pasting the same `<thread_transcript>` block twice yields two drafts with the same embedded ID; React renders duplicate keys, one remove action deletes both cards, and sending appends the transcript block twice instead of treating the ID as one transcript.

[macroscopeapp]

🟡 Medium components/ChatView.tsx:8257

When chatTurnAnchor === "top"``, a later metadata, attachment, or startThreadTurnfailure removes the optimistic message but leaves the timeline inanchoring-new-turn` with an anchor for that deleted message. Because the failure path never clears the anchor or restores the scroll position, subsequent live-follow and timeline positioning remain stuck until navigation or another send; clean up the pending anchor and restore scrolling when removing the optimistic message.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ChatView.tsx around line 8257:

When `chatTurnAnchor === "top"``, a later metadata, attachment, or `startThreadTurn` failure removes the optimistic message but leaves the timeline in `anchoring-new-turn` with an anchor for that deleted message. Because the failure path never clears the anchor or restores the scroll position, subsequent live-follow and timeline positioning remain stuck until navigation or another send; clean up the pending anchor and restore scrolling when removing the optimistic message.

[macroscopeapp]

🟡 Medium

t3code/apps/web/src/components/ChatView.tsx

Line 7539 in ceb6b56

if (feedbackCommand && multipleModelSelections === null) {

A Codex feedback command with a pasted transcript is submitted as feedback without the transcript context, and submitCodexFeedback then clears the draft, silently discarding the transcript. Require composerTranscripts.length === 0 in this feedback-command guard so transcript-bearing commands are sent through the normal message path.

Also found in 1 other location(s)

apps/web/src/components/chat/ChatComposer.tsx:5667

A pasted transcript added here is also ignored by the Codex feedback-command path: that path does not require composerTranscripts to be empty before parsing /feedback, submits only the command, and clears the draft. Consequently a transcript pasted together with a Codex feedback command is silently dropped rather than sent as transcript context.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ChatView.tsx around line 7539:

A Codex feedback command with a pasted transcript is submitted as feedback without the transcript context, and `submitCodexFeedback` then clears the draft, silently discarding the transcript. Require `composerTranscripts.length === 0` in this feedback-command guard so transcript-bearing commands are sent through the normal message path.

Also found in 1 other location(s):
- apps/web/src/components/chat/ChatComposer.tsx:5667 -- A pasted transcript added here is also ignored by the Codex feedback-command path: that path does not require `composerTranscripts` to be empty before parsing `/feedback`, submits only the command, and clears the draft. Consequently a transcript pasted together with a Codex feedback command is silently dropped rather than sent as transcript context.

[macroscopeapp]

🟡 Medium components/ChatView.tsx:7723

A queued message containing only transcripts is silently discarded instead of starting a turn. sendQueuedMessage still calls deriveComposerSendState without message.transcripts, so the message is classified as empty, queue.finishSend runs, and the transcript is never appended to the outgoing prompt; include queued transcripts in both the sendability check and prompt construction.

Also found in 2 other location(s)

apps/web/src/components/chat/ChatComposer.tsx:2246

Counting composerTranscripts as sendable enables a transcript-only submission while a running turn is queued, but sendQueuedMessage still calls deriveComposerSendState without including message.transcripts. That queued sender treats the message as empty, calls queue.finishSend, and never appends the transcript to the outgoing prompt, so a transcript-only queued message is silently lost.

apps/web/src/components/chat/sendQueuedMessage.ts:99

A queued message containing only pasted transcript cards is silently discarded. hasSendableContent is calculated before the new append and elementContextCount excludes message.transcripts, so an empty prompt with no attachments/other contexts reaches the early finishSend return and never sends the transcript that this reduce would append. Direct composer submission includes transcript cards in that count.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ChatView.tsx around line 7723:

A queued message containing only `transcripts` is silently discarded instead of starting a turn. `sendQueuedMessage` still calls `deriveComposerSendState` without `message.transcripts`, so the message is classified as empty, `queue.finishSend` runs, and the transcript is never appended to the outgoing prompt; include queued transcripts in both the sendability check and prompt construction.

Also found in 2 other location(s):
- apps/web/src/components/chat/ChatComposer.tsx:2246 -- Counting `composerTranscripts` as sendable enables a transcript-only submission while a running turn is queued, but `sendQueuedMessage` still calls `deriveComposerSendState` without including `message.transcripts`. That queued sender treats the message as empty, calls `queue.finishSend`, and never appends the transcript to the outgoing prompt, so a transcript-only queued message is silently lost.
- apps/web/src/components/chat/sendQueuedMessage.ts:99 -- A queued message containing only pasted transcript cards is silently discarded. `hasSendableContent` is calculated before the new append and `elementContextCount` excludes `message.transcripts`, so an empty prompt with no attachments/other contexts reaches the early `finishSend` return and never sends the transcript that this `reduce` would append. Direct composer submission includes transcript cards in that count.

[macroscopeapp]

🟡 Medium vcs/GitVcsDriverCore.ts:3086

The info/exclude rule ${WORKTREE_CONTEXT_DIRECTORY_NAME}/ hides .context directories at every nesting level, so users cannot see or stage files in pre-existing paths such as packages/foo/.context/.... Prefix the pattern with / to restrict it to the repository-root scratch directory.

Suggested change

	const excludeEntry = `${WORKTREE_CONTEXT_DIRECTORY_NAME}/`;
	const excludeEntry = `/${WORKTREE_CONTEXT_DIRECTORY_NAME}/`;

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/vcs/GitVcsDriverCore.ts around line 3086:

The `info/exclude` rule `${WORKTREE_CONTEXT_DIRECTORY_NAME}/` hides `.context` directories at every nesting level, so users cannot see or stage files in pre-existing paths such as `packages/foo/.context/...`. Prefix the pattern with `/` to restrict it to the repository-root scratch directory.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This is a broad 105-file feature bundle introducing new transcript, worktree-card, browser, diff, provider, and installation behavior, including a default change to sidebar behavior and new Git/worktree side effects. Multiple unresolved Medium and High findings also identify data-loss, performance, and interaction risks that require human attention.

Not approved because:

• 15 blocking correctness issues found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}