.github/workflows/ai-policy.yml fails on any pull request opened from a fork
whose commits carry an Assisted-by: trailer — that is, on exactly the
contributions that follow the AI policy.
The policy checks pass. What fails is the labelling step that runs afterwards:
- name: Label PR as AI assisted
run: |
gh api "repos/${{ github.repository }}/issues/${{ ... }}/labels" \
--method POST -f "labels[]=AI assisted"
On a fork-triggered pull_request run, Actions secrets are not exposed, so
secrets.COMMAND_BOT_PAT is empty and the github.token fallback is read-only
regardless of the permissions: block. The API call returns 403 and the step
exits non-zero.
The preceding "Create 'AI assisted' label if absent" step already anticipates
this and swallows the error with || true; the labelling step does not.
Observed on nextcloud/serverinfo#1158, run log:
GITHUB_TOKEN Permissions
Contents: read
Issues: read
Metadata: read
PullRequests: read
Secret source: None
...
Found AI-assistant/Assisted-by/AI-Assisted-By trailer(s):
Assisted-by: ClaudeCode:claude-opus-5
...
gh: Resource not accessible by integration (HTTP 403)
##[error]Process completed with exit code 1.
Suggested fix
Labelling is cosmetic; the enforcement value of the workflow is in the
Signed-off-by / Co-Authored-By checks, which work fine on forks. Making the
two labelling steps non-fatal would be enough:
- name: Label PR as AI assisted
continue-on-error: true
If the label matters on fork PRs, it needs a separate pull_request_target
workflow, since only that event grants a writable token.
.github/workflows/ai-policy.ymlfails on any pull request opened from a forkwhose commits carry an
Assisted-by:trailer — that is, on exactly thecontributions that follow the AI policy.
The policy checks pass. What fails is the labelling step that runs afterwards:
On a fork-triggered
pull_requestrun, Actions secrets are not exposed, sosecrets.COMMAND_BOT_PATis empty and thegithub.tokenfallback is read-onlyregardless of the
permissions:block. The API call returns 403 and the stepexits non-zero.
The preceding "Create 'AI assisted' label if absent" step already anticipates
this and swallows the error with
|| true; the labelling step does not.Observed on nextcloud/serverinfo#1158, run log:
Suggested fix
Labelling is cosmetic; the enforcement value of the workflow is in the
Signed-off-by/Co-Authored-Bychecks, which work fine on forks. Making thetwo labelling steps non-fatal would be enough:
If the label matters on fork PRs, it needs a separate
pull_request_targetworkflow, since only that event grants a writable token.