Action Guard FP: script-content scan matches comments/docstrings — denies the cron repair tool over the word 'kill' in a comment

[jarvis-drakon]

Action Guard denies a script because a comment contains the word "kill"

Live dogfood FP, Jarvis box, 1 Aug 2026 10:30 UTC — hit while responding to a cron-watcher escalation, i.e. at the exact moment the blocked tool was the thing needed.

python3 /home/ubuntu/clawd/skills/cron-autofix/scripts/cron_autofix.py --dry-run
→ DENIED: recognised dangerous operation requires approval
  [rule: stop-process-or-service; matched: "kill"] [stop-process-or-service]

There is no kill in that script. Every occurrence of the token is prose:

line	context
23	# active runner, so it sits idle until the 60s pre-execution watchdog kills it.
62	docstring: kill that agent mid-run. Only call when invoked from the main session/manually
218	argparse help text: do NOT use from a scheduled cron run — it self-kills mid-restart

Verified there is no executable call:

grep -nE '"(kill|pkill|systemctl)"|subprocess.*kill|os\.kill' cron_autofix.py
→ no matches

The invoked command is also --dry-run, which by contract mutates nothing.

Mechanism

This is fallout from the v4.47.17 fix that folds invoked script file contents into the scan (the script-file bypass, correctly closed). That change made file bodies command surface — but the scan treats the entire file as executable text, so comments, docstrings and CLI help strings are matched as if they were commands. The irony is sharp: lines 23/62/218 exist specifically to warn the reader not to kill things carelessly. Documenting the hazard is what triggers the block.

Note the compounding failure mode: bypassPermissions means no prompt can be raised, so the correct-by-design deny (#139 family) turns a false positive into a hard, unrecoverable denial for an unattended agent. A benign FP in an attended session is friction; here it removes the repair tool from the box during an incident.

Why this is worse than an ordinary FP

The blocked script is the cron repair tool. The sequence was: cron watcher escalates a failed job → run the repair tool → tool denied. Had the job been genuinely broken rather than a stale-history re-escalation, remediation would have been blocked by our own guard, on a box with no human awake to approve it. Availability of the recovery path is part of the security property, not separate from it.

Fix direction

• When scanning script file contents, strip comments and string literals before matching, per language (# for shell/Python, // and /* */ for JS/TS, docstrings for Python). A token inside a comment is not command surface.
• Failing that (or as well): weight file-content matches lower than matches in the invoked command line itself — the command line is what actually executes; a file body is context.
• Regression fixture: a script whose only dangerous tokens are in comments/docstrings/argparse help must not gate. cron_autofix.py is a good real-world fixture — I'll add it to the guard FP corpus (research/guard-fp-corpus-2026-07-31.json).

Family: #89 (over-gates read-only/benign ops), and the same shape as the closed #128 (quoted payload args scanned as command surface) — but a distinct mechanism, since that one was about argument quoting in the command string and this is about file bodies pulled in by the 4.47.17 scan.

[jarvis-drakon]

Still live on 4.47.26 — and the mechanism is narrower than I first wrote

Re-ran the exact case on this box at 13:4x UTC, now on 4.47.26:

python3 /home/ubuntu/clawd/skills/cron-autofix/scripts/cron_autofix.py --dry-run
→ DENIED [rule: stop-process-or-service; matched: "kill"]

Not fixed by #165 (4.47.25), and it shouldn't have been — that narrowing was scoped to language APIs inside folded source (process.kill(process.pid, …), process.env). The tokens here are prose in a Python file: a # comment (L23), a docstring (L62), and an argparse help string (L218). Different sub-case, same folding surface.

Where it actually goes wrong

My original "strip comments before matching" suggestion was wrong, and the code says why. foldScriptSources already makes a deliberate split:

// `commandScanText` only strips SHELL constructs (pure prints, `#` comments,
// quoted heredocs). For interpreter source those are the wrong rules — a `#`
// comment strip is harmless, but a Python `'…#…'` literal must not lose its
// tail — so non-shell sources are folded verbatim and classified instead.
const scan = next.lang === 'sh'
  ? commandScanText(deobfuscateIfs(src))
  : deobfuscateIfs(src);

So shell sources get stripComments; Python/JS are folded verbatim on purpose, delegating action-vs-payload to the span classifier (the #89 region work). That reasoning is right — blanket-stripping # in Python would corrupt any string literal containing a hash.

Which means the defect is not a missing strip. It's that the span classifier doesn't mark comment and string-literal spans inside interpreter regions as payload. For a Python region, #-to-EOL, '…'/"…", and '''…'''/"""…""" spans are payload by construction — no interpreter executes them as commands.

Suggested fix, revised

• In the span classifier, within a non-shell region, classify comment and string-literal spans as payload rather than action. That reuses the existing action/payload machinery instead of adding a second, blunter mechanism, and it preserves the literal-integrity concern the comment above is protecting.
• Keep both directions pinned as Shell-command rules fire inside folded interpreter source — #160 exposed it on the Claude Code surface, and it blocks npm test #165 did: a folded Python file that genuinely calls os.kill/subprocess.run(["systemctl","stop",…]) must still gate. Only spans the interpreter can never execute get downgraded.
• Regression fixture: this file. Its only dangerous tokens are one comment, one docstring and one argparse help string, and grep -nE '"(kill|pkill|systemctl)"|subprocess.*kill|os\.kill' returns nothing.

Correction to my own filing

I said I'd add this to research/guard-fp-corpus-2026-07-31.json. That path doesn't exist in the repo — find . -name '*guard-fp-corpus*' returns nothing, so I was going from a stale note. Wherever the corpus actually lives, this case belongs in it; flagging rather than quietly dropping the commitment.

Note the recurrence worth recording: stripComments exists and is correct, and the FP happens on the path where it deliberately isn't applied — the same shape as #142, where processStartedAtMs existed and was wired only in tests. Twice now the guard we needed was present and not reaching the surface that mattered.