`abcd implement step --restart` snapshots the lane worktree with `read-tree` and `add -A`, then runs `reset --hard` and `clean -fd`, all without `FilterOverrides`, so a clean or smudge filter the lane's `.gitattributes` and git config name runs as the operator. The rate-limit checkpoint calls the same `saveAside` with reset for an implementer.

abcd implement step --restart snapshots the lane worktree with read-tree and add -A, then runs reset --hard and clean -fd, all without FilterOverrides, so a clean or smudge filter the lane's .gitattributes and git config name runs as the operator. The rate-limit checkpoint calls the same saveAside with reset for an implementer.

Private security advisory GHSA-rq88-qv56-h4m7 (draft, severity high). Same class as GHSA-qv3j-fq4f-g5xr. Full text, evidence and reproduction: .abcd/.work.local/scratch/security-drain-2026-10-11/advisories/ in the main checkout's local tier. This record stays uncommitted until its fix lands; the fix commit adds it directly to resolved/.

Evidence (main 3d171421a): snapshot and saveAside (internal/core/implement/loop/restart.go) pass no filter override; saveAside is also reached from internal/core/implement/loop/ratelimit.go:157. No caller under internal/core/implement uses gitutil.FilterOverrides. Confirmed by reading the code at that commit; not re-run.

Tension to settle: commit 142a73056 documents that the pick's record commit and a sync's merge deliberately run the repository's content filters in the lane worktree, as Git LFS needs, because the implementer already runs the repository's own code there. Blanking filters on restart (the advisory's fix) contradicts that stance and would leave LFS pointer files after reset --hard; keeping them makes this advisory a documented residual rather than a defect.

Ruling 2026-10-11

The product thinker ruled option A+ with the LFS exception, recorded in a draft decision record, since withdrawn. The class is wider than the advisory: the pick's records commit and a sync's merge run content filters on purpose (commit 142a73056), and the landing's records commit runs every repository hook (hookedGit, internal/core/implement/loop/land.go), so a fix to restart alone would leave the planted program running at the next pick, sync or landing. The ruled fix closes all three routes, keeps a filter whose values are exactly git-lfs's standard commands, and moves the commit-msg outbound check in-process. Measured on a scratch --local git-lfs repository: with filters blanked and no exception, a sync of a main that changed an LFS file and an add of an edited LFS file both fail (exit 128); ordinary changes succeed; a planted pre-commit hook does not run with hooks off.

Assessed under abcd-fixes-what-it-adds (2026-10-11)

Would it exist without abcd? Yes. A program named in the checkout's shared git settings (a content filter, a hook, a transport helper) runs on the person's own plain git commands with no abcd involved; tested 2026-10-11 by planting a filter and a hook from inside a lane and running a plain git add and git commit in the main checkout, and both ran. So it is not abcd's vulnerability, and switching those settings off for abcd alone would change how the repository works (large-file storage, its own hooks, its login and ssh helpers) while removing nothing an attacker can do. What abcd can do without changing anything is notice: the run tripwire stops abcd's next git step when those settings change during a run, and names the change. The earlier draft decision to blank filters and hooks in lane steps was withdrawn the same day.