Bot pull requests stay blocked by the unattributed-changes approval

[shiny-code-app]

Objective

Let the automation app merge its own ordinary pull requests without the owner's approval, as the ruleset pair intends, instead of hitting the "extra approval for unattributed changes" setting.

Evidence

• cbusillo/shiny-infra-ops#305 was opened by shiny-code-app[bot] and passes validation-gate, but stays BLOCKED. Merging it as the app fails.
• Both rulesets on that repository have require_extra_approval_for_unattributed_changes: true. One of them, "Code-owner review for DIRECTION.md", has no bypass actors by design, so the app cannot bypass it.
• git-commit-as-bot authored the commit as shiny-code-bot (the older machine user, from CODEX_AUTOMATION_LOGIN in local.env), not the app. After the commit was re-credited to shiny-code-app[bot], the timeline recorded the force push as cbusillo. So git-push-as-bot pushed with a credential that resolves to the owner, and the PR stayed blocked.
• In codex-skills, bot-authored PRs such as Preserve structural evidence in blocked train responses #788 show merged_by: cbusillo, with commits by shiny-code-bot. Merges there appear to land under the owner's account, not the app.
• cbusillo/direction#1 merged because the owner approved it.

Inferred, not verified: the push and commit identity not matching the app that authored the pull request counts as an "unattributed change".

Finish Line

A bot-authored pull request whose commits and pushes come from the app merges as the app with no owner approval on a repository with the standard ruleset pair, and DIRECTION.md pull requests still require the owner. Or, if that is not possible, the rulesets change so that only DIRECTION.md and CODEOWNERS require the owner, as the owner decided on 2026-09-21.

Current Status

State: Active.
Next action: confirm which credential git-push-as-bot resolves in owner sessions, and what GitHub counts as unattributed; then fix the helper identity or the ruleset setting.

[shiny-code-app]

More evidence: the catalog's ruleset body (skills/github/scripts/github_rulesets.py) never sets require_extra_approval_for_unattributed_changes, yet both live rulesets on shiny-infra-ops and codex-skills have it set to true. So GitHub's default is being applied, and it applies on every repository where the standard pair was installed. Because the "Code-owner review for DIRECTION.md" ruleset has no bypass and covers every pull request to the default branch, the setting has to be false in that ruleset too, or the app can never merge. Candidate fix: set it to false explicitly in both ruleset bodies, re-plan with gh-rulesets.py, and have the owner apply it as an admin. Code-owner review still protects DIRECTION.md and CODEOWNERS. What GitHub counts as unattributed has not been verified against GitHub's documentation.

[shiny-code-app]

Correction: the causes suggested above are contradicted by evidence. Do not apply the proposed fix until the real cause is found.

• The app did merge on its own until recently. codex-skills Catch git commit and push behind global options #736–Start required local services without changing configuration #783 (9/22–9/24) show merged_by: shiny-code-app[bot], with commits authored by shiny-code-bot. shiny-infra-ops Local LLM advisory skill scenarios #303 was app-authored, its branch pushed by cbusillo, had no reviews, and was merged by the app on 2026-09-24 19:20 UTC. That is the same setup as Skill coverage matrix and CI promotion decision #305, which was blocked. So commit author and push identity are not the cause.
• The rulesets have not changed since 2026-09-22 (updated_at).
• Last known app merge: 2026-09-24 19:20 UTC (shiny-infra-ops Local LLM advisory skill scenarios #303). First known block: shiny-infra-ops Skill coverage matrix and CI promotion decision #305, tried 2026-09-25 about 02:45 UTC. codex-skills Support reviewed Launchplane expected-config metadata changes #786 (20:25) and Preserve structural evidence in blocked train responses #788 (21:36) were merged by cbusillo; whether the app was blocked on those is not known.
• Still to check: whether GitHub changed rule behavior or the unattributed default in that window; whether the app installation's permissions or token changed; and what gh pr merge as the app reports on a fresh test PR.
• Scope: the pair is installed on all 53 adopted repositories, so any fix has to be applied across all of them by script, not repository by repository.

[shiny-code-app]

Findings from the investigation (2026-09-25):

• GitHub's docs: the setting adds an approval "when Copilot opens a pull request that isn't attributed to a person". The feature is in public preview and "subject to change". The docs also say it has no effect when zero approvals are required: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets
• Other projects hit the same thing with zero required approvals and fixed it by setting the parameter to false explicitly, because GitHub's API defaults it to true when a payload leaves it out: fix(ruleset): disable extra approval for unattributed agent commits NDDev-OpenNetwork/ci-workflows#104 (2026-09-14), chore(policy): .maintainer.yml says merges are never human-gated, but the ruleset requires an extra approval for unattributed commits developerz-ai/wurk#488 (2026-09-02).
• Commit attribution is not the cause here: Local LLM advisory skill scenarios #303 (merged by the app on 9/24) and Skill coverage matrix and CI promotion decision #305 (blocked) both have commits attributed to linked accounts. Both were opened by the app, not on behalf of a person. The only difference found is time. Most likely cause (inferred): during the preview, GitHub began enforcing the setting on app-opened pull requests sometime between 2026-09-24 19:20 UTC and about 02:45 UTC on 9/25.
• Fix: in skills/github/scripts/github_rulesets.py, set require_extra_approval_for_unattributed_changes: False explicitly in both pull_request rule bodies (next to lines 109 and 195), with a test. Then the owner runs one admin apply across every adopted repository: gh-rulesets.py apply --all-owned --owner cbusillo --confirm-owner-admin-write. Code-owner review still guards DIRECTION.md and CODEOWNERS.
• Proof: after the apply, one app-opened pull request merges as the app with no approval. A DIRECTION.md pull request still requires the owner.

[shiny-code-app]

Result after applying #792's rules (2026-09-25): require_extra_approval_for_unattributed_changes is now false on both rulesets in all 54 repositories (apply ok, 0 failures, verified through rules/branches/main). But #792 itself is still BLOCKED ("the base branch policy prohibits the merge"), even after close/reopen and a fresh green check run. So that setting is not the cause, or not the only one.

More facts:

• The owner's account also sees Turn off GitHub's unattributed-changes approval in the standard rulesets #792 as BLOCKED, with viewerCanMergeAsAdmin: false, so the block is not specific to the app.
• The app's bypass on the landing ruleset is intact (current_user_can_bypass: always; Integration 5028253).
• The rule suite for the last successful app merge (codex-skills, 9/24 11:18 EDT) shows the direction pull_request rule passing, and the landing update rule failing but bypassed.
• No CODEOWNERS path is touched, no reviewers are requested, and required checks are green. codex-skills classic protection: required checks, enforce admins, conversation resolution; no required reviews.

Next isolation step (needs owner admin): set the "Code-owner review for DIRECTION.md" ruleset on one repository to evaluate for a few minutes and see whether #792 becomes mergeable. Then the same for the landing ruleset. Restore both right after.

[shiny-code-app]

Root cause found, and it was not GitHub: the direction session merged with raw gh pr merge (through gh-with-env-token) instead of the catalog's gh-pr.py merge.

• On these repositories mergeStateStatus always reads BLOCKED, because the landing ruleset's update rule restricts main to bypass actors. gh pr merge checks that status on the client side and refuses with "the base branch policy prohibits the merge" without trying. gh-pr.py merge calls PUT /pulls/{n}/merge, where the app's bypass applies. Turn off GitHub's unattributed-changes approval in the standard rulesets #792 merged that way as shiny-code-app[bot] on the first try.
• The session also asked for --squash, but these repositories allow merge commits only.
• The earlier theories in this issue (commit attribution, push identity, GitHub's unattributed-changes setting) were wrong. Turn off GitHub's unattributed-changes approval in the standard rulesets #792's explicit require_extra_approval_for_unattributed_changes: false is still worth keeping, because it stops GitHub's default from silently gating pull requests with unlinked commit authors. It is live on all 54 repositories.
• Gap: the command-policy hook catches raw gh pr merge but not gh-with-env-token pr merge, so this path went unwarned. Follow-up: extend the policy to wrapper-prefixed pr merge.