Codex Desktop: add a prompt-first user-intent navigation rail for long agent threads

What variant of Codex are you using?

Codex workspace in the unified ChatGPT desktop app. This request is primarily about the desktop conversation experience.

What feature would you like to see?

Summary

Add a first-class, collapsible user-intent navigation rail to long Codex threads.

I noticed that the ChatGPT web experience can provide a compact right-side navigation entry for each conversation turn, making long conversations much easier to revisit. Codex threads need this even more, but the Codex workspace in the desktop app currently lacks an equivalent prompt-level navigator.

My core proposal is not a generic AI-generated table of contents. It is a stable structural index in which:

• each user instruction is a primary anchor;
• all agent activity caused by that instruction belongs to the same turn;
• tool calls, logs, diffs, and progress updates do not become noisy top-level entries;
• the rail shows where the user is, what the agent is working on, and where earlier intent changed.

Proposed interaction

Thread content                                  User-intent rail

[User] Investigate the failing auth flow        ● Investigate auth flow
  progress / tool calls / command output
  findings / final response

[User] Implement the refresh-token fix          ◉ Implement refresh fix
  plan / edits / tests / diff                    ├ editing
                                                 └ tests running

[User] Compare it with the previous design      ○ Compare designs

The rail should:

1. Show one primary entry for every user prompt.
2. Use a deterministic truncated prompt preview as the default label, with the full prompt available on hover or focus.
3. Highlight the turn currently nearest the top of the viewport.
4. Jump to the exact user-message boundary when selected.
5. Optionally show a small state indicator such as running, input required, completed, interrupted, or failed.
6. Keep tool calls and intermediate output grouped under the initiating prompt rather than listing them as peer entries.
7. Support previous/next user-turn keyboard navigation using the same anchors.
8. Collapse into a compact rail or temporary overlay on narrow windows.

Why a user-intent rail rather than a generated outline?

A generated outline can be useful, but it introduces unstable titles, extra latency, and another summarization layer. User prompts already describe the intent of each iteration and provide a natural, deterministic structure.

This makes the navigation model:

• stable while the assistant is streaming;
• understandable without another model call;
• compatible with lazy loading and transcript virtualization;
• useful for comparing requirements, decisions, and results across iterations;
• less noisy than indexing every assistant or tool message.

Codex conversations are not just chats. They are execution histories. The useful unit of navigation is therefore the user's intent together with the work it triggered.

Minimal viable version

The first release can stay narrow:

• user-prompt anchors only;
• deterministic preview labels;
• active-turn highlighting;
• click-to-jump;
• collapsible/responsive presentation;
• keyboard and screen-reader support.

Status markers and nested milestones can be added later without changing the underlying anchor model.

Acceptance criteria

• In a thread with 100+ turns, any loaded user prompt can be reached in one action.
• The selected anchor consistently lands on the correct user-message boundary.
• Existing anchors do not reorder or change labels while output streams.
• Long tool output and diffs do not flood the rail.
• The implementation does not require mounting the entire conversation DOM.
• The current turn is visibly indicated while scrolling.
• Narrow layouts preserve the usable transcript width.
• Every navigation item is keyboard-focusable and exposes an accessible label and current-state indication.

Technical feasibility

The public app-server protocol already models threads and turns with stable identities and supports paginated turn listing. That suggests the rail can be based on existing conversation structure rather than requiring an additional model-generated outline or a new parallel content model.

The important implementation constraint is to bind anchors to stable turn/message identities, not temporary DOM positions, so navigation remains correct after streaming, resume, compaction, or virtualization.

Contribution

I am happy to help refine the interaction, test it against genuinely long Codex sessions, provide a visual prototype, and implement a scoped version if the Codex team invites a code contribution.