The guard does not read a sourced file found through a PATH the line extends rather than replaces: after PATH=dir:$PATH, export PATH="dir:$PATH" or PATH+=:dir, a source of a bare name that dir holds is allowed unread, because the search gives up on a PATH value holding a variable instead of searching its fixed entries, and the += form is not read as an assignment at all. Found while fixing the zsh path array (iss-2610111730513071) in security lane G3, 2026-10-12; probe: PATH={d}/x:$PATH; source foo.sh = allow with x/foo.sh holding a blocker, while PATH={d}/x; source foo.sh blocks.

Frontmatter

.abcd/work/issues/resolved/iss-2610120953445472-guard-extended-path-source-unread.md
open on GitHub ↗ · commit history ↗

mentions2

• iss-2610111730513071The guard does not track zsh's `path` array, which zsh ties to PATH: a zsh line that assigns `path=(<dir>)` and then runs or sources a bare script name searches <dir>, while the guard's script reader judges the file its own PATH search finds. Left open by lane G on 2026-10-11 while fixing the script-lookup gap (iss-2610111600031244), because in bash `path` is an ordinary variable name and tracking it there would misjudge bash lines.
• iss-2610121214249290A command prefixed by an append assignment is not judged: FOO+=x rm -rf / is allowed while FOO=x rm -rf / blocks, because isAssignment accepts only NAME=VALUE, so the walk to command position takes FOO+=x for the command and the hazard for its operands; bash and zsh read NAME+=VALUE as an assignment prefix. Found in security lane G3 follow-up, 2026-10-12, while reading PATH+= for iss-2610120953445472, whose fix reads += only in the script reader's shell state.