[Bug][macOS 26.707] Worktree mode selector missing from new-task composer; task starts in local checkout

Codex app version

26.707.71524 (build 5263)

Platform

macOS, unified ChatGPT desktop app (bundle ID com.openai.codex)

What happened?

When creating a new Codex task for a local Git repository, the composer no longer shows the environment selector previously labeled Local, Work locally, or New worktree.

Submitting the prompt starts the task directly in the repository's original checkout instead of a Codex-managed worktree. In my reproduction:

• pwd: /Users/cedricwang/VSCode/DialecticPy
• git rev-parse --show-toplevel: /Users/cedricwang/VSCode/DialecticPy
• git branch --show-current: main

The composer footer only shows the add button, access/permission control, and model selector. There is no visible worktree environment control.

The installed application bundle still contains strings/components for Local, Work locally, New worktree, /worktree, and Continue in new worktree, so this appears to be a UI or feature-gating regression rather than removal of the underlying capability.

Steps to reproduce

1. Open a local Git repository as a project in the macOS ChatGPT/Codex desktop app.
2. Create a new task.
3. Inspect the controls beneath the composer.
4. Observe that no Local/Work locally/New worktree selector is present.
5. Submit a prompt.
6. Check the task's working directory and branch.

Expected behavior

A new task should expose an environment choice before submission, including New worktree, as described in the documentation. Choosing it should create and run the task in a Codex-managed worktree rather than the original checkout.

If the UI has intentionally changed, the replacement path should be visible and the documentation should be updated.

Additional context

The current official documentation still says to select Worktree under the composer:

https://learn.chatgpt.com/docs/environments/git-worktrees

An older report described essentially the same missing-worktree symptom and was closed after an app update fixed it, so this may be a regression:

https://github.com/openai/codex/issues/11181