Codex app: support selecting existing worktrees.

Still seeing this on Codex Desktop.

Current new-thread UI only exposes:

• Work locally
• New worktree
• Cloud

There does not appear to be a first-class way to choose an already-existing Codex-managed worktree as the execution target for a fresh zero-context thread.

The workflow this blocks is: continue from the same filesystem/git/index state after a long or polluted conversation, but start with an empty transcript/context window. Forking is not equivalent because it preserves conversation history, and creating a new worktree is not equivalent because it loses the exact existing checkout state.

Expected UX could be something like "New thread here", "Use existing worktree", or "Clear context for this worktree" from an existing worktree-backed thread.

+1 - I like to switch between coding agents apps often and this would help a ton.

Adding another concrete workflow that this would unblock.

In a spec/PR-review workflow, I sometimes need a fresh zero-context Codex thread attached to an already-existing local worktree because that worktree has the exact PR branch, local indexes, build-server files, and git state I want to preserve.

Current limitations I hit:

• fork_thread with same-directory can attach to the existing worktree, but it inherits completed conversation history, so it is not a clean zero-context review thread.
• create_thread can create a new Codex-managed worktree from a branch, but it cannot target an arbitrary existing worktree path that is not listed as a saved project.
• Creating yet another worktree is not equivalent when the goal is to continue from a specific existing checkout state.

Desired UX/API:

• New thread from existing worktree path, e.g. “New thread here” / “Use existing worktree”.
• The new thread should start with empty conversation context while keeping the same cwd/git worktree.
• Ideally this should work for Codex-managed worktrees and user-created git worktrees.

This is separate from worktree creation bugs like #30954 and UI refresh bugs like #30955. This request is specifically for selecting an existing worktree as the execution target for a fresh thread.

I’d like to add a UI and safety dimension to this request.

In the new-task composer, Project | Local | main looks like three pieces of selected workspace state. However:

• Local selects an existing checkout.
• Worktree creates a new task-managed checkout rather than selecting one.
• main is only the starting point; the managed worktree begins in detached-HEAD state.

Suggested intent-based choices:

• Use local checkout
• Create new isolated worktree
• Use existing/reusable worktree
• Based on: main

For an existing task-managed worktree, useful actions would be:

• Resume owning task
• New task here / Make reusable
• Fork into new isolated worktree

The picker should show whether each worktree is managed, permanent, or user-created, along with its dirty state and whether another task is active.

To avoid concurrent-write problems such as #38541, Codex should block direct attachment when another task is actively using the worktree, or require a safe handoff/locking flow.

This would support starting with fresh conversation context while preserving the exact checkout state, without silently creating another worktree. The official worktree documentation already distinguishes task-dedicated managed worktrees from reusable permanent worktrees and explains that managed worktrees start detached.