Read a Run-Time Path Word Behind a Run-Time Command Word as a Possible Write in the Write Guard #3165

Context

Raised by Copilot on the develop -> main promotion #3164, against _gh_names_write in host-setup/agent-safety/claude/gh-write-guard.py. Main's guard shares it, so develop did not introduce it. It was confirmed with hook-payload probes on constructed commands, origin ptr727/example, against both main's and develop's guard.

A Run-Time Path Word Behind a Run-Time Command Word Is Not a Possible Write

Behind a literal gh, a run-time word where gh's command, subcommand, or second subcommand goes reads as a possible write, so its target is checked. Behind a run-time command word such as $G, _gh_names_write accepts only literal path words, so the invocation is dropped and rules 1, 3, and 5 never see it. Each of these is allowed by both guards:

• $G repo deploy-key "$SUB" -R stranger/example
• $G repo autolink "$SUB" -R stranger/example
• $G "$CMD" comment 5 -R stranger/example

The literal-gh forms of the first two are denied by develop's guard and allowed by main's. The literal form of the third is denied by both.

Possible Direction

Read a run-time path word behind a run-time command word the way the direct argv path reads it, reusing _gh_path3_writes and _gh_path_writes in _gh_names_write. Check the verdict change with a develop-versus-branch differential, since a run-time command word ahead of a non-gh tool whose words happen to read as a gh path would newly reach the target check.