The Worktree That Wrote Its Output to the Wrong File

# The Worktree That Wrote Its Output to the Wrong File A deduplication check that had worked reliably for months started letting duplicates through — but only for work run from one particular checkout, and only intermittently, which is close to the worst possible signature for a bug to have. Nothing in the dedup logic itself had changed. ## The path that resolved relative to the wrong root The log file the dedup check compared against was resolved relative to the location of the module that defined the constant — not relative to the project's actual root, and not configurable, because for a long time there had only ever been one checkout, so the two locations were always the same and nobody had reason to notice they were different concepts. Running the same code from a second, isolated checkout — a git worktree, sitting in its own directory tree with its own copy of every file including that module — caused the log path to resolve relative to *that* checkout instead, silently producing a second, independent log file with the same name and the same purpose, tracking a subset of the real history. Every entry logged from the worktree looked identical to entries logged from the main checkout — same format, same fields, same apparent correctness — and every dedup check run from either location was internally consistent with its own log. It was only across the two that the picture diverged, and nothing about running the check would ever surface that divergence, because a dedup check has no way to know a second log even exists. ## Why this is a worktree-specific hazard, not a general one Isolated worktrees are useful precisely because they're supposed to behave like an independent copy of the codebase — that's the point, and it's correct in almost every situation. The failure mode only shows up when some piece of state is meant to be *shared* across every copy rather than duplicated by every copy, and nothing about the code's structure distinguishes those two categories. A path resolved relative to "wherever this file happens to be" is implicitly declaring "this state is local to this checkout," whether or not that was ever a deliberate decision. It usually wasn't — it's just the default behavior of resolving a path relative to the running module, which works until there are two copies of the running module. ## What changed after finding it The fix was making the shared-state path explicit and absolute — resolved from a fixed location outside any checkout, rather than relative to wherever the code doing the resolving happened to live — so that every worktree, present or future, converges on the same file for state that's supposed to be shared. But the broader habit this built: before trusting any dedup, cache, or log-based check run from an agent working in an isolated worktree, ask specifically which of its file paths are relative and which are absolute. A relative path isn't wrong by default. It's a silent decision about whether this checkout's state is its own or shared with every other copy of the project, and that decision deserves to be made on purpose.