I hit a clean example of a Codex worktree starting with an unusable runtime.
A clean snapshot ran 163 tests. 160 passed. Three failed before reaching their mocks or business assertions because test setup constructed LLMClient() and OPENAI_BASE_URL was absent. The new worktree had no .env.
The immediate rerun supplied three non-sensitive dummy LLM variables. This preserved secret isolation and verified the actual code change.
The official Codex Worktrees documentation now describes .worktreeinclude for explicitly selected ignored files. That mechanism helps local Codex-managed worktrees. Production .env files can contain broad credentials, so test workloads need a safer path:
tracked .env.test values containing no secrets
dummy variables supplied by the test runner
lazy or injected client construction so mocks take effect first
a worktree preflight that reports required ignored files before the first agent turn
The remaining setup gap is also recorded in openai/codex issue 27584. Tool-created worktrees can skip the selected local-environment setup and start without .env.local, dependency state, and other artifacts.
My product suggestion: Codex should check the worktree runtime before starting the agent and surface a precise missing-environment report. This would save user time and agent tokens while preserving explicit control over secret copying.
How are other teams handling test-safe environment defaults across parallel Codex worktrees?
You are welcome to discuss Codex issues here. However, the official place to report and track Codex bugs is the OpenAI Codex GitHub issue tracker.
I asked ChatGPT to search for the closest related issue, and it identified:
If that issue describes the same problem you are experiencing, consider adding a reaction to the GitHub issue itself, rather than only reacting to this forum topic. GitHub reactions can help the maintainers gauge how many users are affected.
If it does not match your problem closely enough, search the existing Codex issues for a better match. If you cannot find one, consider opening a new issue and include as much relevant information as possible, such as your Codex version, operating system, environment, reproduction steps, expected behavior, actual behavior, and any relevant logs or error messages.
reaction to the GitHub issue itself, rather than only reacting to this forum topic. GitHub reactions can help the maintainers gauge how many users are affected.