[macOS] Project worktree task initially has projectId=null and recovers only after Desktop restart

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

Unified ChatGPT/Codex Desktop 26.818.21641 (build 6849); bundled codex-cli 0.148.0-alpha.21.

What subscription do you have?

ChatGPT subscription (the exact tier is not displayed in the current unified desktop UI used for this report).

What platform is your computer?

macOS 26.6.2 (25G83), Apple silicon.

What issue are you seeing?

Creating a project-scoped worktree task through the Codex Desktop create_thread tool can successfully create both the task and its managed Git worktree, but the new task is initially reported with projectId: null.

The source project is a valid saved local Git project. Immediately before creation, project discovery returns the expected saved project UUID, local host, canonical repository path, and isGitRepository: true. The creation request explicitly passes that exact saved project UUID and environment: { type: "worktree" }.

Observed result after the pending worktree resolves:

threadId: <redacted>
hostId: local
projectId: null
cwd: ~/.codex/worktrees/<redacted>/<repo>
status: active

The physical worktree exists, is registered by Git, and belongs to the expected repository. Because project identity is missing, the child task is instructed to fail closed and makes zero changes.

After quitting and reopening the Desktop app, list_threads reports the same task and same worktree with the correct saved project UUID. No task recreation, worktree repair, Git operation, or metadata edit is performed. The task can then be continued normally.

This has reproduced twice on the same machine with two separately created project worktree tasks. In both cases, the initial runtime metadata had projectId: null; after an app restart, the existing task recovered the correct project association.

This appears to be a race or stale projection between successful task/worktree creation and the Desktop task-to-project association exposed through thread-management APIs. It is not a Git worktree initialization failure.

What steps can reproduce the bug?

1. Open a controller task inside a saved local Git project in Codex Desktop.
2. Call the project-listing API and record the returned saved project UUID, host, path, and isGitRepository: true.
3. Call create_thread with:

{
  "target": {
    "type": "project",
    "projectId": "<exact saved project UUID from step 2>",
    "environment": { "type": "worktree" }
  },
  "prompt": "Verify your projectId before reading or writing the repository."
}

1. If creation first returns a pending/client identity, wait until the canonical task ID and managed worktree appear.
2. Call list_threads and inspect the new task. It may report the correct host and managed worktree cwd but projectId: null.
3. The child also observes the null project identity and stops without modifying files.
4. Quit and reopen the Desktop app.
5. Call list_threads again. The same task now reports the correct saved project UUID and can be resumed.

The latest reproduction returned a pending client identity immediately, created the physical worktree within seconds, and still reported projectId: null after the child completed its 30-second fail-closed identity check. Waiting for ordinary task completion did not repair the association; restarting the app did.

What is the expected behavior?

• A project-scoped create_thread request must not start the child turn until the task's saved-project association is available and durable.
• A task created with an explicit valid saved project UUID must never be surfaced as projectId: null.
• If association is still being materialized, the API should return a structured IdentityPending/pending state rather than a runnable task with ambiguous identity.
• The association should become visible without requiring an application restart.
• Failed or delayed association must preserve the original task/worktree and expose a bounded retry or refresh mechanism, so controllers do not create duplicate tasks.

Additional information

The report is intentionally sanitized: repository name, absolute user path, saved project UUID, task IDs, prompts, and source contents are omitted. No repository files were modified during either failed identity handshake.

Potentially related reports:

• #10522 — worktree threads not associated with the project sidebar
• #24345 — worktree chat exists locally but loses project/sidebar association
• #23268 — worktree is created from the correct repository but grouped under the wrong project
• #28204 — orchestrator create_thread worktree creation lacks a recoverable identity/error path

The distinguishing evidence here is the API-level transition for the same task: projectId: null before Desktop restart, then the correct saved project UUID after restart, without recreating or repairing the task.