Scope writes by owner, and give the grant it already promised

[ptr727]

Resolves the gap reported in gh-write-guard-override-gap.md: rule 3's deny message promised a per-session permission path that did not exist in the code, so a maintainer's explicit, repeated authorization could not be honored.

Verified before changing anything

Claim	Result
Rule 3 denies unconditionally	True. The logic is inline in classify, not in a function named _check_cross_repo as the report quotes, so the report's code excerpt is a paraphrase. The message and behavior are quoted correctly.
GOVERNANCE.md is absent from HomeAutomation-Config, PhotoCleaner, PlexCleaner	True, all three 404. The deny message cited a file the reader cannot open.
The installed hook might be an older revision	False. The installed copy differs from this one by a single British spelling (judgement), so behavior is identical.

Why other repos wrote cross-repo without complaint

The report asks this to be reconciled, and it is not a permissions difference. Rule 3 has a narrow trigger, measured against the installed hook:

Command shape	Decision
explicit --repo, sibling repo, same owner	DENY
explicit --repo, different owner	DENY
no explicit target, so the target is the cwd's origin	ALLOW
explicit target, cwd is not a git checkout	ALLOW
explicit repos/owner/repo API path	DENY

So an agent that cds into the other repo and runs a plain gh issue create performs the same write invisibly, and an agent whose cwd does not resolve to a git origin skips the check entirely by design. HomeAutomation-Config's agent was not stricter, it used the one shape the guard can see. The hook is also matcher: "Bash" only, and was installed here on 2026-07-31, so nothing before that and no non-Bash path was ever covered.

What changes

The boundary moves to where the harm is. The incident was a stray comment on a stranger's repository, not work across the maintainer's own projects. A sibling repository under the same owner as origin is now allowed. A different owner is denied unless named in GH_WRITE_GUARD_ALLOW, as owner/repo or owner/*.

The grant is a channel the agent cannot use on itself. It is read from the environment the session was launched with. A hook runs as its own process, so an inline VAR=x cmd prefix or an export inside a Bash call never reaches it. A self-test case asserts exactly that, by classifying a command that carries the assignment as text and expecting a deny.

Nine self-test cases cover the matrix: same owner, the API-path form, a different owner with and without a grant, the owner wildcard, a repo grant not extending to that owner's siblings, one owner's grant not reaching another (the original incident, still denied), a malformed grant granting nothing, and the inline-prefix case above.

The prose moves with the code. GOVERNANCE.md "Repository Boundaries and Write Safety" and the claude-md-safety.md kit said "write only to the current project's own repository", which the hook would now contradict. A guard that allows what the rules forbid leaves the agent to guess which one binds, which is the confusion this report is about.

Two things reported, not changed

1. The no-origin skip is a real hole. When origin does not resolve, rule 3 is skipped and an explicit foreign target is allowed. Tightening it would deny ad-hoc work outside a checkout, so it is flagged for your call rather than changed alongside a loosening.
2. Rule 3 scans the raw command string, so merely mentioning a write denies. This fired live while probing the guard for this PR: a python3 heredoc containing the text gh issue create --repo ptr727/PhotoCleaner was denied, though it wrote nothing. Rule 1 strips quoted spans before scanning and rule 3 does not. The fix is to require gh in argv command position, the pattern _push_targets already uses for git push, and it deserves its own change with its own cases rather than riding along here.

Verification

• --selftest passes, 9 new cases plus the existing matrix.
• Decision boundaries measured by classifying strings against the installed hook, not inferred.
• prose_lint blocking set clean tree-wide, and clean on changed lines. repo_gate clean, 180 script tests pass.
• The hook keeps LF endings, and the three prose files keep CRLF.

Not installed to this host. ~/.claude/hooks/gh-write-guard.py still carries the old rule, so the change takes effect after you merge and reinstall. Say the word and I will run the install.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the GitHub write-safety guard and governance prose to allow writes across sibling repositories under the same origin owner, while still denying cross-owner writes unless explicitly granted via an environment allowlist.

Changes:

• Adjust Rule 3 in gh-write-guard.py to scope allowed explicit gh write targets to the origin owner, with cross-owner exceptions via GH_WRITE_GUARD_ALLOW.
• Add self-test coverage for the new Rule 3 decision matrix, including allowlist and “inline env prefix doesn’t apply” cases.
• Align the installed safety kit docs (claude-md-safety.md, host setup README) and committed governance (GOVERNANCE.md) to the new owner-scoped rule.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
host-setup/agent-safety/README.md	Updates host safety kit documentation to describe owner-scoped targeting and GH_WRITE_GUARD_ALLOW.
host-setup/agent-safety/gh-write-guard.py	Implements owner-scoped Rule 3 with GH_WRITE_GUARD_ALLOW support and expands self-tests.
host-setup/agent-safety/claude-md-safety.md	Updates the user-level CLAUDE.md safety block to match owner-scoped targeting and allowlist behavior.
GOVERNANCE.md	Updates “Repository Boundaries and Write Safety” to reflect the owner-scoped write boundary.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (1)

host-setup/agent-safety/gh-write-guard.py:93

• _EXPLICIT_REPO is currently anchored with a negative lookbehind (?<![\w\-]), which still matches -R... inside quoted arguments (e.g. a --title "-Rowner/repo") or other non-word-delimited text. Since rule 3 scans the raw command string (and does not strip quoted spans the way rule 1 does), this can cause false denies when the text merely mentions -Rowner/repo rather than using it as a flag. Anchoring the regex to token boundaries (start-of-string or whitespace) reduces these false positives without losing coverage of --repo=..., -R=..., or -Rvalue.

# Every spelling gh accepts for the target flag: `--repo x`, `--repo=x`, `-R x`, `-R=x`, and the attached
# short form `-Rx`. A form left out is not a near-miss, it is a silent bypass of the whole repository
# scope, so the separator is matched rather than assumed to be a space. The leading look-behind keeps
# `-R` from matching inside a longer token.
_EXPLICIT_REPO = re.compile(r"(?<![\w\-])(?:--repo[=\s]+|-R[=\s]*)(?P<q>['\"]?)(?P<r>[^\s'\"]+)(?P=q)")

[ptr727]

Answering the suppressed finding from round 2. Adopted in b3d40be42dbf21bcf96d2c3b853afaacb454c7ba, with the claim narrowed to what it actually achieves.

The anchor is right and I kept it. It now requires the flag to start a shell token, so your example denies nothing:

                              old pattern              new pattern
--title "-Rowner/repo"        ['esphome/esphome', ...]  ['ptr727/X']     <- fixed
--title "use -Rowner/repo"    ['esphome/esphome', ...]  unchanged        <- NOT fixed
-Rowner/repo                  unchanged                unchanged
--repo=owner/repo             unchanged                unchanged

But it does not close the class, and my first draft claimed it did. I wrote a case asserting that a mention inside a title stops being read as a target, and it failed on the run: a mention mid-prose is preceded by a space, exactly like a real flag, so no look-behind can separate them. The case now asserts the shape that holds, a value opening a quoted span, and the comment names the residual instead of implying it is gone.

Separating a flag from text needs argv-position parsing, the way _push_targets already does it for git push. That is the same open item this PR's description records under "reported, not changed", found when the guard denied a read-only python3 probe whose heredoc merely contained the text. It deserves its own change with its own cases rather than a look-behind that half-covers it.

No coverage is lost: all four bypass spellings from round 1 still deny, and a sibling owner still allows.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (1)

host-setup/agent-safety/gh-write-guard.py:96

• The comment above _EXPLICIT_REPO says the regex “does not reach a mention inside prose (--title "use -Rowner/repo")”, but the pattern only checks for preceding whitespace (or start of string). That means -Rowner/repo inside a quoted argument can still match when preceded by a space, so the comment is misleading about the current behavior.

# scope, so the separator is matched rather than assumed to be a space. The look-behind requires the flag
# to start a shell token (whitespace before it, or the string start), which is where a real flag always
# sits, so a value that opens a quoted span (`--title "-Rowner/repo"`) is not read as a target. It does
# not reach a mention inside prose (`--title "use -Rowner/repo"`), which is preceded by a space like a
# real flag: rule 3 reads the raw string, so telling a flag from text needs argv-position parsing, the
# way _push_targets does it for git push.

[ptr727]

Answering the suppressed finding from round 3. Fixed in 1708cd071276eb729a0c48cf60ef0ca1e720304b.

You read the comment as saying the pattern does not match there. I meant the anchor does not reach that case, so the behavior is unchanged and it still denies. Those are opposite readings of one sentence, and in a comment on a safety control an ambiguity that inverts the meaning is a defect regardless of which reading the author intended, so the wording is the thing to fix rather than the record.

It now states the behavior positively rather than as a negation:

A mention inside prose (`--title "use -Rowner/repo"`) IS still read as a target and still denies.
A space precedes it exactly as one precedes a real flag, so no look-behind can separate the two.

The measured behavior is unchanged and matches that sentence, and it is the same residual this PR's description and the previous round both record as needing argv-position parsing.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.