Codex Desktop automation creation no longer offers Worktree execution on macOS

Open 💬 0 comments Opened Jul 29, 2026 by jasoncym

What version of the Codex App are you using?

Codex Desktop 26.721.81911 (build 5973)

What platform is your computer?

macOS 26.5.2 (25F84), Apple Silicon (arm64)

What issue are you seeing?

The Scheduled/Automations creation flow for a repository-backed cron automation no longer provides a Local vs Worktree execution-environment choice. New cron automations are created as Local-only.

This appears to be a creation-flow regression rather than removal of Worktree automation support:

  • Existing cron automations saved with Worktree execution are still loaded.
  • Updating an existing cron automation can preserve Worktree execution.
  • Existing Worktree automations still create isolated worktrees at runtime.
  • Heartbeat automations are not affected; they correctly target an existing thread and should not show a Worktree choice.

The practical problem is that a user can no longer create a new repository-backed cron automation in Worktree mode from the Desktop UI, even though the saved-configuration and runtime layers still support it.

What steps can reproduce the bug?

  1. Open Scheduled in Codex Desktop.
  2. Create a new standalone scheduled/cron automation, not a heartbeat attached to an existing thread.
  3. Select a saved Git project.
  4. Inspect the create/edit form for an execution-environment control.
  5. Save the automation and inspect its execution environment.

Actual behavior

  • There is no usable Local vs Worktree selector in the creation flow.
  • The newly created cron automation is saved as Local.

Expected behavior

For a repository-backed cron automation, the creation flow should allow the user to choose:

  • Local, or
  • Worktree.

When Worktree is selected, a valid saved project should be required. Projectless cron automations should not be allowed to select Worktree. Heartbeat automations should continue to omit this control.

Editing an existing Worktree automation should also never silently convert it to Local.

Regression and impact

Earlier Codex Desktop automation UI versions exposed execution-environment selection. The current behavior makes it impossible to safely create new repository-writing scheduled jobs without using a separate supported update path after creation. This is especially risky because Local execution can target a human checkout, while Worktree execution is intended to isolate unattended repository changes.

No existing Worktree configurations were lost in this case, and their runtime behavior remains functional.

Current safe workaround

  • Preserve existing Worktree automations through the supported automation update interface.
  • Read the saved automation back after every update.
  • Verify the next real run creates an isolated worktree.
  • Do not manually edit the underlying automation state files.

Related issues

  • #15854 reports the inverse UI problem on Windows/WSL (Worktree shown but Local missing) and explicitly expects automation creation to allow Local or Worktree.
  • #11181 reports a broader Worktree UI disappearance, but not this scheduled-automation creation path.

View original on GitHub ↗