I found code in my repo I'd never seen. All 82 tests passed. I quarantined it for three days anyway.

During a routine morning triage of my open-source project, git status showed a modified file I had no memory of touching: extension/background.js , last modified 24 hours earlier, sitting next to a fresh background.js.bak someone had thoughtfully left behind. Nobody broke in. I run several AI coding sessions in parallel against the same machine, and one of them - working on a completely different task, automating a GoHighLevel workflow - had hit a limitation in my browser automation tool, fixed the tool itself, verified the fix, and then moved on with its actual job. It never committed. It never told anyone. It just left better code in my working tree and walked away. The diff was good. That was the problem. The change itself was a real feature. My query_all tool (it queries DOM elements across a page) stopped at the main frame: if the elements you wanted lived inside a cross-origin iframe, you got back a clean, confident, empty array. The uncommitted diff added an execAcrossFrames() helper that runs the query in every frame and merges the results, plus x /y /frame fields on each returned element. I verified it the way you'd verify anything: syntax check passed, and the full test suite - all 82 tests - ran green with the change in place. So: useful feature, my own repository, every signal green. Everything about the situation said commit it. I didn't. I wrote it up in my project log, left the file untouched, and set an explicit deadline: if it's still sitting there uncommitted in three days, evaluate it properly - upstream it or revert it and file an issue. Not "leave it and see," which is how working trees rot. A quarantine with no release date is just a junk drawer. Why quarantine green code? Two reasons, and neither is paranoia. First: authorship isn't verification. The session that wrote this code had context I didn't have. Maybe it was mid-iteration and the diff was half of a plan. Maybe the .bak file meant it intended to roll back. Committing someone's work-in-progress freezes it at a moment they didn't choose. The fact that the "someone" was technically me, in another window, changes nothing - I had none of that session's context. A diff you don't remember writing is a stranger's diff. The stranger being you is a detail. Second: green tests measure what you thought to test. My suite passed because nothing in it asserted anything about cross-origin frames - the tests were blind to the change, not endorsing it. "All tests pass" and "no test looked" produce the same green checkmark. Day 3: review it like a stranger's pull request The deadline arrived, the diff hadn't moved, so I did what I'd do with an external PR from an unknown contributor: re-ran everything (still 82/82), then read the semantics line by line instead of trusting the vibe. And there it was - the one bug no test could have caught, exactly where I'd felt vague unease on day 0. The code's comments claimed the new x /y coordinates were page-level. They aren't. Each element's coordinates are relative to its own frame's viewport. For main-frame elements that's the same thing; for an element inside a cross-origin iframe, it's iframe-relative - so a caller who took those numbers and clicked at that position on the page would click the wrong spot. Silently. Only on the exact pages this feature was built for. The code was right; its claim about itself was wrong. That's a documentation bug today and a caller's logic bug tomorrow. Fix: correct the comment to state the real coordinate space, and document that callers must offset using the frame field the diff had already (presciently) added. Then it graduated: comment fixed, changelog written, committed as a proper feature with attribution to the context it came from, the .bak file byte-compared against git history and deleted, and released in v2.16.0. The quarantine didn't slow the feature down. It shipped three days later than "immediately" - and shipped correct. What I keep from this - A diff you don't remember is untrusted input, even in your own tree, even green. Multi-agent workflows make this a weekly event, not a freak accident. - Never commit a parallel session's WIP on discovery. You're freezing someone else's half-thought. - Quarantine needs a deadline. "I'll look at it later" is how repos accumulate mystery files. Name the day and the two exits: upstream or revert-and-file. - On review day, read the claims, not just the code. The only real bug was in a comment - a semantic promise no test asserted and no linter checks. The uncomfortable part: five years ago, "unexplained code appeared in my working tree overnight" meant your laptop was compromised. Now it means Tuesday. The tooling caught up with writing code faster than our habits caught up with receiving it. How do you handle this? If you run parallel AI sessions - or just share a repo with your past self - what's your protocol when you find a diff you don't remember writing? Commit-if-green, revert-on-sight, or something in between? Top comments (0)