--- name: bash-cwd-drift-multi-worktree description: "Diagnose \"files keep reverting / phantom edits\" in multi-worktree sessions: the persistent bash shell's cwd silently reverted to another checkout, so probes and git commands ran against different files." --- # Multi-worktree bash cwd drift ## Symptom (all of these at once, in one session) - A file "keeps reverting" to an older version between edits (esp. test files). - `grep -n` line numbers disagree with the tool/test output (e.g. bats reports `line 637`, grep says the match is at 519). - `wc -l`/`md5sum` stable when sampled back-to-back, but state "flaps" across the session. - `git status` clean in one call, surprising in the next. - Probes against `src/` show code that doesn't exist in the branch you think you're on. ## Root cause The persistent bash shell resets to the session's ORIGINAL cwd when a call omits `cwd` (e.g. after a shell respawn at a turn boundary). With several git worktrees of the same repo checked out, consecutive calls silently alternate between two full copies of the tree — half the reads land in the old branch's files. Nothing is rewriting anything; two files are being inspected. ## Decision - In multi-worktree work, pass an **explicit `cwd` on EVERY bash call**. Never rely on persistence. - Use **absolute paths** for `read`/`edit`/`write` (already required) — file tools don't drift; only bash does. ## Check When state seems to flap: `pwd` in the same call as the probe. If two calls to the same relative path report different content, `git worktree list` and census each checkout separately — you have two files, not a gremlin. ## Repair pattern (if corruption got committed via the wrong tree) 1. `git log --oneline --all -- `; per candidate commit print `wc -l` + counts of a few marker strings to classify clean vs corrupted blobs. 2. Restore the good blob with `git show : > ` (no checkout — safe under worktree policies). 3. Re-apply the intended additions as surgical edits; verify with targeted tests before the full suite.