fix(ci): give the @claude mention workflow a usable GitHub token

[MaryWylde]

The job supplied neither github_token nor id-token: write, so claude-code-action fell back to minting a token over OIDC and failed all three attempts with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL".

Use the run's own GITHUB_TOKEN, matching claude-code-review.yml in this repo, which avoids depending on the Claude GitHub App being installed on the org. Comment permissions go read -> write so Claude can post replies.

[github-actions]

Claude finished @MaryWylde's task in 1m 19s —— View job

---

Review: fix(ci): give the @claude mention workflow a usable GitHub token

• Gather context (read diff, compared with claude-code-review.yml)
• Understand the request (review the CI token fix)
• Review correctness/security of workflow change
• Post final review

Summary

The core fix is correct: passing github_token: ${{ secrets.GITHUB_TOKEN }} matches the working pattern in claude-code-review.yml and avoids the OIDC minting path that was failing with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL". Good diagnosis, and the added comments explain the why well for future readers.

The pull-requests/issues permission bump from read → write is correctly scoped — Claude needs to write comments/replies, and this doesn't touch contents, so it doesn't broaden write access to the repo itself.

The existing author_association gating (lines 38–50, unchanged by this PR) is sound and untouched — no regression there.

One thing worth confirming before merge

contents permission (line 56) stays read. That's fine if this workflow is meant to be review/answer-only. But unlike claude-code-review.yml (which never pushes), this mention workflow's own trigger prompt explicitly supports implementation requests and instructs pushing via git-push.sh origin HEAD using this same token. git push with the default GITHUB_TOKEN needs contents: write — with read, implementation-type @claude mentions will still fail, just later (at push time, 403) instead of at token-mint time. Left an inline comment with details.

If the intent is genuinely review/Q&A only for this trigger, this is a non-issue — otherwise contents: write is likely needed too.

[github-actions]

contents stays read here while pull-requests/issues go to write. That's enough for Claude to comment, but this workflow (unlike claude-code-review.yml, which never pushes) is the one that handles implementation requests — the task prompt driving @claude on PRs explicitly instructs pushing via git-push.sh origin HEAD using this same github_token.

git push over the default GITHUB_TOKEN needs contents: write; with contents: read that push will get a 403, so "straightforward"/"complex" implementation requests (as opposed to reviews/Q&A) will still fail after this fix, just later in the flow (at push time instead of at token-mint time).

Worth confirming intentional — if this workflow is meant to stay review/answer-only, fine as is; if it's meant to implement and push (per its own trigger prompt), contents needs to be write too.

Fix this →

[MaryWylde]

The job supplied neither github_token nor id-token: write, so claude-code-action fell back to minting a token over OIDC and failed all three attempts with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL".

Use the run's own GITHUB_TOKEN, matching claude-code-review.yml in this repo, which avoids depending on the Claude GitHub App being installed on the org. Comment permissions go read -> write so Claude can post replies.

[github-actions]

Claude finished @MaryWylde's task in 1m 19s —— View job

---

Review: fix(ci): give the @claude mention workflow a usable GitHub token

• Gather context (read diff, compared with claude-code-review.yml)
• Understand the request (review the CI token fix)
• Review correctness/security of workflow change
• Post final review

Summary

The core fix is correct: passing github_token: ${{ secrets.GITHUB_TOKEN }} matches the working pattern in claude-code-review.yml and avoids the OIDC minting path that was failing with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL". Good diagnosis, and the added comments explain the why well for future readers.

The pull-requests/issues permission bump from read → write is correctly scoped — Claude needs to write comments/replies, and this doesn't touch contents, so it doesn't broaden write access to the repo itself.

The existing author_association gating (lines 38–50, unchanged by this PR) is sound and untouched — no regression there.

One thing worth confirming before merge

contents permission (line 56) stays read. That's fine if this workflow is meant to be review/answer-only. But unlike claude-code-review.yml (which never pushes), this mention workflow's own trigger prompt explicitly supports implementation requests and instructs pushing via git-push.sh origin HEAD using this same token. git push with the default GITHUB_TOKEN needs contents: write — with read, implementation-type @claude mentions will still fail, just later (at push time, 403) instead of at token-mint time. Left an inline comment with details.

If the intent is genuinely review/Q&A only for this trigger, this is a non-issue — otherwise contents: write is likely needed too.

[github-actions]

contents stays read here while pull-requests/issues go to write. That's enough for Claude to comment, but this workflow (unlike claude-code-review.yml, which never pushes) is the one that handles implementation requests — the task prompt driving @claude on PRs explicitly instructs pushing via git-push.sh origin HEAD using this same github_token.

git push over the default GITHUB_TOKEN needs contents: write; with contents: read that push will get a 403, so "straightforward"/"complex" implementation requests (as opposed to reviews/Q&A) will still fail after this fix, just later in the flow (at push time instead of at token-mint time).

Worth confirming intentional — if this workflow is meant to stay review/answer-only, fine as is; if it's meant to implement and push (per its own trigger prompt), contents needs to be write too.

Fix this →

[MaryWylde]

The job supplied neither github_token nor id-token: write, so claude-code-action fell back to minting a token over OIDC and failed all three attempts with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL".

Use the run's own GITHUB_TOKEN, matching claude-code-review.yml in this repo, which avoids depending on the Claude GitHub App being installed on the org. Comment permissions go read -> write so Claude can post replies.

[github-actions]

Claude finished @MaryWylde's task in 1m 19s —— View job

---

Review: fix(ci): give the @claude mention workflow a usable GitHub token

• Gather context (read diff, compared with claude-code-review.yml)
• Understand the request (review the CI token fix)
• Review correctness/security of workflow change
• Post final review

Summary

The core fix is correct: passing github_token: ${{ secrets.GITHUB_TOKEN }} matches the working pattern in claude-code-review.yml and avoids the OIDC minting path that was failing with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL". Good diagnosis, and the added comments explain the why well for future readers.

The pull-requests/issues permission bump from read → write is correctly scoped — Claude needs to write comments/replies, and this doesn't touch contents, so it doesn't broaden write access to the repo itself.

The existing author_association gating (lines 38–50, unchanged by this PR) is sound and untouched — no regression there.

One thing worth confirming before merge

contents permission (line 56) stays read. That's fine if this workflow is meant to be review/answer-only. But unlike claude-code-review.yml (which never pushes), this mention workflow's own trigger prompt explicitly supports implementation requests and instructs pushing via git-push.sh origin HEAD using this same token. git push with the default GITHUB_TOKEN needs contents: write — with read, implementation-type @claude mentions will still fail, just later (at push time, 403) instead of at token-mint time. Left an inline comment with details.

If the intent is genuinely review/Q&A only for this trigger, this is a non-issue — otherwise contents: write is likely needed too.

[github-actions]

contents stays read here while pull-requests/issues go to write. That's enough for Claude to comment, but this workflow (unlike claude-code-review.yml, which never pushes) is the one that handles implementation requests — the task prompt driving @claude on PRs explicitly instructs pushing via git-push.sh origin HEAD using this same github_token.

git push over the default GITHUB_TOKEN needs contents: write; with contents: read that push will get a 403, so "straightforward"/"complex" implementation requests (as opposed to reviews/Q&A) will still fail after this fix, just later in the flow (at push time instead of at token-mint time).

Worth confirming intentional — if this workflow is meant to stay review/answer-only, fine as is; if it's meant to implement and push (per its own trigger prompt), contents needs to be write too.

Fix this →

[MaryWylde]

The job supplied neither github_token nor id-token: write, so claude-code-action fell back to minting a token over OIDC and failed all three attempts with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL".

Use the run's own GITHUB_TOKEN, matching claude-code-review.yml in this repo, which avoids depending on the Claude GitHub App being installed on the org. Comment permissions go read -> write so Claude can post replies.

[github-actions]

Claude finished @MaryWylde's task in 1m 19s —— View job

---

Review: fix(ci): give the @claude mention workflow a usable GitHub token

• Gather context (read diff, compared with claude-code-review.yml)
• Understand the request (review the CI token fix)
• Review correctness/security of workflow change
• Post final review

Summary

The core fix is correct: passing github_token: ${{ secrets.GITHUB_TOKEN }} matches the working pattern in claude-code-review.yml and avoids the OIDC minting path that was failing with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL". Good diagnosis, and the added comments explain the why well for future readers.

The pull-requests/issues permission bump from read → write is correctly scoped — Claude needs to write comments/replies, and this doesn't touch contents, so it doesn't broaden write access to the repo itself.

The existing author_association gating (lines 38–50, unchanged by this PR) is sound and untouched — no regression there.

One thing worth confirming before merge

contents permission (line 56) stays read. That's fine if this workflow is meant to be review/answer-only. But unlike claude-code-review.yml (which never pushes), this mention workflow's own trigger prompt explicitly supports implementation requests and instructs pushing via git-push.sh origin HEAD using this same token. git push with the default GITHUB_TOKEN needs contents: write — with read, implementation-type @claude mentions will still fail, just later (at push time, 403) instead of at token-mint time. Left an inline comment with details.

If the intent is genuinely review/Q&A only for this trigger, this is a non-issue — otherwise contents: write is likely needed too.

[github-actions]

contents stays read here while pull-requests/issues go to write. That's enough for Claude to comment, but this workflow (unlike claude-code-review.yml, which never pushes) is the one that handles implementation requests — the task prompt driving @claude on PRs explicitly instructs pushing via git-push.sh origin HEAD using this same github_token.

git push over the default GITHUB_TOKEN needs contents: write; with contents: read that push will get a 403, so "straightforward"/"complex" implementation requests (as opposed to reviews/Q&A) will still fail after this fix, just later in the flow (at push time instead of at token-mint time).

Worth confirming intentional — if this workflow is meant to stay review/answer-only, fine as is; if it's meant to implement and push (per its own trigger prompt), contents needs to be write too.

Fix this →

[MaryWylde]

The job supplied neither github_token nor id-token: write, so claude-code-action fell back to minting a token over OIDC and failed all three attempts with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL".

Use the run's own GITHUB_TOKEN, matching claude-code-review.yml in this repo, which avoids depending on the Claude GitHub App being installed on the org. Comment permissions go read -> write so Claude can post replies.

[github-actions]

Claude finished @MaryWylde's task in 1m 19s —— View job

---

Review: fix(ci): give the @claude mention workflow a usable GitHub token

• Gather context (read diff, compared with claude-code-review.yml)
• Understand the request (review the CI token fix)
• Review correctness/security of workflow change
• Post final review

Summary

The core fix is correct: passing github_token: ${{ secrets.GITHUB_TOKEN }} matches the working pattern in claude-code-review.yml and avoids the OIDC minting path that was failing with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL". Good diagnosis, and the added comments explain the why well for future readers.

The pull-requests/issues permission bump from read → write is correctly scoped — Claude needs to write comments/replies, and this doesn't touch contents, so it doesn't broaden write access to the repo itself.

The existing author_association gating (lines 38–50, unchanged by this PR) is sound and untouched — no regression there.

One thing worth confirming before merge

contents permission (line 56) stays read. That's fine if this workflow is meant to be review/answer-only. But unlike claude-code-review.yml (which never pushes), this mention workflow's own trigger prompt explicitly supports implementation requests and instructs pushing via git-push.sh origin HEAD using this same token. git push with the default GITHUB_TOKEN needs contents: write — with read, implementation-type @claude mentions will still fail, just later (at push time, 403) instead of at token-mint time. Left an inline comment with details.

If the intent is genuinely review/Q&A only for this trigger, this is a non-issue — otherwise contents: write is likely needed too.

[github-actions]

contents stays read here while pull-requests/issues go to write. That's enough for Claude to comment, but this workflow (unlike claude-code-review.yml, which never pushes) is the one that handles implementation requests — the task prompt driving @claude on PRs explicitly instructs pushing via git-push.sh origin HEAD using this same github_token.

git push over the default GITHUB_TOKEN needs contents: write; with contents: read that push will get a 403, so "straightforward"/"complex" implementation requests (as opposed to reviews/Q&A) will still fail after this fix, just later in the flow (at push time instead of at token-mint time).

Worth confirming intentional — if this workflow is meant to stay review/answer-only, fine as is; if it's meant to implement and push (per its own trigger prompt), contents needs to be write too.

Fix this →

[MaryWylde]

The job supplied neither github_token nor id-token: write, so claude-code-action fell back to minting a token over OIDC and failed all three attempts with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL".

Use the run's own GITHUB_TOKEN, matching claude-code-review.yml in this repo, which avoids depending on the Claude GitHub App being installed on the org. Comment permissions go read -> write so Claude can post replies.

[github-actions]

Claude finished @MaryWylde's task in 1m 19s —— View job

---

Review: fix(ci): give the @claude mention workflow a usable GitHub token

• Gather context (read diff, compared with claude-code-review.yml)
• Understand the request (review the CI token fix)
• Review correctness/security of workflow change
• Post final review

Summary

The core fix is correct: passing github_token: ${{ secrets.GITHUB_TOKEN }} matches the working pattern in claude-code-review.yml and avoids the OIDC minting path that was failing with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL". Good diagnosis, and the added comments explain the why well for future readers.

The pull-requests/issues permission bump from read → write is correctly scoped — Claude needs to write comments/replies, and this doesn't touch contents, so it doesn't broaden write access to the repo itself.

The existing author_association gating (lines 38–50, unchanged by this PR) is sound and untouched — no regression there.

One thing worth confirming before merge

contents permission (line 56) stays read. That's fine if this workflow is meant to be review/answer-only. But unlike claude-code-review.yml (which never pushes), this mention workflow's own trigger prompt explicitly supports implementation requests and instructs pushing via git-push.sh origin HEAD using this same token. git push with the default GITHUB_TOKEN needs contents: write — with read, implementation-type @claude mentions will still fail, just later (at push time, 403) instead of at token-mint time. Left an inline comment with details.

If the intent is genuinely review/Q&A only for this trigger, this is a non-issue — otherwise contents: write is likely needed too.

[github-actions]

contents stays read here while pull-requests/issues go to write. That's enough for Claude to comment, but this workflow (unlike claude-code-review.yml, which never pushes) is the one that handles implementation requests — the task prompt driving @claude on PRs explicitly instructs pushing via git-push.sh origin HEAD using this same github_token.

git push over the default GITHUB_TOKEN needs contents: write; with contents: read that push will get a 403, so "straightforward"/"complex" implementation requests (as opposed to reviews/Q&A) will still fail after this fix, just later in the flow (at push time instead of at token-mint time).

Worth confirming intentional — if this workflow is meant to stay review/answer-only, fine as is; if it's meant to implement and push (per its own trigger prompt), contents needs to be write too.

Fix this →

[MaryWylde]

The job supplied neither github_token nor id-token: write, so claude-code-action fell back to minting a token over OIDC and failed all three attempts with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL".

Use the run's own GITHUB_TOKEN, matching claude-code-review.yml in this repo, which avoids depending on the Claude GitHub App being installed on the org. Comment permissions go read -> write so Claude can post replies.

[github-actions]

Claude finished @MaryWylde's task in 1m 19s —— View job

---

Review: fix(ci): give the @claude mention workflow a usable GitHub token

• Gather context (read diff, compared with claude-code-review.yml)
• Understand the request (review the CI token fix)
• Review correctness/security of workflow change
• Post final review

Summary

The core fix is correct: passing github_token: ${{ secrets.GITHUB_TOKEN }} matches the working pattern in claude-code-review.yml and avoids the OIDC minting path that was failing with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL". Good diagnosis, and the added comments explain the why well for future readers.

The pull-requests/issues permission bump from read → write is correctly scoped — Claude needs to write comments/replies, and this doesn't touch contents, so it doesn't broaden write access to the repo itself.

The existing author_association gating (lines 38–50, unchanged by this PR) is sound and untouched — no regression there.

One thing worth confirming before merge

contents permission (line 56) stays read. That's fine if this workflow is meant to be review/answer-only. But unlike claude-code-review.yml (which never pushes), this mention workflow's own trigger prompt explicitly supports implementation requests and instructs pushing via git-push.sh origin HEAD using this same token. git push with the default GITHUB_TOKEN needs contents: write — with read, implementation-type @claude mentions will still fail, just later (at push time, 403) instead of at token-mint time. Left an inline comment with details.

If the intent is genuinely review/Q&A only for this trigger, this is a non-issue — otherwise contents: write is likely needed too.

[github-actions]

contents stays read here while pull-requests/issues go to write. That's enough for Claude to comment, but this workflow (unlike claude-code-review.yml, which never pushes) is the one that handles implementation requests — the task prompt driving @claude on PRs explicitly instructs pushing via git-push.sh origin HEAD using this same github_token.

git push over the default GITHUB_TOKEN needs contents: write; with contents: read that push will get a 403, so "straightforward"/"complex" implementation requests (as opposed to reviews/Q&A) will still fail after this fix, just later in the flow (at push time instead of at token-mint time).

Worth confirming intentional — if this workflow is meant to stay review/answer-only, fine as is; if it's meant to implement and push (per its own trigger prompt), contents needs to be write too.

Fix this →

[MaryWylde]

The job supplied neither github_token nor id-token: write, so claude-code-action fell back to minting a token over OIDC and failed all three attempts with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL".

Use the run's own GITHUB_TOKEN, matching claude-code-review.yml in this repo, which avoids depending on the Claude GitHub App being installed on the org. Comment permissions go read -> write so Claude can post replies.

[github-actions]

Claude finished @MaryWylde's task in 1m 19s —— View job

---

Review: fix(ci): give the @claude mention workflow a usable GitHub token

• Gather context (read diff, compared with claude-code-review.yml)
• Understand the request (review the CI token fix)
• Review correctness/security of workflow change
• Post final review

Summary

The core fix is correct: passing github_token: ${{ secrets.GITHUB_TOKEN }} matches the working pattern in claude-code-review.yml and avoids the OIDC minting path that was failing with "Unable to get ACTIONS_ID_TOKEN_REQUEST_URL". Good diagnosis, and the added comments explain the why well for future readers.

The pull-requests/issues permission bump from read → write is correctly scoped — Claude needs to write comments/replies, and this doesn't touch contents, so it doesn't broaden write access to the repo itself.

The existing author_association gating (lines 38–50, unchanged by this PR) is sound and untouched — no regression there.

One thing worth confirming before merge

contents permission (line 56) stays read. That's fine if this workflow is meant to be review/answer-only. But unlike claude-code-review.yml (which never pushes), this mention workflow's own trigger prompt explicitly supports implementation requests and instructs pushing via git-push.sh origin HEAD using this same token. git push with the default GITHUB_TOKEN needs contents: write — with read, implementation-type @claude mentions will still fail, just later (at push time, 403) instead of at token-mint time. Left an inline comment with details.

If the intent is genuinely review/Q&A only for this trigger, this is a non-issue — otherwise contents: write is likely needed too.

[github-actions]

contents stays read here while pull-requests/issues go to write. That's enough for Claude to comment, but this workflow (unlike claude-code-review.yml, which never pushes) is the one that handles implementation requests — the task prompt driving @claude on PRs explicitly instructs pushing via git-push.sh origin HEAD using this same github_token.

git push over the default GITHUB_TOKEN needs contents: write; with contents: read that push will get a 403, so "straightforward"/"complex" implementation requests (as opposed to reviews/Q&A) will still fail after this fix, just later in the flow (at push time instead of at token-mint time).

Worth confirming intentional — if this workflow is meant to stay review/answer-only, fine as is; if it's meant to implement and push (per its own trigger prompt), contents needs to be write too.

Fix this →