Add keyboard navigation and jump-to-message modal for long conversations

[Basit-Balogun10]

Problem

Long conversations become hard to navigate once they grow beyond a few turns. Search (Ctrl+F) can find text, but it cannot move between messages or jump to a specific turn in the conversation thread.

Closes #2360. Builds on #2321 to make the shortcuts configurable

Changes

• Added conversation navigation shortcuts so users can move through user messages with Alt/Option+Up and Alt/Option+Down.
• Added a message jump picker to jump directly to a specific user message.
• Kept the selected message in view while navigating so the keyboard flow stays anchored in the thread.
• Exposed the new bindings in the shortcuts sheet so the mac equivalent is visible as ⌥↑ and ⌥↓.

How did you test this?

Validated the touched renderer files with targeted static checks (get_errors).

Manual verification flow:

1. Open a task with a long conversation thread.
2. On macOS, press Option+Up and Option+Down to move backward and forward through user messages.
3. On Windows/Linux, press Alt+Up and Alt+Down to verify the same navigation path.
4. Press Cmd/Ctrl+J to open the message jump picker.
5. Type part of a message, select a result, and confirm the conversation scrolls to that turn.
6. Open the keyboard shortcuts sheet and confirm the new bindings are listed with the correct mac glyphs.
7. Repeat the navigation while focus is inside the conversation editor to confirm the shortcuts still work in-context.

Demo

chat-timeline-modal-and-keyboard-navigation-posthog-code.webm

Publish to changelog?

no

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/sessions/components/MessageJumpPicker.tsx:88-93
Superfluous alias: `allEntries` is always identical to `visibleEntries` and used only once in `handleSelect`. The intermediate name adds no clarity and violates the "no superfluous parts" rule.

```suggestion
  const handleSelect = useCallback(
    (id: string | null) => {
      if (id === null) return;
      const entry = visibleEntries.find((e) => e.id === id);
```

### Issue 2 of 3
apps/code/src/renderer/constants/keyboard-shortcuts.ts:282-305
**Dual source of truth for configurability**

`CONFIGURABLE_SHORTCUT_IDS` and the `configurable: true` flag on each `KeyboardShortcut` entry must be kept in sync manually. The flag controls which UI renderer (`ShortcutRecorder` vs `ShortcutKeys`) is shown in the sheet; the const array drives the TypeScript type and store logic. Adding a new shortcut requires updating both, but there is no compile-time or runtime guard that catches a mismatch — a shortcut could show `ShortcutRecorder` in the UI while the store type rejects its ID, or vice versa. Consider deriving one from the other: either generate `CONFIGURABLE_SHORTCUT_IDS` by filtering `KEYBOARD_SHORTCUTS` where `configurable === true`, or drop the `configurable` flag and compute it from membership in `CONFIGURABLE_SHORTCUT_IDS`.

### Issue 3 of 3
apps/code/src/renderer/features/sessions/components/ConversationView.tsx:217-221
**Jump picker doesn't anchor subsequent keyboard navigation**

`handleJumpToIndex` scrolls the list but never calls `setKeyboardFocusedMessageId`. After using `Cmd/Ctrl+J` to jump to a message, pressing `Alt+Up` / `Alt+Down` continues from whatever `keyboardFocusedMessageId` was before the picker opened (or from the first/last message if it was `null`), not from the just-jumped-to turn. A user who jump-navigates and then tries to step forward from that position will get a disorienting result. Consider calling `setKeyboardFocusedMessageId` with the target message's ID inside `handleJumpToIndex` (or pass the setter down to the picker).

_{Reviews (1): Last reviewed commit: "feat(code): add conversation message nav..." | Re-trigger Greptile}

[greptile-apps]

Superfluous alias: allEntries is always identical to visibleEntries and used only once in handleSelect. The intermediate name adds no clarity and violates the "no superfluous parts" rule.

Suggested change

	const allEntries = visibleEntries;
	const handleSelect = useCallback(
	(id: string | null) => {
	if (id === null) return;
	const entry = allEntries.find((e) => e.id === id);
	const handleSelect = useCallback(
	(id: string | null) => {
	if (id === null) return;
	const entry = visibleEntries.find((e) => e.id === id);

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/components/MessageJumpPicker.tsx
Line: 88-93

Comment:
Superfluous alias: `allEntries` is always identical to `visibleEntries` and used only once in `handleSelect`. The intermediate name adds no clarity and violates the "no superfluous parts" rule.

```suggestion
  const handleSelect = useCallback(
    (id: string | null) => {
      if (id === null) return;
      const entry = visibleEntries.find((e) => e.id === id);
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Dual source of truth for configurability

CONFIGURABLE_SHORTCUT_IDS and the configurable: true flag on each KeyboardShortcut entry must be kept in sync manually. The flag controls which UI renderer (ShortcutRecorder vs ShortcutKeys) is shown in the sheet; the const array drives the TypeScript type and store logic. Adding a new shortcut requires updating both, but there is no compile-time or runtime guard that catches a mismatch — a shortcut could show ShortcutRecorder in the UI while the store type rejects its ID, or vice versa. Consider deriving one from the other: either generate CONFIGURABLE_SHORTCUT_IDS by filtering KEYBOARD_SHORTCUTS where configurable === true, or drop the configurable flag and compute it from membership in CONFIGURABLE_SHORTCUT_IDS.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/constants/keyboard-shortcuts.ts
Line: 282-305

Comment:
**Dual source of truth for configurability**

`CONFIGURABLE_SHORTCUT_IDS` and the `configurable: true` flag on each `KeyboardShortcut` entry must be kept in sync manually. The flag controls which UI renderer (`ShortcutRecorder` vs `ShortcutKeys`) is shown in the sheet; the const array drives the TypeScript type and store logic. Adding a new shortcut requires updating both, but there is no compile-time or runtime guard that catches a mismatch — a shortcut could show `ShortcutRecorder` in the UI while the store type rejects its ID, or vice versa. Consider deriving one from the other: either generate `CONFIGURABLE_SHORTCUT_IDS` by filtering `KEYBOARD_SHORTCUTS` where `configurable === true`, or drop the `configurable` flag and compute it from membership in `CONFIGURABLE_SHORTCUT_IDS`.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Jump picker doesn't anchor subsequent keyboard navigation

handleJumpToIndex scrolls the list but never calls setKeyboardFocusedMessageId. After using Cmd/Ctrl+J to jump to a message, pressing Alt+Up / Alt+Down continues from whatever keyboardFocusedMessageId was before the picker opened (or from the first/last message if it was null), not from the just-jumped-to turn. A user who jump-navigates and then tries to step forward from that position will get a disorienting result. Consider calling setKeyboardFocusedMessageId with the target message's ID inside handleJumpToIndex (or pass the setter down to the picker).

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/components/ConversationView.tsx
Line: 217-221

Comment:
**Jump picker doesn't anchor subsequent keyboard navigation**

`handleJumpToIndex` scrolls the list but never calls `setKeyboardFocusedMessageId`. After using `Cmd/Ctrl+J` to jump to a message, pressing `Alt+Up` / `Alt+Down` continues from whatever `keyboardFocusedMessageId` was before the picker opened (or from the first/last message if it was `null`), not from the just-jumped-to turn. A user who jump-navigates and then tries to step forward from that position will get a disorienting result. Consider calling `setKeyboardFocusedMessageId` with the target message's ID inside `handleJumpToIndex` (or pass the setter down to the picker).

How can I resolve this? If you propose a fix, please make it concise.