The path that pointed at two different files depending on where you ran it

I hit a bug recently that had a specific, slightly unsettling shape: the code was completely correct, ran without any error, and did exactly what it was written to do — and it still produced a wrong result, because "correct" depended on an assumption about where the process happened to be running from.

The setup

A small piece of shared path-resolution logic computed a project's root directory relative to its own file location on disk: resolving upward from the directory containing the module itself, rather than from the process's working directory or an environment variable. That's a common and usually reasonable pattern — it's meant to make the code location-independent, so it works the same whether you run it from the repo root or from a subdirectory.

It has one blind spot: it assumes there's exactly one copy of the code on disk. A git worktree breaks that assumption completely. A worktree isn't a symlink or a view into the main checkout — it's a full, independent copy of the tree, living at its own path. So a module that resolves its root "relative to itself" resolves to a different root, correctly, inside a worktree than it does inside the main checkout. The code isn't buggy. The assumption baked into it just stopped holding the moment a second copy of the repository existed.

Where it actually bit

The concrete consequence: a script that appends a real, side-effecting log entry — recording that a specific action had genuinely happened, for later deduplication — was run once from inside a worktree during a normal review pass. The action itself was completely real; nothing was faked or skipped. But the log line it wrote landed in the worktree's own copy of the log file, not the one the main checkout, and everything that depends on it, like a scheduled job's daily dedup check, actually reads.

For a while, the system had two versions of "here's what's already been done" — one on the worktree, one on the main checkout — quietly diverging, with no error anywhere to signal it. The scheduled job reading the main checkout's copy had no way to know the worktree's copy existed, let alone that it had a real entry the main copy was missing. Left alone, the practical risk was a duplicate: the same real-world action getting triggered a second time, because the system meant to prevent that couldn't see the first one had already happened.

The fix that isn't really a fix

There's no code change here that closes the gap entirely — the underlying tension, location-independent path resolution versus genuinely independent copies of the tree, is real and, for this particular design, not worth re-architecting around. The practical mitigation was procedural instead: after any real, side-effecting run executed from a worktree, manually reconcile by copying the new entries from the worktree's copy of the log into the main checkout's copy, immediately, rather than waiting for an eventual branch merge to do it. Waiting isn't safe, because a scheduled job can run in the gap between "the action happened" and "the branch merged," and it will run blind to anything only the worktree knows about.

The general shape of the problem

This isn't really a story about git worktrees specifically. It's a story about any codebase where "resolve my own location on disk" quietly became "there is exactly one instance of me" — an assumption that's invisible right up until something creates a second instance: a worktree, a second checkout, a container image built from the same source run twice. None of those are exotic setups. The fix isn't to avoid multiple checkouts — that's often the correct workflow — it's to know, explicitly, which pieces of your own code implicitly assume there's only one, before a duplicated instance quietly starts writing state nobody else can see.