Codex Desktop Windows: chats created from a saved project still show as “No chats” under that project
What version of the Codex App are you using?
Codex Desktop for Windows. Observed installed package path/version family:
OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
What subscription do you have?
ChatGPT Plus/Pro user. Exact account details intentionally omitted from the public issue.
What platform is your computer?
Windows desktop app.
What issue are you seeing?
Chats created directly from a saved project in the Codex Desktop sidebar do not appear under that project. The project section continues to display Italian localized text:
Nessuna chat
which corresponds to No chats.
This is misleading because the threads are not lost and do have the correct working directory. They are returned by thread search/listing and have cwd equal to the saved project path, but the project sidebar still shows no chats.
Local project involved
Redacted path form:
%USERPROFILE%\Documents\Codex\2026-04-24\browser-use-plugin-browser-use-openai
Project label:
Laboratorio tecnico Argo - Archivio e AI locale
Steps to reproduce
- Save/add a local project in Codex Desktop.
- Create a new chat from that saved project in the sidebar.
- Send a message in the chat.
- Return to the project section in the sidebar.
- Observe that the project still shows
Nessuna chat/No chats. - Restart Codex.
- Reboot Windows.
- Observe that the project still shows
Nessuna chat/No chats.
Expected behavior
A chat created from a saved project should appear under that saved project in the sidebar.
If the chat has cwd equal to the saved project path, the project sidebar should not say No chats.
Actual behavior
The chat is visible/searchable as an autonomous/recent thread, and the runtime uses the correct project directory, but the saved project group still shows Nessuna chat.
Diagnostic evidence
Three affected thread IDs:
019eebeb-e153-7713-8a8b-005776df5d8e
019eebf2-0dd1-7110-ad2f-498b622cbdbd
019eec03-c6dc-73f2-a02e-f659d00d4d14
list_projects returns the saved project correctly:
projectId/path = %USERPROFILE%\Documents\Codex\2026-04-24\browser-use-plugin-browser-use-openai
label = Laboratorio tecnico Argo - Archivio e AI locale
list_threads returns the affected threads with:
cwd = %USERPROFILE%\Documents\Codex\2026-04-24\browser-use-plugin-browser-use-openai
The local .codex-global-state.json initially did not contain thread-workspace-root-hints entries for the affected project threads. As a diagnostic experiment, I added entries mapping those thread IDs to the project root. The entries persisted after restart, but the project sidebar still displayed Nessuna chat.
So either the sidebar does not use thread-workspace-root-hints for this grouping, or a separate index/cache/grouping mechanism is stale or inconsistent with the underlying thread metadata.
Impact
This makes the project sidebar unreliable as a working-memory surface. A user can create a chat from a project and reasonably believe the chat will remain under that project, but the UI reports No chats even though the thread exists and has the correct cwd.
It creates a data-loss-class UX problem even when no data is actually lost.
Related issues
This appears related to the broader family of project/sidebar/thread indexing problems, including:
- #21128
- #20741
- #27159
- #27843
- #28094
- #29130
I am filing this as a fresh reproducible variant because the chat was created directly from the saved project, the project path is a normal Windows local path rather than WSL, and adding thread-workspace-root-hints did not make the sidebar list the chats.
Requested guidance / fix
Please clarify or fix the authoritative source of truth for project-to-thread grouping in Codex Desktop.
At minimum, Codex should provide one of the following:
- a supported way to rebuild the project/sidebar thread index from durable local state;
- a documented local recovery command;
- project sidebar grouping based directly on persisted thread
cwdwith proper path normalization; - or a UI action to move/attach an existing thread to a saved project.
Note on recognition / compensation
I understand this report may not qualify for OpenAI security or safety bug bounty programs, because it appears to be a product/UI bug rather than a security vulnerability. Still, if OpenAI offers any recognition, credits, or compensation for reproducible product bugs that improve Codex reliability, I would appreciate consideration.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗