`add-labels` safe-output always mints `pull-requests: write`; no `pull-requests: false` opt-out like `add-comment`

[seesharprun]

The add-labels safe-output unconditionally requires pull-requests: write in the minted GitHub App token, even when every target is an issue. Unlike add-comment, it exposes no toggle to exclude the PR scope. An App intentionally scoped to contents: read + issues: write therefore cannot use add-labels — the token mint fails with The permissions requested are not granted to this installation (HTTP 422).

Scenario

• A GitHub App granted only contents: read + issues: write.
• Goal: read existing issues, add comments to them, and apply a label to the issue. No pull-request access wanted or granted.
• add-comment works within these scopes by setting pull-requests: false.
• add-labels has no equivalent, so the safe_outputs job's token mint is rejected and no comment/label is written.

Reproduction

safe-outputs:
  github-app:
    client-id: ${{ vars.APP_CLIENT_ID }}
    private-key: ${{ secrets.APP_PRIVATE_KEY }}
    owner: my-org
    repositories: [my-repo]
  add-comment:
    pull-requests: false        # OK: excludes pull-requests:write
  add-labels:
    allowed: [routed]           # always forces pull-requests:write

Compile and run against an App that lacks pull-requests: write. The safe_outputs job fails at Generate GitHub App token:

The permissions requested are not granted to this installation. (HTTP 422)

Expected behavior

add-labels should be usable with issues: write alone when it targets only issues — mirroring the issues: / pull-requests: handler toggles that add-comment already supports, or inferring issue-only scope from the resolved target so the minted token omits pull-requests: write when PRs aren't targeted.

Actual behavior

add-labels always requests contents: read + issues: write + pull-requests: write, with no opt-out.

Source pointers and a minimal fix that mirrors add-comment

• add-comment's toggle lives in pkg/workflow/add_comment.go: AddCommentsConfig.PullRequests *bool (yaml pull-requests), and buildAddCommentPermissions() adds pull-requests: write only when that field is nil/true.
• add-labels lives in pkg/workflow/add_labels.go: AddLabelsConfig has no Issues / PullRequests fields.
• Its permission builder is the add-labels descriptor in pkg/workflow/safe_output_handlers.go, which returns the hardcoded NewPermissionsContentsReadIssuesWritePRWrite().
• Minimal change: add Issues / PullRequests *bool to AddLabelsConfig, add a buildAddLabelsPermissions() that mirrors buildAddCommentPermissions(), and point the add-labels descriptor's PermissionBuilder at it instead of the fixed constant.
• Docs follow-up: the safe-outputs reference doesn't cover the pull-requests: / issues: toggles for add-comment (the pull-requests: false behavior is currently only discoverable in source); document them for both handlers.

Related

• safe_outputs minted App token caps issues:* permission at workflow-level value, blocking add-comment / add-labels #30392 — same underlying principle (safe_outputs App token = union of handlers' actual scopes); fixed the issues:* cap but not add-labels' PR scope.
• Compiled lock file requests broader permissions than workflow needs (discussions:write, pull-requests:write) #26486 — least-privilege for compiled permissions.

Environment

• gh-aw compiler: behavior verified in current main source (see details above); reproduced on the v0.83.x setup action.
• actions/create-github-app-token@v3.2.0.