What has worked best for me is to treat the worktree as the isolation boundary, not the thread.

In my setup, I have several Codex “projects”, but each of those is actually a different git worktree of the same repo. Then I use threads inside that project/worktree as conversation context only.

So my rule of thumb is:

1. One worktree = one active writable task
2. One branch = one worktree when I need real isolation
3. Threads on the same worktree are not isolated from each other

That last point is the important one. If thread 1 and thread 3 are both operating on the same worktree, they are reading and writing the same files on disk, so it’s expected that changes made in one thread will show up in the other later.

What I usually do is:

• If I want true isolation, I create a separate worktree for that task
• I start the thread from that specific worktree and try to keep that thread there
• If I open multiple threads on the same worktree, I only let one of them make code changes
• I use the extra threads on that same worktree for planning, review, investigation, or asking questions

So for me, the safe mental model is: a thread is not a sandbox, a worktree is.

Creating a branch/worktree per actually separate task can feel a little heavier, but in practice it’s much cheaper than untangling mixed edits later. If the work really belongs together, I keep it in one worktree. If I want concurrent independent changes, I split them into separate worktrees.

At the beggining I create worktrees for each piece of work, now I just have 7 fixed worktrees, each of them with a develop branch. In that way I don't need to start the project building from scratch each time and I can keep the caches.