Codex Desktop ignores thread.projectId created through its own App Server and places task in Recents
What version of Codex is running?
- Codex Desktop / ChatGPT macOS:
26.820.60940 - Remote
codex app-server:0.149.1
What operating system are you using?
macOS Desktop connected to a Linux remote workspace.
What is the problem?
A task created by a custom client through the same running App Server process used by Codex Desktop is visible in Desktop, but Desktop places it under Recents instead of its existing saved project.
The client supplies a valid App Server projectId to thread/start. App Server accepts and persists that ID. However, for the same task, Desktop reports projectId: null.
This appears to show that App Server's SQLite-backed project assignment and Desktop's saved-project/sidebar assignment remain separate, even when both clients use the same App Server process and socket.
Steps to reproduce
- Open a remote project in Codex Desktop. In this test, the saved Desktop project was named
actors. - Connect a custom JSON-RPC client to the exact App Server process/socket already used by Desktop.
- Use the App Server project API to import/create a project for the same repository root.
- Call
thread/startwith:
- a worktree cwd for that repository; and
- the valid App Server project ID from step 3.
- Read the task through App Server.
thread/readreturns the non-null project ID supplied above. - Inspect the same task through Desktop or open it in the macOS app.
Actual result
- The task is visible and can be opened in Desktop.
- Desktop reports
projectId: nullfor it. - The task appears under Recents, not under the existing
actorsproject. - Reading the Desktop project UUID through App Server
project/readreturnsproject not found. - The Desktop project and App Server project have different UUIDs despite referring to the same repository root.
Restarting Desktop did not move the task into the saved project.
Expected result
There should be a supported way for a client connected to Desktop's own App Server to start a task in an existing Desktop project, or Desktop should reconcile the App Server project/root assignment with its saved project and group the task correctly.
At minimum, the protocol should make the two meanings of projectId explicit. Ideally, Desktop would expose an atomic project-aware create/assign operation or a supported way to move an existing task into a saved Desktop project.
Why this case is different from related reports
This is not caused by two competing App Server processes. Both clients use the same running App Server. Sharing that process solves task ownership/opening, but does not solve project grouping.
Related issues:
- #40535 documents the separate Desktop and App Server project catalogs, but its reproduction uses a separate App Server process.
- #36250 explains that generic
thread/startdoes not persist Desktop's saved-project assignment. - #25498 requests project registration and moving tasks between projects.
- #39764 and #37021 report
projectId: nullwhen a Desktop assignment already exists; in this reproduction, the Desktop assignment appears never to be created.
PR #38940 added App Server project storage and thread/start.projectId, but it does not appear to bridge that project identity to Desktop's saved-project catalog.
Additional evidence
For one test task:
- App Server
thread/read: non-null App Server project UUID - Desktop task listing:
projectId: null - Desktop sidebar: task under Recents
- App Server
project/readusing the Desktop saved-project UUID:project not found
I can provide sanitized JSON-RPC request/response logs if useful.
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action