push-to-pull-request-branch safe output unconditionally requests issues: write

[timdittler]

Problem

The compiled .lock.yml for a workflow using only push-to-pull-request-branch safe output unconditionally requests issues: write permission — both in the job's permissions: block and via permission-issues: write on the GitHub App token step.

This requires the GitHub App installation to have issues: write granted, even though push-to-pull-request-branch only pushes commits to an existing PR branch and has no reason to create or modify issues.

Unlike create-pull-request, which has a documented fallback-to-issue behavior (and now supports fallback-as-issue: false per #15274), push-to-pull-request-branch does not accept fallback-as-issue — attempting to set it produces:

error: Unknown property: fallback-as-issue. Valid fields are: branch, commit-title-suffix, github-token, if-no-changes, labels, staged, target, title-prefix

Reproduction

1. Create a workflow with only push-to-pull-request-branch:

---
name: Example
on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - some/file.tf

safe-outputs:
  app:
    app-id: ${{ vars.APP_ID }}
    private-key: ${{ secrets.APP_PRIVATE_KEY }}
  push-to-pull-request-branch:
---
# My Workflow
Push changes to the PR branch.

2. Compile: gh aw compile
3. Observe the compiled .lock.yml contains:

    permissions:
      contents: write
      issues: write        # <-- not needed
      pull-requests: write

    steps:
      - name: Generate GitHub App token
        uses: actions/create-github-app-token@...
        with:
          permission-contents: write
          permission-issues: write        # <-- not needed
          permission-pull-requests: write

Impact

If the GitHub App installation does not have issues: write granted, the safe outputs job fails with:

RequestError [HttpError]: The permissions requested are not granted to this installation.

Expected behavior

push-to-pull-request-branch should only request contents: write and pull-requests: write (to push to the branch and interact with the PR). There is no issue-related fallback behavior for this safe output type, so issues: write should not be required.

Related

• Docs: safe-outputs.app: permission narrowing + (?) implicit permission inflation #15274 — documented the implicit issues: write for create-pull-request and added fallback-as-issue: false
• Conclusion job should not request discussions: write when workflow has no discussion-related safe-outputs #15516 — similar issue where discussions: write was unconditionally added

Version

gh aw version: v0.45.4