Live test: what does the scrub quarantine do?

[Mirrowel]

@Mirrobot-Agent quick question - when the workspace scrub removes an auto-loaded file, where does the content go? Asking for the live chain test.

[Mirrobot-Agent]

@Mirrowel Short answer: it's quarantined, not destroyed — and this session is a live example of the quiet case.

The mechanism (read straight from /tmp/scrub-workspace.sh):

• Every removal is appended to /tmp/scrub-removals.txt with path + reason, so nothing disappears silently.
• A removed auto-load file (AGENTS.md, CLAUDE.md, .claude/, .opencode/, etc.) is copied — symlinks dereferenced — to /tmp/scrub-quarantine/<original-path>, but only if its resolved target stays inside this repository. Out-of-repo/absolute symlink targets are removed with no copy (foreign runner files aren't PR content). When a copy is preserved, the log names both places.
• A quarantined copy is consultable on demand as data (e.g. an AGENTS.md describing a module I'm reviewing) — it's never auto-loaded, so it can't act as an instruction channel.
• Even beyond quarantine, the content stays visible in the PR's ref-based diff — it still exists on the PR's git ref, so removal hides nothing from review.

This session's live result: /tmp/scrub-quarantine/ and /tmp/scrub-removals.txt don't exist — meaning the scrub on this default-branch checkout removed nothing to quarantine. The interesting path (file differs from main/dev, gets pulled out, lands in quarantine) only fires on PR checkouts or tainted branches.

One deliberate exclusion worth noting: the workflow's scratch wipe (.mirrobot_files) is not quarantined, since it's regenerated per run.

This response was generated by an AI assistant.

[Mirrowel]

@Mirrobot-Agent follow-up: does the quarantine survive across runs, or is it per-session only?

[Mirrobot-Agent]

@Mirrowel Per-run only — the quarantine dies with the runner VM.

Why: it lives in /tmp (QUARANTINE_DIR / REMOVALS_FILE defaults, scrub-workspace.sh lines 91–92), and GitHub-hosted runners are ephemeral machines — when the job ends, /tmp is destroyed with it. I also checked every workflow for an escape hatch: no upload-artifact, no actions/cache, no env override relocating those paths anywhere (the only override in the repo is scrub-fixtures.sh redirecting them to test scratch space).

The nuance — "run" vs "scrub invocation": within a single run it does survive multiple scrubs. The removals log appends per invocation, and quarantine entries accumulate per original path, each re-quarantine replacing (never nesting with) its old copy. So if a session checks out ten PRs and scrubs after each, all ten quarantines coexist in one growing /tmp/scrub-quarantine/.

What persists instead (by design): the durable record was never the quarantine — removals get surfaced in the agent's final thread summary, and the removed content itself still lives on the PR's git ref, so the ref-based diff remains the permanent evidence. The quarantine is an in-session working convenience (consultable as data mid-review), not an archive. Small security bonus to the evaporation: quarantined files are untrusted instruction-file content, and not persisting them means no lingering stash of it on disk after the session that needed it is gone.

This response was generated by an AI assistant.