openai / openai/codex

Codex App: add a cross-thread bookmark library for messages and selected snippets

Open
#46,813 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app enhancement session
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

What variant of Codex are you using?

Codex App (macOS; applicable to the desktop app generally)

What feature would you like to see?

Summary

Add a cross-thread bookmark library to Codex so users can save either:

  1. a complete user or assistant message; or
  2. a selected passage inside a message.

The saved item should remain connected to its source and be retrievable later without requiring the user to remember which thread contained it.

This proposal extends the thread-local bookmark ideas in #23350 and #38631. Those issues focus on returning to a location inside one thread. This request focuses on retrieval across many threads, selected-text granularity, and a centralized library.

Problem

Codex conversations often contain durable information—approved plans, architectural decisions, root-cause findings, commands, handoff summaries, or explanations—that users need days or weeks later.

Today, recovery depends on remembering the original thread, searching for exact wording, or copying content into an external notes app. Long-running users accumulate many threads, so thread-local navigation alone does not solve the retrieval problem.

Proposed interaction

Saving
  • Add Bookmark beside the existing message actions.
  • When text is selected, include Save selection in the selection toolbar.
  • Open a small save dialog with:
    • editable title;
    • optional note;
    • optional tags or collection;
    • source thread shown read-only.
  • Provide a fast path that saves immediately with an automatically derived title.
Retrieving

Add a Bookmarks destination in the Codex App sidebar or library area.

Each saved item should show:

  • title;
  • excerpt;
  • source thread;
  • whether it represents a whole message or a selected range;
  • creation date;
  • optional tags/collection.

Users should be able to:

  • search titles, notes, tags, and saved content;
  • filter by project/repository, thread, date, tag, or item type;
  • open the original thread at the exact message or selection;
  • copy a stable reference to the source;
  • remove or edit bookmark metadata.

Suggested MVP

  1. Save whole messages and selected text.
  2. Show all saved items in one cross-thread list.
  3. Full-text search over saved content and metadata.
  4. Jump to the exact source message.
  5. Persist bookmarks across app restarts.
  6. Preserve project/repository and thread provenance.
  7. Clearly handle deleted or unavailable source threads.

Tags, collections, sync, export, and AI-assisted organization can follow after the basic retrieval loop is reliable.

Implementation direction

This is an implementation proposal rather than a prescriptive internal design.

Stable source identity

A bookmark should reference stable conversation identifiers rather than a scroll offset:

thread_id
turn_id
item_id
selection_start   # optional
selection_end     # optional

A deep link could resolve the same identity, for example:

codex://threads/<thread_id>?item=<item_id>

For selected passages, the stored text can be used as a fallback anchor if the rendered representation changes.

Local data model

A minimal record could resemble:

Bookmark {
  id
  thread_id
  turn_id
  item_id
  selection_start?
  selection_end?
  saved_text
  title
  note?
  tags[]
  project_path_or_id?
  created_at
  updated_at
}

The initial implementation could use the app's existing local persistence layer. Keeping an immutable saved_text snapshot makes the bookmark useful even if the source becomes unavailable, while the source identifiers preserve navigation and provenance.

Application operations

The app-facing interface only needs a small set of operations:

create_bookmark(source, selection?, metadata)
list_bookmarks(filters, query, cursor)
update_bookmark(id, metadata)
delete_bookmark(id)
resolve_bookmark(id) -> source location and availability

Thread rendering can expose the stable item identity to message actions. The library can use paginated local queries and a debounced full-text search.

Source navigation

Opening a bookmark should:

  1. resolve the source thread;
  2. load the thread if necessary;
  3. scroll to the stable item;
  4. highlight the whole message or selected range briefly;
  5. show a clear fallback state when the source no longer exists.
Privacy and lifecycle
  • Bookmarks must inherit the privacy boundary of their source conversations.
  • No bookmark should become publicly shareable by default.
  • Deleting a thread should explicitly offer one of two behaviors:
    • delete its bookmarks; or
    • retain standalone saved snapshots marked Source unavailable.
  • If cross-device sync is added later, it should follow the same account and workspace boundaries as the underlying conversation.
  • Sensitive content should not be included in telemetry.

Acceptance criteria

  • A user can bookmark a complete user or assistant message.
  • A user can bookmark only a selected passage.
  • Saved items from different threads appear in one searchable library.
  • Every item visibly preserves source provenance.
  • Opening a valid bookmark returns to the exact source location.
  • Bookmarks survive app restart.
  • Deleted or unavailable sources produce a defined, non-destructive state.
  • Keyboard navigation and accessible labels are supported.
  • The feature works without requiring AI-generated organization.

Relationship to existing issues

  • #23350 requests user-created anchors inside a thread.
  • #38631 proposes representing those anchors in the conversation minimap.
  • This proposal complements both by defining the cross-thread retrieval layer, selected-passage support, provenance, persistence, and an implementation-oriented data model.

A thread-local marker and a cross-thread library could share the same bookmark record: the minimap represents it inside a thread, while the library makes it discoverable across the user's work.


Proposed by Leandro González Ruiz (@LGUIUX).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No implementation files, tests, or entry points are identified. Start by locating the existing thread-local bookmark work referenced in #23350 and #38631, then trace the Codex App's message actions and local persistence layer; done requires the full MVP and acceptance criteria in this proposal to work across threads.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.