Every worktree's test suite passed — but that didn't mean it had actually tested that worktree's code
This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).
I was developing a batch of new features across four git worktrees in parallel.
Each worktree was an independent branch owning a different slice of the work. The plan was to run tests inside each one, confirm they passed, and then merge them into main in order.
Symptom
While sorting out the merge order, I went back and looked at one of the helper scripts — a runner used to build reports.
Near the top of the file there was a line like this: an absolute path stored as a constant, then inserted at the front of sys.path with sys.path.insert(0, that_path).
That path pointed at the main checkout. Not the worktree. A fixed string that always pointed to the same single place, no matter where the script ran.
What I thought at first
At first it didn't register as a problem.
It looked like a familiar line — the kind people add to make the project root importable. Each worktree is its own directory at the git level, so I assumed that wherever the script ran, it would import its own local copy of the code inside that directory.
That assumption was wrong.
The actual cause
A git worktree only separates working directories from each other. To Python's import system, it's just another path on disk.
No matter which worktree you run this script from, the absolute path baked into the code always points at the main checkout. Same value, regardless of where you execute it.
Run pytest broadly — without naming specific files, across a whole directory or with a -k pattern — and this script gets swept into collection and imported too. The moment that happens, the top-level code in the module runs, including that sys.path.insert(0, ...) line.
From that point on, every import in the same process looks at whatever got pushed to the front of sys.path first — the main checkout's path, not the worktree's own modified code. Whatever's still sitting in main, old and unmodified.
So a worktree reporting "all tests passed" was no guarantee that the pass had actually exercised that worktree's changes. With bad luck, it could have passed against main's old code instead.
Why nobody caught it
sys.path pollution doesn't throw an error. The import just "succeeds." There's no visible signal at all.
Each of the four worktrees reported green, and nobody went back to double-check what code that green result had actually run against. Once the test runner lit up green, that was treated as the end of the story.
How it was addressed
The real fix is removing the hardcoded absolute path from the script, but the merge schedule was tight, so the immediate response was a workaround.
Instead of running tests via broad discovery, test invocations were switched to explicitly naming the files under test, so the problematic script never got swept into collection. The failure pattern itself was logged separately as a recognized class of incident, with the actual hardcoding left as a follow-up fix.
Generalizing
An import hook with a hardcoded absolute path silently defeats worktree or monorepo isolation. Even when directories are physically separated, one line of code can cut straight through that separation and always point to the same place.
"The tests passed" does not guarantee "the copy of code I wanted got executed." This is especially true in any setup running multiple checkouts of the same codebase at once — before trusting a green result, check which copy is actually being imported right now.
Broad test discovery sweeps up side effects along with the tests you meant to run. Running pytest across a whole directory or with a -k pattern also executes the top-level code of any module that happens to get collected along the way. Explicitly naming the files under test shrinks that exposure surface — not a complete fix, but enough to hold the line until the root cause gets removed.
When working across parallel agents or parallel branches, the illusion that "each workspace looks independent" is especially dangerous. Separate directories on disk aren't proof that the code inside them is actually isolated. A single hardcoded absolute path can cross that boundary without anyone noticing.
Top comments (0)