Codex App create_thread worktree rows fail with 'Worktree init failed' and no recoverable error

What version of the Codex App are you using?

Codex App 26.609.41114 build 3888

Bundled CLI: codex-cli 0.140.0-alpha.2

Global CLI on the same machine: codex-cli 0.135.0

What platform is your computer?

macOS 26.3 build 25D125

What issue are you seeing?

A parent/orchestrator Codex thread attempted to create two worktree-backed project threads through the create_thread tool. The tool returned only pending worktree IDs, and the Codex sidebar then showed both child rows as:

Worktree init failed

The parent thread had no returned threadId, no follow-up API to inspect/cancel/resolve the pending worktree, and no useful error message explaining why init failed.

Observed pending IDs from the tool results:

{"pendingWorktreeId":"local:8afc1d65-0aeb-450b-9ec7-6f76b68bba58"}
{"pendingWorktreeId":"local:85344054-5e7f-49c2-a751-65872c865ceb"}

What steps can reproduce the bug?

From a visible Codex manager/orchestrator thread in a local Git project, call create_thread twice with a project worktree target similar to:

{
  "target": {
    "type": "project",
    "projectId": "/path/to/local/git/project",
    "environment": {
      "type": "worktree",
      "startingState": { "type": "working-tree" }
    }
  },
  "thinking": "xhigh",
  "prompt": "You are a managed direct-report thread..."
}

Actual result:

1. create_thread returns only pendingWorktreeId.
2. The sidebar creates rows for the pending workers.
3. Within about one minute, both rows display Worktree init failed.
4. The parent/orchestrator cannot inspect the failed pending worktree, cannot retrieve a failure reason, cannot send a correction, and cannot cancel or clean it up through the tool surface.

Diagnostic evidence from the local machine

After the failure:

• No matching new directories existed under ~/.codex/worktrees for the two pending IDs.
• No normal threads rows were created for the failed pending worktrees in ~/.codex/sqlite/state_5.sqlite.
• Searching the live ~/.codex/sqlite/logs_2.sqlite around the failure time for the pending IDs, worktree, and failed did not expose an actionable worktree-init error.
• git worktree add --detach HEAD /tmp/... from the same repo succeeded and was removed cleanly, so the base Git repository and filesystem permissions appear healthy.
• The app-server was running from the bundled CLI and the Codex app was otherwise responsive.

Expected behavior

At minimum, failed pending worktree initialization should surface an actionable error to the parent/orchestrator and the UI.

One or more of these would make the workflow recoverable:

1. create_thread returns a stable reserved threadId plus pendingWorktreeId, even before init completes.
2. A pending-worktree API exists, for example read_pending_worktree(pendingWorktreeId), cancel_pending_worktree(pendingWorktreeId), and resolve_pending_worktree(pendingWorktreeId).
3. The failed sidebar row can expose the exact failing command/stderr or a structured failure reason.
4. list_threads or another tool can search pending/failed worktree rows by pendingWorktreeId.
5. Failed pending worktree rows are cleanup-able through the tool surface.

Why this matters

This blocks visible manager/worker workflows in Codex Desktop. An orchestrator can request independent worker threads, but if Codex worktree setup fails, the parent is left with only a non-addressable pendingWorktreeId and a sidebar row saying Worktree init failed.

The user-facing failure is especially rough because the app visibly creates failed worker rows but the agent has no programmatic recovery path or error details.

Related issues

• #26861 covers the broader API gap where create_thread returns pendingWorktreeId without an addressable threadId.
• #27584 covers another tool-created worktree limitation around local environment setup.

This issue is specifically about the pending worktree reaching a visible Worktree init failed state with no actionable error, no persisted thread, and no tool-level recovery path.