VS Code Codex threads appear in Recents but are not associated with the matching Codex App project

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.41515

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Existing Codex conversations created with the VS Code Codex extension are visible in Codex Desktop under Recents, but they are not associated/grouped with the corresponding Codex Desktop project in the Projects sidebar.

For example, a Codex thread created through the VS Code extension has a cwd pointing to a local Git repository:

/Users/<user>/path/to/<repository>

The same repository is also registered as a project in Codex Desktop.

The VS Code-created thread appears under Recents and can be opened normally.

When opening the thread from Recents, Codex Desktop correctly shows that the thread is associated with the corresponding local repository/folder and that it runs on the local computer. This indicates that Codex Desktop can resolve the repository associated with the thread.

However, the thread does not appear in the task/thread list under the matching project in the Projects sidebar.

In contrast, threads created directly from Codex Desktop for the same repository are immediately grouped under the corresponding project.

The affected VS Code thread is also correctly present in the local Codex storage:

• ~/.codex/sessions/
• ~/.codex/state_5.sqlite
• ~/.codex/session_index.jsonl

Therefore, this does not appear to be a missing-history or session-import issue. It appears to be specifically a project association/grouping issue in Codex Desktop.

Environment

• OS: macOS
• Codex App version: 26.803.41515
• VS Code Codex CLI version recorded in an affected thread: 0.146.0-alpha.9.2
• Codex Desktop CLI version recorded in a newly created Desktop thread: 0.147.0-alpha.6.5
• VS Code thread originator: codex_vscode
• Desktop thread originator: codex_work_desktop

Evidence

An affected VS Code-created thread has session metadata similar to:

id = <thread-id>
originator = codex_vscode
source = vscode
thread_source = user
cwd = /Users/<user>/path/to/<repository>
history_mode = legacy

The corresponding rollout file exists under:

~/.codex/sessions/YYYY/MM/DD/rollout-<timestamp>-<thread-id>.jsonl

The same thread is also present in state_5.sqlite.
For example:

SELECT id
FROM threads
WHERE id='<thread-id>';

returns the expected thread.
Inspecting the row shows:

source = vscode
thread_source = user
archived = 0
cwd = /Users/<user>/path/to/<repository>
title = <VS Code thread title>

The same thread is also present in session_index.jsonl:

{
  "id": "<thread-id>",
  "thread_name": "<VS Code thread title>",
  "updated_at": "<timestamp>"
}

Multiple older VS Code/CLI threads are present in the local Codex history/index.
The important point is that the affected thread is successfully recognized by Codex Desktop:

• It appears under Recents.
• It can be opened normally.
• Codex Desktop displays the associated repository/folder.
• The local database contains the correct cwd.
• The thread is not archived.

However, it is not grouped under the corresponding project in the Projects sidebar.
In contrast, a newly created Codex Desktop thread has metadata similar to:

originator = codex_work_desktop
source = vscode
thread_source = user

and is immediately grouped under the corresponding project.
This suggests that Codex Desktop can read and resolve VS Code-created threads, but does not associate/group them with an existing Desktop project.

What steps can reproduce the bug?

1. Open a local Git repository in VS Code.

1. Create and use a conversation through the Codex VS Code extension.

1. Confirm that the thread metadata uses the repository path as its cwd.

1. Add/open the same repository as a project in Codex Desktop.

1. Open Codex Desktop.

1. The VS Code-created conversation appears under Recents and can be opened normally.

1. Open the conversation from Recents. Codex Desktop correctly identifies its associated local repository/folder.

1. Expand/select the matching project in the Projects sidebar.

1. The VS Code-created conversation is not listed under that project.

1. Create a new thread directly from Codex Desktop using the same project.

1. The Desktop-created thread is correctly grouped under the project, while the VS Code-created thread remains only under Recents.

Restarting Codex Desktop does not change the project association.

What is the expected behavior?

When a Codex thread created through the VS Code extension has a cwd that matches a repository/project already registered in Codex Desktop, the thread should automatically be associated with and displayed under that project in the Projects sidebar.

The conversation may also remain visible under Recents, but it should not exist only as an ungrouped Recent item when Codex Desktop can already identify the corresponding repository/project.

Ideally, threads created from VS Code, CLI, and Codex Desktop that belong to the same local repository should be grouped under the same Codex Desktop project.

Additional information

The affected thread is visible and usable in Codex Desktop under Recents, so this does not appear to be a history visibility or import problem.
When the thread is opened from Recents, Codex Desktop correctly shows:

• the thread title,
• the associated local repository/folder,
• and that it runs on the local computer.

The local database also contains the correct cwd, and the thread has:

source = vscode
thread_source = user
archived = 0

This suggests that Codex Desktop can resolve the repository associated with the thread, but does not attach/group the imported VS Code thread under the corresponding Desktop project.
The difference between:

originator = codex_vscode

and:

originator = codex_work_desktop

may be relevant, since Desktop-created threads are grouped correctly while VS Code-created threads are not.
The issue may therefore be related to project association logic or filtering based on thread origin/source rather than session discovery itself.