Cron worktree automations cannot discover Codex session/worktree creation capabilities
What variant of Codex are you using?
Codex desktop app
What happened?
A recurring Codex automation configured as a cron job in a worktree environment cannot discover or use any real Codex session/thread creation capability, even though the same desktop app runtime in an interactive thread can create project-scoped Codex sessions in new worktrees.
This blocks automation workflows where a scheduled orchestrator is supposed to triage work and hand each selected task to a separate Codex session/worktree.
Reproduction
- In an interactive Codex desktop thread, discover thread/session tooling.
- Create a new projectless Codex thread: this succeeds and returns a
threadId. - Create a new Codex thread in a saved local project: this succeeds and returns a
threadId. - Create a new Codex thread in the same saved project using a new worktree environment: this succeeds asynchronously and returns a worktree/session pending identifier.
- Configure a recurring automation as:
- kind: cron
- execution environment: worktree
- cwd: saved local project checkout
- local environment config: unset/null
- In the automation prompt, ask the run to discover the currently available Codex session/thread creation capability and create a project-scoped Codex session in a new worktree.
- Let the automation run.
Actual result
The cron worktree automation reports that no real Codex session/thread creation capability is exposed. In the failing run, tool discovery did not expose capabilities equivalent to creating/forking/handing off to real Codex threads, a project registry, or isolated worktree-backed Codex session creation.
Only unrelated capabilities were visible, such as GitHub issue/PR operations, filesystem/browser tools, Vercel tools, and multi-agent tools. Because multi-agent subagents are not a substitute for real durable Codex sessions/worktrees, the automation correctly stopped as blocked.
No issues were mutated and no worker sessions were started.
Expected result
A cron worktree automation should either:
- expose the same Codex App session/worktree creation capability that an interactive desktop thread can use, or
- document that cron/background automation runs cannot create or hand off to new durable Codex sessions/worktrees.
If the latter is intentional, it would help to have an explicit supported pattern for scheduled orchestration that creates isolated project worktree sessions.
Why this matters
The target workflow is an issue triage orchestrator:
- inspect GitHub issues labeled ready for agent work
- skip issues already running, blocked, or awaiting human review
- start one isolated Codex session/worktree per selected issue
- have each worker open a draft PR and continue its own follow-up loop
This works conceptually from an interactive desktop thread because session/worktree creation is available there. It fails specifically when moved into a cron worktree automation because the required Codex session creation surface is absent from that runtime.
Additional context
This is related to cross-thread orchestration needs such as #14923, but this issue is narrower: the interactive app thread can create sessions/worktrees, while a cron worktree automation cannot discover the same capability at runtime.
The automation was also tested with the local environment setup config unset/null to avoid setup-config rejection issues; the failure is about missing runtime capability, not local setup config.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗