fix(disk-hygiene): engine gate over-gates a consumer's own engine-named script when its absolute path holds a non-keep-class character

[kyle-sexton]

🤖 Agent-authored (autonomous babysit lane). Found by codex review on #1625 (P2), verified and filed rather than fixed there — that PR was two rounds past its fix cap and its last two fix rounds had each introduced a fresh defect, so the disciplined move was to stop patching and record this properly.

Problem

_engine_gate_relevant's unparsable branch derives marker tokens as maximal runs of path-legal characters (_MARKER_TOKEN_SPLIT = [^A-Za-z0-9._\-/\\:]+) and then requires the "provably a DIFFERENT file" escape to see an absolute path. Those two rules fight each other: any character outside the keep class splits an absolute consumer path into fragments, and the fragment carrying the filename is no longer absolute, so the escape cannot fire and the guard gates a consumer's own tool.

This is the same bug class as #1611 — the guard denying unrelated work — in a narrower population.

Reproduction

A consumer's own hygiene.py under an absolute parent path, in an operator-carrying command: python3 <abs>/hygiene.py --help && echo done.

Consumer parent directory	pre-#1625	at b90084bc
consumer+tools	defer	GATE
consumer@tools	defer	GATE
consumer tools (space)	GATE	GATE (unchanged)
plain_tools under a Windows 8.3 temp path	defer	GATE

Note the last row: codex reported this for punctuation like +, @, =, but it is broader. That path contains no punctuation of its own — it over-gates because the enclosing Windows temp path is C:\Users\KYLESE~1\..., and ~ is outside the keep class. Short-name path segments are ordinary on Windows, so the affected population is wider than "unusual characters in a path".

Severity is bounded: this is over-gating, the fail-closed direction. It cannot cause the guard to miss an engine invocation. The cost is a consumer being denied work on their own unrelated file.

Why the obvious fix is not obvious

Widening the keep class walks straight back into the failure that started #1625's review chain. The first cut there split on shell metacharacters, and codex's first P1 showed that an assignment (engine=hygiene.py) glues with =, which is not a metacharacter — a real fail-open. Enumerating "safe" path punctuation re-opens exactly that door, because every character added to the keep class is a character that can also glue the marker to a neighbour.

The tension is structural: detection wants aggressive splitting, resolution wants whole paths, and one token list is currently serving both.

Suggested direction

Separate the two, rather than trying to find one delimiter set that satisfies both:

• Detect the marker with the existing fine-grained tokens — unchanged, so no fail-open reopens.
• Resolve the "provably a different file" question against the coarse whitespace/quote-delimited token that contains the fine token, which preserves the whole path.

Sketch, not prescriptive:

raw_tokens = [t.strip("'\"") for t in _LINE_CONTINUATION.sub("", command).split()]

def _provably_other(token: str) -> bool:
    candidates = [token] + [raw for raw in raw_tokens if token in raw]
    return any(
        os.path.isabs(c) and _script_path_key(c) is not None and not _samefile(c)
        for c in candidates
    )

I traced this against the shapes #1625's review chain established, and it appears to hold — cd <scripts>;./hygiene.py scan still gates (the coarse token <scripts>;./hygiene.py does not resolve), cd <scripts> && ./hygiene.py apply still gates (the coarse token is relative), and /tmp/consumer+tools/hygiene.py defers again. Treat that as a hypothesis, not a result — I did not implement or test it, and the last two changes in this area each looked equally sound before their differential run said otherwise.

Acceptance criteria

• A consumer's own absolute hygiene.py defers in an operator-carrying command regardless of punctuation, ~ short-name segments, or spaces in its parent path.
• Every shape in fix(disk-hygiene): match the engine marker on a filename boundary #1625's four differential matrices holds its verdict — in particular the assignment (engine=hygiene.py && python3 "$engine" apply), line-continuation, and post-cd relative shapes must still gate.
• Verified as a differential against the current guard, not by reasoning alone. #1625 has the probe scripts' shape in its thread evidence if useful.

[kyle-sexton]

🤖 Agent-authored (autonomous babysit lane). Disposition correction.

I filed this as a deferrable out-of-scope finding from PR #1625's review. That framing was wrong on the policy that actually applies: a valid finding may be deferred only when it is out of scope and tracked, and a regression the change itself introduced is never deferrable — it is fixed or reverted.

This over-gate does not exist on main. PR #1625 introduces it. So it is not an independent backlog item to be picked up later; it is one of two outstanding defects that PR must resolve before it can merge, alongside the Windows trailing-dot fail-open in its final unresolved thread.

The issue stays open as the record of the finding and its reproduction, which are unaffected. What changes is the expectation attached to it: it should be closed by whatever resolves #1625, not scheduled separately. If #1625 is reverted rather than fixed, this issue goes with it — the over-gate disappears when the change does.

PR #1625 is parked with do-not-merge at b401bd08 and annotated with the same correction.

[kyle-sexton]

This was generated by AI (triage lane, gate-audit pass — cycle 2 retry, instance melo-lap-001-triage-20260727T125559Z).

Verdict: REAL — but NOT independently schedulable; coupled to PR #1625

Strongly evidenced: a four-row differential reproduction matrix with pre-#1625 vs b90084bc verdicts, and the observation that the affected population is wider than "unusual characters in a path" (the Windows 8.3 row over-gates purely because ~ in a C:\Users\KYLESE~1\... style path falls outside the keep class — no punctuation of its own required).

The follow-up comment is disposition-controlling and changes the routing. This over-gate does not exist on main; PR #1625 introduces it. Per the policy that comment invokes, a regression the change itself introduced is never deferrable — it is fixed or reverted. So this is not a backlog item to be picked up on its own: it should be closed by whatever resolves #1625, and if #1625 is reverted the issue goes with it. PR #1625 is parked with do-not-merge at b401bd08.

Not agent-ready, on three independent counts:

• The open decision is fix-vs-revert of fix(disk-hygiene): match the engine marker on a filename boundary #1625, which is not this issue's to make.
• The body's own suggested direction is explicitly labeled a hypothesis, unimplemented and untested, with the warning that the last two changes in this area each looked equally sound before their differential run said otherwise.
• The tension named — detection wants aggressive splitting, resolution wants whole paths, one token list serving both — is structural, and widening the keep class walks back into the confirmed assignment-gluing fail-open that the review chain already caught once.

area: security applied: the owning surface is the disk-hygiene destructive-operation guard script, a bypass-prevention control. The current defect is over-gating in the fail-closed direction and is bounded, but the failure mode of a careless fix is fail-open on that guard, which is exactly the security floor.

Priority high because it is one of two defects blocking a parked in-flight PR, not because the over-gate itself is severe. automated retained.

Triage-lane footnote, offered as live corroboration: this comment could not be posted through the normal path. The first attempt was refused by the disk-hygiene guard itself, because the comment body quoted the engine-marker tokens from this issue's own reproduction section. That is an independent, unplanned reproduction of the finding's class — the guard gating a consumer's entirely unrelated work — encountered by a read-only triage pass that touches no engine at all. Recorded as an observation only; it does not change the verdict or the labels above.

Labels applied: priority: high, work-class: scoped, area: security, needs-human, status: needs-decision (removed priority: needs-triage).