Codex App: add a global Pins view for messages, text selections, and generated files

Open 💬 3 comments Opened Jul 10, 2026 by swyzhc

What variant of Codex are you using?

Codex App (macOS)

What feature would you like to see?

Codex currently lets me pin an entire conversation, but the thing I need later is often one message, part of a message, or a generated file inside that conversation.

A recent example: I asked Codex to create a technical document in Markdown. The file still exists, but to find it from Codex I have to remember which thread produced it, open that thread, and locate the original message. The same problem comes up with design decisions, useful explanations, and command output that I know I will need again.

I would like to pin individual items from a message's hover or context menu, then access them from a global Pins view.

Proposed first version

From a conversation, the user can:

Pin a whole user or assistant message.
Pin selected text within a message.
Pin a linked or generated file.

The Pins view would:

Show items from the current project by default, with an option to view all projects.
Display pinned text directly. Long messages can be collapsed.
Show the source project, thread, and date.
Provide an action to jump back to the exact source message.
Preview or open the current version of a pinned file.
Show the file as unavailable if it has been moved or deleted.
Allow the user to remove a Pin.

A user should be able to Pin an item with one explicit action and return to it later within two or three actions, without having to find and search the original thread.

Why thread pinning and search do not solve this

Pinning a thread keeps the whole conversation accessible, but the user still has to find the relevant message inside it.

Search helps when the user remembers the right words. A Pin records the user's intent at the moment the content is created: "I know I will need this again."

Scope

The first version can stay manual and lightweight:

No automatic or AI-selected Pins.
No tags, folders, notes, or knowledge management features.
No natural-language Pin commands.
No file copies or backups. A file Pin points to the original file.
No cross-device or cross-surface sync requirement for the first version.

Pins should persist across app restarts.

Additional information

Related issues:

#23350 proposes manual bookmarks inside a single thread.
#26425 proposes a broader timeline and conversation navigator.
#30790 proposes message-level navigation to a specific turn or item.
#16672 proposes global search across conversation content.

This request is broader than thread-local bookmarks but narrower than a full conversation timeline. It asks for a manually curated, cross-thread collection of saved messages, selections, and file references.

If the maintainers prefer to extend #23350 instead of tracking this separately, the main behavior I would like to preserve is the project-scoped global Pins view.

View original on GitHub ↗

3 Comments

pdurlej · 1 month ago

Related work that may provide a shared backend primitive: #26889 proposes bounded, thread-scoped context pins that survive compaction and are re-supplied to the model as untrusted user context. There is a server-side implementation branch here:

https://github.com/openai/codex/compare/main...pdurlej:feature/thread-context-pins-refresh

I see the two requests as complementary rather than duplicates. This issue focuses on retrieval and a global Pins view; #26889 focuses on model-context continuity. A message or text-selection action could save an item for later retrieval and, when the user explicitly wants Codex to keep using it, back it with a thread context pin.

Claude Code's current Pin as chapter affordance is a useful product precedent: users can explicitly mark part of a conversation to remain in active context. Our proposed first slice deliberately avoids UI and file pins; it provides persistence, experimental app-server CRUD, bounded untrusted injection, and reinjection after compaction, which could serve as the backend foundation for a later message-level pin action.

abcjhby2871 · 1 month ago

+1 to message/item-level Pins. A useful extension would be optional lightweight user-defined tags on pinned messages, selected text, files, or exact conversation positions.

Example tags could include decision, todo, bug, experiment, result, or important. The main value is not only saving an item, but being able to quickly filter and revisit the relevant subset later in a long-running project.

Suggested behavior:

allow one or more optional tags when pinning a message, selection, file, or location;
edit/remove tags later without recreating the Pin;
filter Pins by tag within the current thread, current project, or global Pins view;
preserve the exact source location and support click-to-jump back to it;
where ChatGPT Chat, Quick Chat, and Codex expose the same conversation, keep the Pin/tag metadata consistent across those surfaces.

A first version could remain deliberately small: free-form text tags plus filtering, with no folders, hierarchy, automatic classification, or full knowledge-management system required. This would complement the thread-local bookmarks in #23350 and the precise turn/item navigation proposed in #30790.

starSumi · 22 days ago

There is a useful follow-up layer between the proposed global Pins view and full automatic memory: user-managed named collections of source threads and turns.

The first Pins version can remain as scoped in this issue. A later collection layer could add:

user-created, renamed, and archived collections;
many-to-many membership, so one thread or turn can appear in several collections;
members that reference either a whole thread or an exact completed turn;
inclusion of archived source threads without unarchiving them;
source metadata and a jump back to the original thread/turn;
explicit search/read or composer attachment of one collection when the user wants Codex to reuse it.

This is different from a sidebar folder. A folder primarily controls navigation and usually gives a thread one placement. A knowledge collection is a curated retrieval scope: it can mix exact turns from several threads and can be selected as context for a later task.

The agent-facing semantics also need to differ from replaying transcript history. Collection members should be returned as typed, source-aware, untrusted retrieved context. They should preserve provenance such as source thread, turn, time, and workspace, while the destination thread's current instructions, permissions, and environment remain authoritative. Tool calls, tool results, reasoning records, and historical side effects should not be replayed merely because a source turn was selected.

Several shipped or proposed pieces make this a bounded follow-up rather than a new memory system:

#14923 records that persistent cross-thread list/read/send/fork/archive primitives have shipped.
#16672 records that cross-project title/content search and result jumping have shipped.
This issue supplies the manual item-curation entry point.
#31006 covers user-selected context attachment in the composer.
#28860 covers deriving a new thread from selected historical turns, which is separate from referencing a collection in an existing thread.

A narrow first collection slice could therefore be manual CRUD plus ThreadRef/TurnRef membership and source navigation. Automatic classification, embeddings, silent context injection, external knowledge-base import, and cross-device sync can remain out of scope.

Would maintainers prefer named collections and explicit agent retrieval to be tracked as a follow-up to Global Pins, or as a separate design issue because it adds agent-facing context semantics?