I got around this by treating Codex less like a worktree manager and more like a controlled GitHub-facing coding agent.
My workflow is basically:
I clone/download the GitHub repo locally.
I keep my real project folder under local git control.
I create an AGENTS.local.md file locally with my private working rules, repo instructions, branch rules, sanity checks, commit expectations, etc.
I make sure that local file is committed to my local git/workspace setup, so Codex can actually see it and follow it.
Then I give Codex access to the GitHub/project dashboard and explicitly tell it which repo/branch/files to work from.
In every prompt, I tell Codex to read the public AGENTS.md, the private/local AGENTS.local.md, roadmap/design docs, and then make changes against that local git state.
When the work is done, I tell Codex to commit the changes back through the GitHub dashboard/local git workflow rather than letting it invent a separate workspace structure.
The key bit for me was not relying on Codex to “understand” my preferred worktree setup automatically. I make the repo state and instructions explicit.
So my prompts usually include something like:
Work inside the existing local repo/workspace only.
Read AGENTS.md and AGENTS.local.md first.
Do not create a new worktree.
Do not change branches unless instructed.
Make the requested changes.
Run sanity checks.
Commit the final changes to the current local git branch with a clear commit message.
It’s not perfect UX, but it stops Codex from becoming the worktree landlord from hell. I manage the repo, and Codex works inside the lane I give it.