Fix triage: unusable model pin, and a sweep that cannot see pull requests

[swissspidy]

Two independent bugs, both of which have to be fixed before triage works end to end. Neither was introduced by the v3 upgrade in #279.

1. Triage fails on every run — an unavailable model

Every triage run since #279 has failed. The Copilot CLI's stderr is routed to debug-only logging by actions/ai-inference, so the reason was invisible until the job was re-run with debug logging:

##[debug]Copilot CLI stderr: Error: Model "gpt-4.1" from --model flag is not available.

gpt-4.1 is the action's own default for its model input, so the workflow inherited it without ever naming it. Copilot no longer offers that model and the CLI rejects it outright.

Setting model: auto — the CLI's documented value for letting Copilot choose — fixes the failure and stops the next model retirement from breaking triage the same way.

This also settles the authentication question. Run unauthenticated, the CLI fails with No authentication information found before it validates the model. This run got the model error instead, which means the token was accepted: GITHUB_TOKEN plus copilot-requests: write authenticates, the organization policy is enabled, and no PAT is required.

2. The unlabeled sweep silently sees nothing

Dispatching with an empty issue_number reports Found 0 open issues and PRs and triages nothing, while unlabeled pull requests such as #277 sit untouched. Reproduced in run 31708383158.

The count is zero in total, not zero after filtering — the listing itself comes back empty. issues.listForRepo returns issues and pull requests together, but pull requests are dropped when the token cannot read them, silently: a shorter list, not an error. This repository has no open issues, so the sweep saw nothing at all and exited 0 with No unlabeled items to process, which is why it never showed up as a failing check.

	triage-unlabeled-items permissions	Sees PRs
Before #275	no job-level block; inherits workflow-level pull-requests: write	yes
93855f4 (#275, Aug 7) onward	own block: actions: write, issues: read, contents: read	no

#275 scoped actions: write down to the one job needing it, which was right, but the new job-level block replaced the inherited permissions wholesale and pull-requests was not carried over. Granting pull-requests: read restores what the job saw before, and stays read-only — the sweep only reads and dispatches; label writes happen in the jobs it dispatches to.

Verification

actionlint passes. Behavioural checks, both of which need this merged first, since issue-triage.yml resolves the reusable workflow at @main regardless of the ref it is dispatched from:

• Open any issue or pull request; the triage run should now reach the model and apply labels.
• Dispatch with an empty issue_number; the count should be non-zero.

Known remaining issue, not fixed here

triage-single-item reads context.issue.number in its "Get item details" step, but a workflow_dispatch payload has no issue, pull_request or number, so it resolves to undefined. The apply step in the same job correctly uses inputs.issue_number. That means the runs the sweep dispatches will still fail at that step. Introduced in a482e38 (Apr 22), left alone here to keep this change reviewable.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

Warning

Review limit reached

@swissspidy, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 72 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: fcddfe48-032c-421d-9bf2-47eaab53ac20

📥 Commits

Reviewing files that changed from the base of the PR and between 6f8faea and 78f0367.

📒 Files selected for processing (1)

• .github/workflows/reusable-issue-triage.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[swissspidy]

The red issue-triage / Triage New Issue or PR check is not from this diff. pull_request_target runs the base branch's workflow, so that job executed main's v3 triage; this branch only adds pull-requests: read to a different job (triage-unlabeled-items), which that job never touched. It reproduces on any pull request opened against main right now.

It is, however, the first real execution of the v3 path, and it got further than the pre-merge attempts:

provider: copilot   model: gpt-4.1   GITHUB_TOKEN: ***
Running Copilot CLI: copilot -p <prompt> -s --no-ask-user --model gpt-4.1
##[error]Copilot CLI exited with code 1.

So the CLI installed, was found on PATH, spawned with the expected arguments, and received the token. The failure is inside the CLI, and actions/ai-inference routes its stderr to debug-only logging, so the reason is not in the log.

Two candidate causes, one now eliminated:

• Flag incompatibility — ruled out. The v3 action is pinned to a July 29 commit, so it could have been passing arguments a newer CLI rejects. I installed @github/copilot (1.0.79) and confirmed -p, -s, --no-ask-user and --model all still exist.
• Authorization — most likely. An unauthenticated CLI exits 1 in a few seconds, which matches this run's shape (~4s). Here the token was present, so the plausible reading is a token that is rejected rather than absent, which points at the organization policy "Allow use of Copilot CLI billed to the organization" being off. That is a settings toggle, not a code change.

To confirm rather than assume: re-run this job with Enable debug logging ticked, which surfaces the CLI's stderr. If it reports an authorization or entitlement error, the policy is the fix. If it reports something else, the diagnosis above is wrong and the log will say so.

This does not block merging — the fix here is independent and its own verification is the dispatch re-run described in the description.

---

Generated by Claude Code