# Why did git reset --hard run in my main checkout instead of the worktree?

Problem 62. Published Nov 13. Last checked Nov 13. Tags: git, AI agents, code.
Page: https://bluhook.com/log/git-reset-ran-in-shared-checkout

## What happened

Quinn (systems) hit it and fixed it. An engineering AI agent checked it.

Our systems AI agent wanted to test whether two pull requests would merge cleanly. The plan was to do it in a throwaway copy of the code (a git worktree), so the team's shared working copy would stay untouched.

The command chained the steps: fetch the code, step into the throwaway copy, then reset and merge. The fetch failed on a typo, so the step into the copy never ran. The reset and merge steps were joined with a plain semicolon, which runs the next step even after a failure. They ran in the shared copy instead.

The hard reset wiped one unsaved file edit there. Nothing was pushed.

**Why it happened**

The step into the copy depended on the fetch with &&. When the fetch failed, the cd was skipped, and the shell stayed in the shared folder. The steps after it didn't depend on the cd at all.

"Stop on first error" (set -e) would not have saved it. Bash ignores a failure inside an && or || chain under set -e, so the script keeps going.

**What we tried first**

We put the shared copy back on main with git reset --keep and checked that no local commits were left. Then we listed every file that changed in that minute. Only one tracked file was hit. The rest were files our agents write while they run, which a reset leaves alone.

We searched every agent transcript since the start of the month, and git's lost objects, for the wiped edit. It could not be recovered, so its owner redid it.

## What we did

1. Step into the copy on its own line, and stop if that fails: cd <copy> || exit 1.
2. Name the copy on every git command: git -C <copy> reset, git -C <copy> merge. A skipped cd then can't send a command to the wrong folder.
3. One git write per command, so one failure can't fall through to the next write.

## How we know it worked

A second AI agent, from engineering, read the shared copy back: on main, 0 local commits, nothing lost beyond the one edit. The same merge test then ran the safe way in a throwaway copy. Both pull requests merged cleanly, in either order.

## What you can take from it

If a command has to run in a certain folder, don't trust an earlier cd to still be in force. Name the folder in the command itself. And set -e won't catch a failure inside an && chain.