Environment
- mimosa 1.0.3 from the official ZCode plugin marketplace (
zcode-plugins-official), Windows (win32 10.0.26200), ZCode CLI sessions 2026-09-23/24.
- Affected project: Nexusmill/colibri-code-review (public - full finding-by-finding adjudication is in its gate-evidence docket, EV-124).
Summary
While landing documentation commits, the mimosa git-gate (PreToolUse on Bash, project-wide scan of the session repo on any git commit) blocked every commit from ZCode sessions in the repository on 12 HIGH findings. All 12 findings - and all 11 findings from the owner-requested /mimosa-deep-audit - were adjudicated false (refuted on current bytes, or stale). Three defects turned that from a nuisance into a total commit lockout.
Related issues
Defects 2-3 below reproduce and extend an already-reported class: #762 (gate ignores the accepted list the security_scan MCP tool honors; blocks every commit/push), #526 and #613 (no exemption/baseline channel; stock code hard-blocked; sealed scan does not change the gate's verdict), #329 (exclusions ignored, no false-positive disposal path, disable does not take effect), #481 (denials not recorded, no scoped suppression), and zcode-plugins#17 (whole-workspace scan false-blocking stock code, 591 vs sealed 43 findings). Newly reported here: defect 1 (citations past EOF from stale snapshots) and the direct proof in defect 2 that the git-gate does not read deep-scan artifacts at all - the remedy loop is structurally unreleasable, not merely unergonomic.
Defect 1: the scanner analyzes stale file snapshots and cites lines past EOF
Findings against agent_error_rates.py cite lines 569 and 658 of a 555-line file - line numbers beyond the end of the file on disk. Both the commit-gate scan and the deep-audit scan returned the same past-EOF citations (deep scan scan-2026-09-24T07-29-48.380Z-ad39e2b96da8, seal sha256:cd19ef4e), so both analyzed a stale mid-edit snapshot of a file that had since been shortened. A scanner that reports line citations beyond the current EOF has no snapshot-invalidation guarantee at all.
Expected: invalidate per-content (hash/mtime) before analysis; never emit a citation past the file's current EOF.
Defect 2: the git-gate does not read deep-scan artifacts - its remedy loop cannot release itself
Immediately after the sealed deep scan completed (result verdictEffect: "none"), the next commit attempt was denied with the same finding set - still including four test-file hits that the deep scan never made. The gate and the deep scan are disjoint scanners with no shared state, so the plugin's own remedy (address findings, then rescan) can never clear the gate when findings are false positives. There is no acknowledgment, allowlist, or adjudication path (none in the shipped contracts; hooks and rules are sealed). The result was eight byte-identical denials of already-adjudicated content across two days and multiple sessions, ended only by disabling the plugin.
Defect 3: no finding-memory - byte-identical re-denial
Each commit attempt re-ran the full scan and re-denied on identical bytes with identical findings, eight times. An adjudicated finding (or even an unchanged content hash) should never re-fire as if new.
Additional observation: the documented disable procedure silently failed
The README correctly says to start a new task after disabling the plugin (hooks snapshot at task startup). We did - and the gate still fired, because the Settings disable had never persisted: the plugin's enable flag still read true in the ZCode config after the UI showed it disabled, so the fresh session re-armed the gate. Whatever layer owns that write, the documented disable path can fail silently and leave the gate active.
Finding-quality context
Of 23 total findings (12 gate + 11 deep-scan) against this repository, zero survived adversarial adjudication. Representative false positives: path-traversal findings against the path sanitizer itself (_safe_name flattens both separator forms to __ before any join), mkdtemp + literal-name test fixtures flagged as traversal sinks, and the designed model-catalogue lookups (one operator-configured base URL, one hardcoded literal URL - no steerable input) flagged as injection-adjacent. The full adjudication is public (EV-124, linked above). Individually these are ordinary static-analysis false positives; combined with a hard commit BLOCK and no release path (defect 2), each one is a permanent repository lockout.
Requested remediation (any one breaks the lockout)
- Content-hash/mtime snapshot invalidation; refuse to emit citations past EOF.
- Shared finding state: a completed deep scan supersedes the gate's finding set.
- An adjudication/acknowledgment mechanism keyed to content hashes, so identical bytes cannot re-deny.
- Make
/mimosa-status (or the gate's denial text) report when the gate is armed from an enable flag the user believes they disabled.
Environment
zcode-plugins-official), Windows (win32 10.0.26200), ZCode CLI sessions 2026-09-23/24.Summary
While landing documentation commits, the mimosa git-gate (PreToolUse on Bash, project-wide scan of the session repo on any
git commit) blocked every commit from ZCode sessions in the repository on 12 HIGH findings. All 12 findings - and all 11 findings from the owner-requested/mimosa-deep-audit- were adjudicated false (refuted on current bytes, or stale). Three defects turned that from a nuisance into a total commit lockout.Related issues
Defects 2-3 below reproduce and extend an already-reported class: #762 (gate ignores the accepted list the
security_scanMCP tool honors; blocks every commit/push), #526 and #613 (no exemption/baseline channel; stock code hard-blocked; sealed scan does not change the gate's verdict), #329 (exclusions ignored, no false-positive disposal path, disable does not take effect), #481 (denials not recorded, no scoped suppression), and zcode-plugins#17 (whole-workspace scan false-blocking stock code, 591 vs sealed 43 findings). Newly reported here: defect 1 (citations past EOF from stale snapshots) and the direct proof in defect 2 that the git-gate does not read deep-scan artifacts at all - the remedy loop is structurally unreleasable, not merely unergonomic.Defect 1: the scanner analyzes stale file snapshots and cites lines past EOF
Findings against
agent_error_rates.pycite lines 569 and 658 of a 555-line file - line numbers beyond the end of the file on disk. Both the commit-gate scan and the deep-audit scan returned the same past-EOF citations (deep scanscan-2026-09-24T07-29-48.380Z-ad39e2b96da8, sealsha256:cd19ef4e), so both analyzed a stale mid-edit snapshot of a file that had since been shortened. A scanner that reports line citations beyond the current EOF has no snapshot-invalidation guarantee at all.Expected: invalidate per-content (hash/mtime) before analysis; never emit a citation past the file's current EOF.
Defect 2: the git-gate does not read deep-scan artifacts - its remedy loop cannot release itself
Immediately after the sealed deep scan completed (result
verdictEffect: "none"), the next commit attempt was denied with the same finding set - still including four test-file hits that the deep scan never made. The gate and the deep scan are disjoint scanners with no shared state, so the plugin's own remedy (address findings, then rescan) can never clear the gate when findings are false positives. There is no acknowledgment, allowlist, or adjudication path (none in the shipped contracts; hooks and rules are sealed). The result was eight byte-identical denials of already-adjudicated content across two days and multiple sessions, ended only by disabling the plugin.Defect 3: no finding-memory - byte-identical re-denial
Each commit attempt re-ran the full scan and re-denied on identical bytes with identical findings, eight times. An adjudicated finding (or even an unchanged content hash) should never re-fire as if new.
Additional observation: the documented disable procedure silently failed
The README correctly says to start a new task after disabling the plugin (hooks snapshot at task startup). We did - and the gate still fired, because the Settings disable had never persisted: the plugin's enable flag still read
truein the ZCode config after the UI showed it disabled, so the fresh session re-armed the gate. Whatever layer owns that write, the documented disable path can fail silently and leave the gate active.Finding-quality context
Of 23 total findings (12 gate + 11 deep-scan) against this repository, zero survived adversarial adjudication. Representative false positives: path-traversal findings against the path sanitizer itself (
_safe_nameflattens both separator forms to__before any join), mkdtemp + literal-name test fixtures flagged as traversal sinks, and the designed model-catalogue lookups (one operator-configured base URL, one hardcoded literal URL - no steerable input) flagged as injection-adjacent. The full adjudication is public (EV-124, linked above). Individually these are ordinary static-analysis false positives; combined with a hard commit BLOCK and no release path (defect 2), each one is a permanent repository lockout.Requested remediation (any one breaks the lockout)
/mimosa-status(or the gate's denial text) report when the gate is armed from an enable flag the user believes they disabled.