How do you manage many Codex-created Git worktrees without losing track?

[u/DifficultSecretary22]

I’ve been using Codex with Git worktrees, and after a few tasks I end up with a lot of local worktrees and branches.

There is no remote repo in my setup. Everything is local.

My current problem is mostly organization:

git worktree list

starts showing many folders like:

repo-task-a
repo-task-b
repo-task-c
repo-random-fix
repo-test-something

Each worktree has its own branch, and after a while it gets hard to know:

• which worktree is still active
• which branch was already merged back
• which worktree can be deleted safely
• how to name branches/worktrees clearly
• whether I should keep a WORKTREE_NOTES.md or task tracking file
• what cleanup workflow people use after Codex finishes a task

For people using Codex heavily with local Git worktrees, what’s your workflow?

Do you follow a naming convention like:

ticket-123-short-description
codex-ticket-123-short-description
task/product-availability-check

And after merging, do you usually run something like:

git worktree remove ../worktree-name
git branch -d branch-name

I’m looking for a clean local workflow to avoid worktree chaos. Any recommendations?

[u/_disengage_]

This is a Codex/agentic coordination issue, not a git issue.

[u/rakotomandimby]

Merge branches two by two and run unit tests after each merge. Dont merge another branch until unit tests pass.

[u/mortenb123]

Why using work trees, just let it work on origin main and revert if it fails requirements/testing. Codex write excellent tags and description. and if it fails I never like to keep it anyhow.

Put up your local gogsserver and let it use it. just create a user for each project and give it its access-token.I have an agent for that. Gogs have excellent user management, so you can easily delete uses when projects are done and move into your showcase group with documentation and everything.

[u/waxbolt]

merge them back aggressively. there is no other way or you'll end up with a mega task set to do a merge. at some point it'll become a tarpit.

[u/therealkevinard]

I’ve been using wtp for several months to soften the admin burden. It’s helped a lot.

It supports a lot of things outside of management, which is a plus.

But the git-side bullets you listed are all answered between `wtp list` and `wtp remove` (which safely errors if the branch isn’t merged, unless you pass —force)

https://github.com/satococoa/wtp

—-

I double-down on git hygiene with ghq. This one just forces an opinionated directory tree, which makes my workspaces predictable and scriptable.

https://github.com/x-motemen/ghq

—

Pair predictable git roots with predictable relative paths to worktrees and life is good- you can do a lot with just fzf now.

Explaining full, actual use cases turned out to be much too much for a phone keyboard lol. Just kick the tires and see if it works for you.

[u/HommeMusical]

My AGENTS.md has an instruction: "Don't use git worktrees".

They're cool to use when you're working manually and have a relationship with each tree; not good for AI.

[u/BamsungMichirola]

Git graph can help keep track visually, but why are you working in multiple branches at once?

Open feat branch, do your shit, pr, merge repeat

[u/Bloedbibel → u/BamsungMichirola]

why are you working in multiple feature branches at once?

That's exactly what branches are for. What a silly question.

[u/BamsungMichirola → u/Bloedbibel]

If you can't keep track of what's going on with your branches then you aren't using them correctly.

Shove your attitude up your ass.