›_ Codex Issues
Codex Issues / #32927

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

Open 💬 4 comments Opened Jul 14, 2026 by andyhcwang
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32723

Powered by Codex Action

andyhcwang · 1 month ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Restore worktree & environment selection for Scheduled Tasks #32723 _Powered by Codex Action_

Not duplication.

andyhcwang · 1 month ago

Still reproduces after updating the app.

Current version

  • Codex/ChatGPT desktop: 26.707.72221
  • Build: 5307
  • Platform: macOS
  • Rechecked: July 15, 2026

Current UI

The new-task composer footer shows only:

  • add/attachment button
  • Full access permission control
  • model selector
  • microphone
  • send button

There is still no visible Local, Work locally, Worktree, or New worktree environment control.

Fresh reproduction

Two newly created DialecticPy tasks today both started in the original checkout:

  • cwd: /Users/cedricwang/VSCode/DialecticPy
  • checkout branch: main
  • neither task started under ~/.codex/worktrees/...

So the regression is still present in build 5307: without an environment selector, new tasks enter the shared Local checkout and can interfere with other concurrent Codex/Claude sessions. The managed-worktree infrastructure still exists; the missing piece is the new-task selection UI.

shinny-xionghongwei · 1 month ago

Confirming a closely related Windows regression in the unified ChatGPT/Codex desktop app.

Environment:

  • App package: OpenAI.Codex 26.707.9981.0 (x64)
  • OS: Windows 11, version 10.0.26200, build 26200
  • Project picker includes both a valid local Git repository and a Debian remote Git project

Observed behavior:

The new-task composer shows the project picker, add button, access/permission control, and model selector, but there is no Local, Work locally, or New worktree environment selector.

The project picker only switches between local and remote projects; it does not expose a worktree option. In the captured reproduction, the Debian remote project was selected.

The underlying worktree capability still appears to be available: a new worktree task for the local Git project could be created successfully through the app's built-in create_thread action. This suggests the issue is with UI exposure or feature gating rather than removal of the backend capability.