Codex Desktop ignores thread.projectId created through its own App Server and places task in Recents #40935

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

1. Open a remote project in Codex Desktop. In this test, the saved Desktop project was named actors.
2. Connect a custom JSON-RPC client to the exact App Server process/socket already used by Desktop.
3. Use the App Server project API to import/create a project for the same repository root.
4. Call thread/start with:
   • a worktree cwd for that repository; and
   • the valid App Server project ID from step 3.
5. Read the task through App Server. thread/read returns the non-null project ID supplied above.
6. 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: null for it.
• The task appears under Recents, not under the existing actors project.
• Reading the Desktop project UUID through App Server project/read returns project 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:

• Codex Desktop: request an authorized local bridge for project catalog and thread activation #40535 documents the separate Desktop and App Server project catalogs, but its reproduction uses a separate App Server process.
• Codex Desktop: atomic project-aware create_thread with runtime roots and idempotency #36250 explains that generic thread/start does not persist Desktop's saved-project assignment.
• Codex Desktop: add project management for registering projects and moving threads between projects #25498 requests project registration and moving tasks between projects.
• [macOS] Project worktree task initially has projectId=null and recovers only after Desktop restart #39764 and [Windows][Desktop] task list returns projectId=null for a valid directly bound local-project task #37021 report projectId: null when 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/read using the Desktop saved-project UUID: project not found

I can provide sanitized JSON-RPC request/response logs if useful.