guardrails: block-hook-bypass _py_write open( indicator blocks read-only python3 -c reads

[kyle-sexton]

Summary

block-hook-bypass.sh's _py_write indicator includes a bare open[[:space:]]*\(, which matches any open( — including a read. Since open() defaults to mode 'r', a python3 -c that only reads a file is blocked with a message asserting it writes.

Filing as a precision question, not a clear-cut bug: this lane documents an "ACCEPTED OVER-BLOCK" posture (the fail-closed choice approved for the PowerShell branch, block-hook-bypass.sh:468-475). But that documented acceptance covers prose/comment/quoted-string mentions of a write. A genuine read-only open() is a different category, and it is not called out as accepted anywhere I could find.

Related but distinct: #1178 (CLOSED) fixed the path( sub-indicator's unanchored match. This is the sibling open( sub-indicator, and it is a mode gap rather than an anchoring gap — so #1178's fix does not cover it and this is not a regression of it.

Reproduction (live, not constructed)

Hit incidentally while reading a JSON settings file during unrelated work:

python3 -c "
import json,os
p=os.path.expanduser('~/.claude/settings.json')
d=json.load(open(p,encoding='utf-8'))
print(json.dumps(d.get('statusLine'),indent=2))
"

Blocked with:

PreToolUse:Bash hook error: ["${CLAUDE_PLUGIN_ROOT}"/hooks/block-hook-bypass.sh]:
BLOCKED: python3 -c file write bypasses Write/Edit hooks
Use the Write or Edit tool instead of a shell file-write workaround.

There is no write in that command. The only open() is a read, and the sole side effect is print.

Mechanism

block-hook-bypass.sh:313:

_py_write='open[[:space:]]*\(|\.write[[:space:]]*\(|(^|[^[:alnum:]_])pathlib|(^|[^[:alnum:]_])path[[:space:]]*\('

The first alternative matches open( with no regard for mode. The call site at :505-508 gates only on "is this a python3 -c invocation?" plus that indicator:

if [[ "$EXEC_LC" =~ (^|[[:space:];|&()/\\]+)python3(\.exe)?[[:space:]]+-c ]] &&
  [[ "$COMMAND_LC" =~ $_py_write ]]; then
  block_bypass "python-write" "python3 -c file write bypasses Write/Edit hooks"
fi

Note the asymmetry with the PowerShell branch at :477, which requires a second confirming predicate (ps::might_write_via_python3) before blocking. The python3 -c site has no equivalent corroboration step.

Why it is worth precision work

json.load(open(p)) / open(p).read() is the most common way to read a config or JSON file in a one-liner, so this fires on routine read-only inspection rather than on anything resembling a bypass attempt. Two costs:

1. The diagnostic is false. It states the command writes and instructs the operator to "use the Write or Edit tool instead" — advice that cannot apply to a read. An operator who trusts the message is misled about what their own command did.
2. It trains around the guard. The natural response is to reach for another reader (jq, cat, Get-Content) until one is not blocked — which is exactly the "routine alternative after a denial" behavior pattern that makes over-blocking counterproductive.

Possible directions (not a prescription)

• Require a write-mode signal near the open( — e.g. a second argument containing w/a/x/+, or mode=. A bare open(x) and open(x, 'r') are unambiguously reads.
• Or mirror the PowerShell branch: keep open( as a cheap indicator but require a corroborating predicate before blocking, so the indicator alone cannot deny.
• Or, if the over-block is genuinely intended here, say so in the block message — "read-only open() is also blocked; use Read/Grep" — so the diagnostic stops making a false factual claim.

Whichever way it goes, the message text should not assert a write that did not happen.

Environment

Windows 11 / Git Bash, CLI 2.1.220, guardrails as installed from the melodic-software marketplace at the time of the block. Reproduced once, incidentally; I have not swept for other read-only idioms that trip the same indicator (pathlib and the .write( alternative were not exercised).

[kyle-sexton]

This was generated by AI during triage.

Triage: verified → briefed, human-gated

Category: Bug (precision / over-block), guardrails hook.

Verification — confirmed by source inspection, not by re-running the block. The mechanism is
exactly as reported. In block-hook-bypass.sh the _py_write indicator's first alternative is a
bare open[[:space:]]*\( with no mode discrimination, and its call site gates on only two
predicates — "is this a python3 -c invocation" and that indicator — with no corroborating
predicate. The asymmetry with the PowerShell branch, which requires a second confirming predicate
(ps::might_write_via_python3) before blocking, is present as described. Since open() defaults to
mode 'r', a read-only one-liner satisfies the indicator.

Redundancy check. Searched the guardrails hook surface for an existing mode-aware open(
discrimination or a corroborating predicate on the python3 -c branch: none exists. The reporter's
cross-reference to the closed sibling finding on the path( sub-indicator holds — that was an
anchoring fix and does not reach this mode gap, so this is not a regression of it. No
docs/out-of-scope/ ledger in this repo, so the rejected-concept check does not apply.

Why human-gated. The three directions the report offers are not one decision with a
maintainer-vetoable default — they split on guard posture:

• narrowing a fail-closed predicate in a security-adjacent hook (require a write-mode signal),
• keeping the cheap indicator but demanding corroboration before it can deny, or
• affirming the over-block as intended and correcting only the diagnostic.

The first two weaken a deny predicate; the third preserves it. Which is right depends on whether the
documented "ACCEPTED OVER-BLOCK" posture was meant to cover a genuine read-only open() — product
intent owned by whoever owns that posture, not inferable from the report.

Common ground, recorded so the decision is cheaper. All three directions agree on one point: the
block message must not assert a write that did not happen. Whichever posture is chosen, the
diagnostic text is in scope. That is a slice of the same item, not separable work, so it stays here
rather than being filed separately.

Live corroboration from this triage pass. While triaging this issue the same hook blocked a
cat > file heredoc used to stage a triage comment — a correct block on its own terms, and an
independent data point that this hook's deny paths are exercised routinely by ordinary agent work.
It does not bear on the open( mode gap.

Not verified, flagged as open: the reporter exercised only the open( alternative. The
pathlib and .write( alternatives were not swept for the same class of read-only false positive.

Labels applied: priority: medium (no work is blocked; the cost is a false diagnostic and a
train-around-the-guard incentive), needs-human; raw marker cleared.

[kyle-sexton]

Coordination note from the handoff-inbox batch-4 validation pass: #2217 files the opposite direction on the same regex — block-hook-bypass.sh:670 requires the literal python3, so python -c, py -c and python3.11 -c are not matched at all (reproduced at HEAD 685dd381). Widening that interpreter pattern touches the same detector this issue reports as over-blocking, so the two want one sitting rather than two. No change to this issue's own scope.

[kyle-sexton]

Closing as already addressed on main: read-only open() in inline python is no longer treated as a write indicator unless a write-mode literal co-occurs (py_write_indicator / #2217). Test: python -c read-only open (allowed).