git status in sandbox causes all files to be modified

[willeppy]

My agent ran git status in a quicksand sandbox and every file looked modified.

Repro

Make a git repo on the host, mount it, run git status in the guest.

# make git repo for testing
mkdir /tmp/r && cd /tmp/r && git init -q . && echo hi > a.txt
git add -A && git commit -qm init

# quicksand part
quicksand run ubuntu --network full -v /tmp/r:/workspace
# in the quicksand emulator: apt-get install -y git && cd /workspace && git status

Every file shows as modified, and back on the host .git/index is gone.

[tylerpayne]

Reproduction notes

Tested on September 9, 2026, with a macOS ARM64 host and Ubuntu guest, using the default read/write CIFS mount. The source checkout was ab0aa99394e1ef59c36f3791bafa637647bf05ee (quicksand-core 0.12.2.dev0, quicksand-smb 0.5.4.dev0), with quicksand-ubuntu 0.9.11 and quicksand-qemu 0.5.11. This checkout includes the SMB rename fixes released in quicksand-smb 0.5.3.

Reproduced: unchanged files appear modified

Created a disposable host Git repository with a committed a.txt, mounted it at /workspace, and installed Git in the guest. The host repository was clean before running the guest commands.

$ git -c safe.directory=/workspace -C /workspace status --porcelain=v1
 M a.txt
$ git -c safe.directory=/workspace -C /workspace diff --summary
 mode change 100644 => 100755 a.txt

The guest saw a.txt as executable (0755), while Git recorded it as non-executable (100644). In this reproduction, the false modification was a file-mode difference from CIFS's synthesized permissions, not a content change.

This command returned a clean status:

git -c safe.directory=/workspace -c core.filemode=false -C /workspace status --porcelain=v1

core.filemode=false is scoped to that invocation, so it does not modify the host repository's Git configuration. It ignores executable-bit differences; content changes are still reported.

Not reproduced: deletion of the host .git/index

Repeated guest git status calls left the host .git/index present and the host repository clean. This also held with core.filemode=false, exercising the otherwise-clean index-refresh path.

I additionally staged one version of a.txt, then changed its working-tree content again. Guest and host both reported MM a.txt, and the host's staged entries (git ls-files --stage) remained unchanged after guest status calls.

Regression coverage has been added in the working branch for clean and staged/unstaged repositories, both with the original Git behavior and with the command-scoped file-mode workaround. It is not yet merged.

Conclusion: the “files look modified” symptom reproduces, but host index deletion does not reproduce on this checkout. The recent SMB rename fixes may be relevant, but this does not establish that they fixed the deletion report; I have not compared against the older SMB version. No Windows reproduction was attempted.