The 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.

Frontmatter

.abcd/work/issues/resolved/iss-2610111730513071-guard-misses-zsh-path-array.md
open on GitHub ↗ · commit history ↗

mentions2

• iss-2610111600031244The guard's script reader resolves a different file than bash runs in three ways: after `cd` it keeps the logical path (so `cd -P link && bash ../s.sh` judges the file beside the link while bash runs the one beside its target), it ignores `CDPATH`, and `source` of a bare name ignores a `PATH` prefix on the same command. Each lets a planted script carrying a bundled blocker run with exit 0.
• iss-2610120953445472The 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.