lockdown: treat leading "cd <path>" as no-op for leading-token analysis #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally filed by @coilysiren on 2026-05-14T19:25:41Z - https://github.com/coilysiren/cli-guard/issues/58
Problem
cli-guard's lockdown PreToolUse hook segment-splits a Bash invocation and validates each segment's leading token against the allowlist. Today,
cd <path> && coily ...fails because segment 1's leading token iscd, notcoily, even thoughcdis a shell builtin with no execve and the post-cdsegment is the only thing that needs gating.Observed today on a Mac session: harness denied
cd /Users/kai/projects/coilysiren/cli-guardwith no surfaced workaround. The denial fires during the exact kind of work the wrapper is meant to enable (cross-repo coily invocations bound to a specific commit-scope).Proposed change
In the segment loop (see
lockdown/hook.gosegment validation), if a segment matches a barecd <path>shape with no shell metacharacters and<path>resolves to a real directory, skip it from leading-token analysis and let the next segment speak for the chain. The chdir then happens naturally in bash when Claude runs the approved command. No hook rewrite needed.Boundary considerations
$(...), backticks, globs, unescaped spaces).cdsegments, or cap at one. I lean cap-at-one to keep the rule legible.cd X && rm -rf /stays denied becausermis not allowed, not becausecdis.cd.Related
--commit-scoperecovery suggestion in the denial message (separate work in coily-discipline, filed in coilysiren/coily).kai-coily-disciplinepointer cleanup (filed in coilysiren/coilyco-ai).