Post-hoc sweep

The safety net: after a run finishes, walk the diff, and revert anything that touched a protected path without permission.

The gate checks each write as it happens, but it can only check what it sees. A file created in a way the pre-write hook didn’t catch — a new .env appearing mid-session, say — would slip past. The post-hoc sweep is the cleanup pass that runs after the agent finishes, compares the result against the protected paths, and undoes any violation.

Snapshot, then delta

The sweep works by photographing the worktree before and after the run. The shim takes a snapshot before launching the agent, and another after it exits; the difference is the set of files the agent actually changed.

  before run:  snapshot worktree  →  { path : content-fingerprint }
       │
       ▼  (agent runs)
  after run:   snapshot worktree  →  { path : content-fingerprint }
       │
       ▼
  delta = paths whose fingerprint changed, or are new
       │
       ▼
  for each changed path matching a protected glob with no token:
        revert it + record the violation

Why a fingerprint, not a list of names

The snapshot stores a content fingerprint per file (a SHA-256 of the contents), not just the set of filenames. This fixes a real bug: if a file was already modified before the agent ran and the agent modified it again, a plain set-difference of filenames would miss it — the name was in both lists. Comparing fingerprints catches “changed again” as well as “newly appeared,” and it also avoids falsely flagging pre-existing untracked files (like node_modules) that never actually changed.

The gitignored-secret catch

When the sweep gathers candidate files it combines two git queries: tracked files modified versus HEAD, and untracked files. Crucially, it does not pass --exclude-standard to the untracked query. That flag would hide files matched by .gitignore — and a forbidden .env is typically gitignored. Omitting the flag means a secret file that git would normally ignore is still seen, still matched against the protected globs, and still reverted. The sweep deliberately looks where git is trained not to.

How a revert is done

Reverting depends on whether the file existed before:

• Tracked and modified — git checkout HEAD -- <path> restores the original and unstages the change.
• New (not in HEAD) — checkout can’t restore a file that never existed, so the sweep unstages it and deletes it from the working tree.
• Already gone — nothing to do.

Every reverted path is written to the audit log with the rule it broke, marked either reverted (the undo succeeded) or blocked.

Where it sits

The sweep is the in-repo counterpart to Landlock. Landlock walls off the world outside the worktree at the kernel level; the worktree itself is allowed, because the agent needs to edit code there. The sweep handles the fine-grained question of which in-repo files were off-limits — the category a kernel wall can’t express. Gate at write time, sweep after the fact, CODEOWNERS at merge time: three passes over the same protected list.

See also

• The gate — the write-time check this backs up.
• Landlock — the outer wall; the sweep covers the inside.
• Protected paths — what the sweep matches against.
• Morpheus drain — runs the sweep after each unattended run.