Repository navigation
Codex Desktop: support project-level pinned conversations #20816
Description
What variant of Codex are you using?
App
What feature would you like to see?
Codex Desktop currently supports pinned conversations at the app/sidebar level. I would like an additional project-scoped pinning model: conversations that are pinned inside a specific project/workspace, separate from global/app-level pins.
A useful shape would be:
- Keep the existing app-level pinned conversations behavior.
- Add project-level pinned conversations that appear at the top of that project section.
- Limit project-level pins to a small number, for example up to 3 per project, so the project sidebar stays focused.
- Preserve these project pins across app restarts.
Why this matters
Projects often have a few durable operational threads: release/deploy thread, recurring QA/debug thread, project notes, or a long-running investigation. These are important within that project, but they do not necessarily belong in the global pinned list for the whole app.
Project-level pins would make it easier to keep the most useful project conversations close without turning global pins into a mixed list across unrelated workspaces.
Additional information
I searched existing Codex issues and found sidebar/history/pinned-tab-adjacent issues, but did not find an exact feature request for project-scoped conversation pins.
Activity
stevenxi commentedon May 15, 2026
It would be useful if the pinned conversations be tagged with the project name.
When there're multiple pinned convresations, takes a bit of time to understand which covnersation belongs to which porject, expecially when working on multiple projects parallel.
Additonally, if there's way to label/add note to the conversation, that would be extreamly helpful.
idaibin commentedon Jun 16, 2026
I’m hitting this in Codex Desktop as well.
When I pin active conversations across multiple local repositories, the pinned list does not show enough project context. I often have to open a thread first just to confirm which workspace it belongs to.
It would help if Codex showed the project/repository name or workspace folder basename in two places:
The full cwd/path could be available on hover or click. This would make it much safer to resume active work without accidentally continuing in the wrong project.
stevenxi commentedon Jun 16, 2026
A temporary workaround would be rename the session, include context / labels as prefix.
bmccarthyco commentedon Jul 13, 2026
I would not recommend setting a limit, this is for the user to decide. Keep it as simple as possible: global pin and/or project pin.
emmepra commentedon Jul 18, 2026
My concrete use case is keeping one durable Home/controller thread at the top of each project, while reserving global pins for cross-project work. Project-scoped pins would make re-entry much more reliable without turning the global pinned list into a mixed portfolio. I would also be interested in contributing an implementation if maintainers can point to the owning component and explicitly invite an external PR, per the repository contribution policy.
wizardlouis commentedon Oct 20, 2026
I'd like to add my support for project-level pinned conversations, along with a concrete usability example and a few suggested behaviors.
When managing multiple projects in Codex, I want important conversations to stay at the top of their own project's conversation list. If a conversation appears only in the global pinned section, returning to its project to find it can make it seem as though the conversation has disappeared. It also becomes harder to identify which project each pinned conversation belongs to.
Suggested behavior:
For developers working across multiple repositories, long-running investigations, or parallel development tasks, this would reduce the time spent finding conversations and preserve a clear project context. Pinning should change a conversation's access priority, not its project membership.
In my recent case, a conversation using my project's working directory was visible in the global pinned section, but its project association was empty. I have not established that pinning caused the missing association; I am sharing this as a discoverability problem rather than a confirmed pinning bug.