You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix the add_comment credential path in PR Sous Chef — it is 0-for-3 on PR #48593 in the last 68 minutes, and it fails only after a different write (update_pull_request / dismiss_pull_request_review) already succeeded against the same PR moments earlier.
Affected workflow / runs
Workflow: .github/workflows/pr-sous-chef.lock.yml ("PR Sous Chef")
§30384256680 — 2026-07-28T17:54:26Z — add_comment failed 401 (request id 1340:1AEE4B:72FE2D:186887D:6A68ECD1)
§30386933161 — 2026-07-28T18:26:44Z — add_comment failed 401 (request id 20C3:33FC32:A056B5:220844C:6A68F464)
§30389499577 — 2026-07-28T19:02:45Z — add_comment failed 401 (request id 1C28:2ABB8:EA167:3221C5:6A68FCD5)
Evidence
All three runs show the identical shape:
POST /repos/github/gh-aw/issues/48593/comments - 401 with id <req-id> in ~40-65ms
##[error]Failed to add comment: Bad credentials - https://docs.github.com/rest
In all three runs, a different safe output writing to the same PR (either update_pull_request or dismiss_pull_request_review) completed successfully in the same job execution, immediately before or after the failing add_comment call. This rules out a blanket token-revocation or repo-permission problem — the failure is specific to the add_comment code path/endpoint (issues/{n}/comments), not to authentication in general for this job.
Probable root cause
The add_comment handler likely mints or caches a GitHub App installation token separately from the other safe-output handlers (e.g., a stale/short-lived token reused across a multi-message batch, or a token scoped without issues:write while pull_requests:write is granted). A 401 (not 403) specifically points to an invalid/expired credential rather than a permissions/policy denial — distinguish this from the already-tracked #47753 (branch-from-base rejected by verified-signatures rule, a 422/permission-shaped failure) and #47659 (resolve_pull_request_review_thread failing) which are different safe-output code paths with different error shapes.
Proposed remediation
Audit the safe-outputs processor's token acquisition for add_comment vs. update_pull_request/dismiss_pull_request_review — confirm whether they use the same cached installation token instance or independently mint one.
If tokens are cached across the batch, verify freshness/expiry is checked before each API call, not just once at job start.
Add a retry-with-fresh-token on 401 for add_comment (matching the retry-exempt-status-codes config already present: 400,401,403,404,422 — note 401 is currently in the no-retry list, which may be masking a legitimately transient token-refresh case; confirm this is intentional).
Add a regression test that runs add_comment after another mutating safe output in the same batch against the same target PR.
Success criteria
PR Sous Chef's add_comment step succeeds when run in the same batch as update_pull_request/dismiss_pull_request_review against the same PR, across at least 3 consecutive scheduled runs.
Fix the add_comment credential path in PR Sous Chef — it is 0-for-3 on PR #48593 in the last 68 minutes, and it fails only after a different write (update_pull_request / dismiss_pull_request_review) already succeeded against the same PR moments earlier.
Affected workflow / runs
Workflow: .github/workflows/pr-sous-chef.lock.yml ("PR Sous Chef")
§30384256680 — 2026-07-28T17:54:26Z — add_comment failed 401 (request id 1340:1AEE4B:72FE2D:186887D:6A68ECD1)
§30386933161 — 2026-07-28T18:26:44Z — add_comment failed 401 (request id 20C3:33FC32:A056B5:220844C:6A68F464)
§30389499577 — 2026-07-28T19:02:45Z — add_comment failed 401 (request id 1C28:2ABB8:EA167:3221C5:6A68FCD5)
Evidence
All three runs show the identical shape:
POST /repos/github/gh-aw/issues/48593/comments - 401 with id <req-id> in ~40-65ms
##[error]Failed to add comment: Bad credentials - https://docs.github.com/rest
In all three runs, a different safe output writing to the same PR (either update_pull_request or dismiss_pull_request_review) completed successfully in the same job execution, immediately before or after the failing add_comment call. This rules out a blanket token-revocation or repo-permission problem — the failure is specific to the add_comment code path/endpoint (issues/{n}/comments), not to authentication in general for this job.
Update — still failing 2+ hours after filing (2026-07-28, later same day)
Not fixed. Two more add_comment 401 failures hit the identical safe_outputs → "Process Safe Outputs" code path, well after this issue was opened:
§30400044871 — 2026-07-28T21:17:26Z — Process Safe Outputs failed: Failed to add comment: Bad credentials
§30401927723 — 2026-07-28T21:45:07Z — Process Safe Outputs failed: Failed to add comment: Bad credentials (agent turn count 144 — high, but the failure is the same credential error, not a new symptom)
Fix priority stands at P1 — this is now confirmed recurring across 5 runs over ~4 hours, not a one-off. Prioritize the token-freshness check in proposed remediation step 2 first; it's the most likely culprit given the failure keeps recurring hours after the initial report.
Probable root cause
The add_comment handler likely mints or caches a GitHub App installation token separately from the other safe-output handlers (e.g., a stale/short-lived token reused across a multi-message batch, or a token scoped without issues:write while pull_requests:write is granted). A 401 (not 403) specifically points to an invalid/expired credential rather than a permissions/policy denial — distinguish this from the already-tracked #47753 (branch-from-base rejected by verified-signatures rule, a 422/permission-shaped failure) and #47659 (resolve_pull_request_review_thread failing) which are different safe-output code paths with different error shapes.
Proposed remediation
Audit the safe-outputs processor's token acquisition for add_comment vs. update_pull_request/dismiss_pull_request_review — confirm whether they use the same cached installation token instance or independently mint one.
If tokens are cached across the batch, verify freshness/expiry is checked before each API call, not just once at job start.
Add a retry-with-fresh-token on 401 for add_comment (matching the retry-exempt-status-codes config already present: 400,401,403,404,422 — note 401 is currently in the no-retry list, which may be masking a legitimately transient token-refresh case; confirm this is intentional).
Add a regression test that runs add_comment after another mutating safe output in the same batch against the same target PR.
Success criteria
PR Sous Chef's add_comment step succeeds when run in the same batch as update_pull_request/dismiss_pull_request_review against the same PR, across at least 3 consecutive scheduled runs.
Problem
Fix the add_comment credential path in PR Sous Chef — it is 0-for-3 on PR #48593 in the last 68 minutes, and it fails only after a different write (update_pull_request / dismiss_pull_request_review) already succeeded against the same PR moments earlier.
Affected workflow / runs
.github/workflows/pr-sous-chef.lock.yml("PR Sous Chef")safe_outputs→ step "Process Safe Outputs" (agent job itself succeeds every time)add_commentfailed 401 (request id1340:1AEE4B:72FE2D:186887D:6A68ECD1)add_commentfailed 401 (request id20C3:33FC32:A056B5:220844C:6A68F464)add_commentfailed 401 (request id1C28:2ABB8:EA167:3221C5:6A68FCD5)Evidence
All three runs show the identical shape:
In all three runs, a different safe output writing to the same PR (either
update_pull_requestordismiss_pull_request_review) completed successfully in the same job execution, immediately before or after the failingadd_commentcall. This rules out a blanket token-revocation or repo-permission problem — the failure is specific to theadd_commentcode path/endpoint (issues/{n}/comments), not to authentication in general for this job.Probable root cause
The
add_commenthandler likely mints or caches a GitHub App installation token separately from the other safe-output handlers (e.g., a stale/short-lived token reused across a multi-message batch, or a token scoped withoutissues:writewhilepull_requests:writeis granted). A 401 (not 403) specifically points to an invalid/expired credential rather than a permissions/policy denial — distinguish this from the already-tracked #47753 (branch-from-base rejected by verified-signatures rule, a 422/permission-shaped failure) and #47659 (resolve_pull_request_review_thread failing) which are different safe-output code paths with different error shapes.Proposed remediation
add_commentvs.update_pull_request/dismiss_pull_request_review— confirm whether they use the same cached installation token instance or independently mint one.add_comment(matching the retry-exempt-status-codes config already present:400,401,403,404,422— note 401 is currently in the no-retry list, which may be masking a legitimately transient token-refresh case; confirm this is intentional).add_commentafter another mutating safe output in the same batch against the same target PR.Success criteria
add_commentstep succeeds when run in the same batch asupdate_pull_request/dismiss_pull_request_reviewagainst the same PR, across at least 3 consecutive scheduled runs.add_commentinsafe_outputsjob logs for PR Sous Chef.Related to [aw-failures] [aw] Failure Investigator (6h) - Issue Group #46171
Problem
Fix the add_comment credential path in PR Sous Chef — it is 0-for-3 on PR #48593 in the last 68 minutes, and it fails only after a different write (update_pull_request / dismiss_pull_request_review) already succeeded against the same PR moments earlier.
Affected workflow / runs
.github/workflows/pr-sous-chef.lock.yml("PR Sous Chef")safe_outputs→ step "Process Safe Outputs" (agent job itself succeeds every time)add_commentfailed 401 (request id1340:1AEE4B:72FE2D:186887D:6A68ECD1)add_commentfailed 401 (request id20C3:33FC32:A056B5:220844C:6A68F464)add_commentfailed 401 (request id1C28:2ABB8:EA167:3221C5:6A68FCD5)Evidence
All three runs show the identical shape:
In all three runs, a different safe output writing to the same PR (either
update_pull_requestordismiss_pull_request_review) completed successfully in the same job execution, immediately before or after the failingadd_commentcall. This rules out a blanket token-revocation or repo-permission problem — the failure is specific to theadd_commentcode path/endpoint (issues/{n}/comments), not to authentication in general for this job.Update — still failing 2+ hours after filing (2026-07-28, later same day)
Not fixed. Two more
add_comment401 failures hit the identicalsafe_outputs→ "Process Safe Outputs" code path, well after this issue was opened:Process Safe Outputsfailed:Failed to add comment: Bad credentialsProcess Safe Outputsfailed:Failed to add comment: Bad credentials(agent turn count 144 — high, but the failure is the same credential error, not a new symptom)Fix priority stands at P1 — this is now confirmed recurring across 5 runs over ~4 hours, not a one-off. Prioritize the token-freshness check in proposed remediation step 2 first; it's the most likely culprit given the failure keeps recurring hours after the initial report.
Probable root cause
The
add_commenthandler likely mints or caches a GitHub App installation token separately from the other safe-output handlers (e.g., a stale/short-lived token reused across a multi-message batch, or a token scoped withoutissues:writewhilepull_requests:writeis granted). A 401 (not 403) specifically points to an invalid/expired credential rather than a permissions/policy denial — distinguish this from the already-tracked #47753 (branch-from-base rejected by verified-signatures rule, a 422/permission-shaped failure) and #47659 (resolve_pull_request_review_thread failing) which are different safe-output code paths with different error shapes.Proposed remediation
add_commentvs.update_pull_request/dismiss_pull_request_review— confirm whether they use the same cached installation token instance or independently mint one.add_comment(matching the retry-exempt-status-codes config already present:400,401,403,404,422— note 401 is currently in the no-retry list, which may be masking a legitimately transient token-refresh case; confirm this is intentional).add_commentafter another mutating safe output in the same batch against the same target PR.Success criteria
add_commentstep succeeds when run in the same batch asupdate_pull_request/dismiss_pull_request_reviewagainst the same PR, across at least 3 consecutive scheduled runs.add_commentinsafe_outputsjob logs for PR Sous Chef.Related to [aw-failures] [aw] Failure Investigator (6h) - Issue Group #46171