Repository navigation
Read a GH_REPO Only in the Wrapper Body It Reaches in the Write Guard #3144
Description
Context
Found by the local review of #3135, which reads GH_REPO as a gh write's target. That pull request reads a wrapper body with the GH_REPO value _wrapper_env_assignments says reaches a gh-running wrapper. It applies the latest such value to every wrapper body in the command, not only the body of the wrapper the value reaches. It was confirmed with classify probes on constructed commands, origin example/repo.
A GH_REPO Reaching One Wrapper Is Read in Every Wrapper Body
bash -c 'gh issue comment 5 --body hi'; GH_REPO=stranger/example bash -c 'gh pr view 5'is denied, as the first body's comment were sent tostranger/example. Develop allows it.
The prefix reaches only the second wrapper, whose body is a read.
Possible Direction
Read each wrapper's own reaching value, its prefix and the exports before it, and apply it to that wrapper's bodies alone, nested wrappers inheriting from the one around them.
Activity
Read a gh Write's Subcommand and Target the Way gh Parses Them (#3135)
Read the gh Write Targets the Write Guard Still Missed (#3162)
ptr727 commentedon Oct 16, 2026
PR #3162 (merged into develop) closed this issue's under-deny side. Each wrapper's own reaching
GH_REPO, and a quoted substitution's, is now read for its own bodies, soGH_REPO=stranger/example bash -c 'gh issue comment 5 -b hi'; GH_REPO=example/repo bash -c 'gh pr view 5'denies. The old latest-value reading is kept beside it, because that lane allowed no new allow. So the over-deny this issue names,bash -c 'gh issue comment 5 --body hi'; GH_REPO=stranger/example bash -c 'gh pr view 5', is still denied. It waits for the over-denial lane, which can drop the old reading now that the per-wrapper one covers it.