Two agent sessions, one working tree: the checkout that ate my work

I had several coding-agent sessions working in the same repository inside a Google Drive folder. One session switched branches. In another session, work appeared to disappear.

Files were replaced with the other branch’s contents. Uncommitted edits and work committed on a different branch could look as though they had vanished.

If you run several coding-agent or editor sessions in parallel, this is the boundary that matters: separate sessions do not mean separate working trees. We had several sessions, but they were all looking at the same directory.

Google Drive added another problem. Sometimes the Read tool and bash or git disagreed about what files were there.

What I checked first, and what looked wrong

Two observations sent me in the wrong direction. Work appeared to have been rolled back. And a sub-agent reported that directories such as src/data did not exist — which was simply untrue, the shell could see them.

Those were two different versions of “the files are gone.”

The first came from looking at a working tree after another session had changed its branch. The second came from tools seeing different file states under Drive’s streaming sync.

Neither observation was enough to establish that committed work had been lost.

That distinction mattered. A missing directory in one tool’s view looked like a repository problem. Files containing an older or different implementation looked like lost work. But the visible files were only one part of the state we needed to inspect.

The useful checks were against Git’s history and objects:

git reflog
git cat-file -t <sha>

Those checks gave us a way to investigate the committed work independently of what the current working directory happened to show.

Root cause

The checked-out branch belongs to the working tree, not to the session.

Our sessions shared one working directory. When one session ran:

git checkout <other-branch>

it changed the branch and HEAD for that shared working tree. The files in the directory were replaced with the selected branch’s contents.

The other session did not retain a private copy of its previous branch. It was still operating on the same directory, whose contents had just changed underneath it.

That is the mechanism behind the apparent disappearance. Work committed on one branch can stop being visible in the files when the shared directory switches to another branch. Looking at those files alone makes “I am now seeing another branch” resemble “my work was removed.”

There was no session boundary around the checkout. Every session using that directory was exposed to it.

Then Drive complicated the evidence.

The repository, including .git, was inside the synced folder. Streaming sync introduced lag and cache inconsistencies. The Read tool could see a different file state from bash or git. A sub-agent could therefore report a directory as absent even when that report did not agree with the other tools.

These problems overlapped, but they were not the same mechanism. Shared checkout state changed which branch’s files occupied the directory. Drive made observations of that directory inconsistent.

The reassuring part: the committed objects survived

The working tree looked wrong. The committed Git objects were still there.

Using git reflog and git cat-file -t <sha>, we were able to recover everything in this incident.

That deserves its own section because “the files disappeared” is an alarming symptom, and the distinction is easy to miss while investigating it. What is visible in the working tree does not, by itself, tell us whether the committed objects still exist.

The qualification is committed. The recovery fact recorded here concerns Git objects. It is not evidence that an uncommitted edit has the same protection.

That became part of the fix: commit at work boundaries, and push at important points. Once the work is on origin, its recovery no longer depends on the state of the Drive folder.

The fix

I moved my work into a separate Git worktree outside Google Drive. We recovered the work and completed the implementation there.

Run from the original repository, the setup was:

git worktree add "<local-directory-outside-drive>" "<branch>"

The placeholders stand for a local directory outside the synced folder and the branch assigned to that worktree.

That gave the session an independent working tree and HEAD. Another session switching branches in the original directory could no longer take over this worktree’s checkout.

The practical setup also included sharing the existing dependencies and copying the environment file:

original_repo="<original-repository-directory>"
worktree_dir="<local-directory-outside-drive>"

ln -s "$original_repo/node_modules" "$worktree_dir/node_modules"
cp "$original_repo/.env" "$worktree_dir/.env"

The node_modules symlink avoided reinstalling dependencies. The .env file was copied into the new tree.

Development servers also needed separate ports. The arrangement in the notes was port 3000 for the Drive-side tree and 3001 for the external worktree.

Finally, we committed at work boundaries and used git push at important points. The separate worktree addressed the shared checkout problem. Committing and pushing provided the recovery protection.

What I would check first next time

I would start with the directory shared by the sessions.

• Are multiple sessions using the same working tree?
• Did another session switch its branch?
• Is the repository, including .git, inside a cloud-synced folder?
• Do the Read tool and shell agree about the files?
• What do git reflog and git cat-file -t <sha> show?

Before treating missing files as lost work, I would check the committed objects. Before starting another parallel session, I would give it its own worktree outside the synced folder.