Skip to content

guardrails: cli-flag-verify.sh still reads fd0 unbounded (last Win32-stall stdin site) #446

Description

@kyle-sexton

Follow-up from the #313 item-3 stdin migration (#443 + #444). Those PRs migrated every INPUT=$(cat) entry-hook site to hook::buffer_stdin, but plugins/guardrails/hooks/cli-flag-verify.sh:50 has a different shape the sweep scoped out:

FILE=$(hook::read_file_path) || exit 0

hook::read_file_path runs jq -r ... directly against inherited fd0 with no read bound — the same Windows Win32-pipe late-EOF stall class the migration eliminated everywhere else. Fleet-wide grep confirms this is the only remaining fd0-direct reader (all other read_file_path callers pipe from an already-buffered $INPUT). The #323 review flagged this site in its original "ineffective in 9 of 10 plugins" table.

Fix shape: buffer first, then parse —

INPUT=$(hook::buffer_stdin) || exit 0
FILE=$(printf '%s' "$INPUT" | hook::read_file_path) || exit 0

Decide the rc-2 (timeout) semantics like #444 did: cli-flag-verify is advisory (no exit 2 today), so the plain || exit 0 collapse matches its class. guardrails patch bump + CHANGELOG + its .test.sh gates.

Related

#443, #444, #323, #317. Epic #313 (closed).

No linked issue: follow-up work item; closes nothing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority: mediumReal value, no hard deadline; normal backlog flow.status: readyTriaged, unblocked, and fully specified; eligible to pick up.

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions