Claude Code links a real repo into a test sandbox, and the test deletes its .git

This is one person's account in a bug report on GitHub, not independently confirmed. It does include steps to reproduce the underlying trap.

What happened

The developer was working in a git worktree that was missing a sibling folder. To get a project self-test running, Claude, running an Opus model, created a symlink from the worktree to that folder in the main checkout. The self-test copies the folder into a temporary sandbox, deletes the copy's .git directory with rm -rf, and then writes changes into the copy.

How it went wrong

On macOS, cp -R copies a symlink as a link rather than following it. So the 'copy' in the sandbox still pointed at the real checkout, and every delete and write went straight through. The developer says the real repo's .git folder was deleted, several source files were changed and a whole source directory was removed. There was no remote and no backup, so they say the history is permanently gone.

No error appeared. They only noticed later, when git commands in other worktrees started failing because their git directory had vanished. They say the model never read what the script did before pointing it at the real checkout, and nothing in the tool flagged the symlink or the deletes that followed.

What they changed

They've since added a guard to their self-tests: refuse to run if the copied path contains a symlink, and before every rm, resolve where it really points and require it to be inside the temporary sandbox. The report is labelled as a data-loss bug, and we found no fix announced yet.

Our take

A sandbox is only a sandbox if nothing in it links back out. Before an agent runs a script that deletes things, it should read the script, and anything you can't rebuild needs a remote or a backup the agent can't reach.