Remote project new-thread composer no longer exposes New worktree

What happened?

In Codex Desktop, when I start a new chat for a local project, the composer shows the run-location dropdown with options like:

• Work locally
• New worktree
• Cloud

When I start a new chat for a remote project, that dropdown is no longer present. The composer only shows a branch dropdown. I do not see any way to create a new remote-project thread in a fresh worktree from the new-thread composer.

This is a serious regression for parallel-agent workflows. Without a visible New worktree / New remote worktree option for remote projects, multiple remote threads appear to target the same remote checkout/path, so agents working in parallel can overlap in the same repo.

Why this matters

Worktrees are the isolation mechanism that lets multiple agents work on the same repo concurrently. For remote projects, this is even more important because the user may be connecting to a single SSH host/project path and expect Codex to create separate worktrees per thread.

Right now the apparent choices are:

1. Start another remote-project thread against the same checkout, risking collisions, or
2. Manually create a remote worktree and add/open that path as a separate remote project.

That removes the main benefit of thread-level worktree creation.

Expected behavior

The remote-project new-thread composer should expose a way to start in a new worktree, equivalent to local projects. For example:

• Work in current remote checkout
• New remote worktree
• Cloud, if supported/applicable

Starting a remote-project thread with New remote worktree should create a separate worktree on the remote host and bind the new thread to that path.

Actual behavior

For remote projects, the run-location dropdown is hidden and only the branch dropdown remains. I cannot find a visible path to create a remote worktree during thread creation.

Local source-code observations

I looked through the installed Codex app bundle and found code paths that suggest worktree creation is still explicit, not automatic:

• threads-create-aB-XmjWR.js only creates a pending worktree when target.environment.type === "worktree"; otherwise it calls start-conversation directly with hostId, cwd, and workspaceRoots.
• pending-worktree-conversation-CgQZkMum.js starts the conversation after the pending worktree is ready, using the created worktree path as cwd/workspaceRoots.
• local-remote-dropdown-DnABqdXS.js still contains labels/logic for New remote worktree, but the remote-project new-thread surface appears not to mount/show that dropdown.
• composer-DhWyK5QW.js appears to pass hideRunLocationDropdown in the remote-project new-thread flow, leaving only the branch selector visible.

So it does not look like “every remote thread is automatically a worktree”; it looks like direct remote threads are still possible and the UI no longer exposes the worktree path at creation time.

Related issues

• Related/open: #27736
• Related/closed: #27013

Environment

• Codex Desktop app
• Remote project connected over SSH/remote host
• Observed in the new-chat/new-thread composer for a remote project