`host-setup/agent-safety/claude/install.py`'s `source_ref()` computes the dirty-checkout
signal with:
```python
status = git("status", "--porcelain", "--", *PAYLOAD_FILES)
ref["dirty"] = bool(status)
```
`git()` returns `None` both when `git status` finds no differences (empty stdout) and when the
command itself fails (non-zero exit, for example a corrupt or unreadable index, or a permissions
problem reading `.git`). `bool(None)` reads as `False` either way, so a failed status read is
silently reported as a clean checkout rather than as "unknown". A stamp built from that read
claims CURRENT when the installer actually has no idea whether the tree is dirty.
Found while adding `TestSourceRef` in #1641's fix: that test's baseline-skip guard only checks
`vcs` and `dirty`, so it cannot distinguish "really clean" from "status failed and read as
clean", which is this same ambiguity surfacing in test code rather than in the installer.
Predates #1641's own change: the `else` branch above is unchanged by that fix, which only added
an override branch ahead of it. The line-endings and "dubious ownership" cases in
`TestSourceRef`'s docstring were checked separately and are not this defect; `rev-parse HEAD`
fails first in the dubious-ownership case, which correctly yields `vcs: none` rather than a false
clean.
A fix distinguishes the git command failing from returning empty output, for example by having
`git()` signal failure separately from "no output", and reads it here as "unknown" rather than
"clean". A "dirty" verdict of unknown could reasonably read as either dirty (fail closed, matching
the module's own stated preference for reporting a dirty tree "rather than hidden") or as its own
STALE reason distinct from "dirty", which is a design choice for whoever fixes this rather than
this issue's to make.
`host-setup/agent-safety/claude/install.py`'s `source_ref()` computes the dirty-checkout
signal with:
```python
status = git("status", "--porcelain", "--", *PAYLOAD_FILES)
ref["dirty"] = bool(status)
```
`git()` returns `None` both when `git status` finds no differences (empty stdout) and when the
command itself fails (non-zero exit, for example a corrupt or unreadable index, or a permissions
problem reading `.git`). `bool(None)` reads as `False` either way, so a failed status read is
silently reported as a clean checkout rather than as "unknown". A stamp built from that read
claims CURRENT when the installer actually has no idea whether the tree is dirty.
Found while adding `TestSourceRef` in #1641's fix: that test's baseline-skip guard only checks
`vcs` and `dirty`, so it cannot distinguish "really clean" from "status failed and read as
clean", which is this same ambiguity surfacing in test code rather than in the installer.
Predates #1641's own change: the `else` branch above is unchanged by that fix, which only added
an override branch ahead of it. The line-endings and "dubious ownership" cases in
`TestSourceRef`'s docstring were checked separately and are not this defect; `rev-parse HEAD`
fails first in the dubious-ownership case, which correctly yields `vcs: none` rather than a false
clean.
A fix distinguishes the git command failing from returning empty output, for example by having
`git()` signal failure separately from "no output", and reads it here as "unknown" rather than
"clean". A "dirty" verdict of unknown could reasonably read as either dirty (fail closed, matching
the module's own stated preference for reporting a dirty tree "rather than hidden") or as its own
STALE reason distinct from "dirty", which is a design choice for whoever fixes this rather than
this issue's to make.