Problem
GitHub workflows prefer connector mutations even when that connector cannot write to the target repository.
The attempt then fails with 403 Resource not accessible by integration. The workflow retries through the authenticated gh session and succeeds.
This is a repeated, predictable failure. It adds latency, creates misleading failure output, and asks the connector to perform an operation it cannot authorize.
Recent occurrences include creating PR #804 and posting its required suppressed-finding responses. The authenticated gh session and repository context were already verified.
The same repository-level denial affects pull request creation, issue creation, PR conversation comments, review responses, labels, reactions, and similar writes.
Desired Behavior
Route directly to authenticated gh when repository write access through the connector is known to be unavailable.
Keep connector-first behavior for reads and for repositories where connector write access is available or unknown and cheaply discoverable.
Do not require a failed mutation as the capability probe when a read-only permission check or established session evidence can decide the route.
Apply one repository-level capability decision consistently across publication and review-follow-up workflows.
Scope
- Define a connector write-capability preflight for pull requests, issues, comments, review responses, labels, reactions, and related mutations.
- Reuse a connector authorization failure for later writes to the same repository during the session.
- Share the capability result across publication and review-follow-up skills.
- Route directly to authenticated
gh after the preflight or cached result shows insufficient connector access. - Preserve the existing identity, repository, branch, target, and draft-state verification before each fallback write.
- Report the selected route without presenting an expected authorization limitation as a task failure.
Acceptance Criteria
- Workflows do not attempt connector mutations when insufficient repository write access is already known.
- A read-only preflight can select
gh without creating or changing GitHub state. - One repository-level denial prevents repeated connector attempts for later write types in the session.
- Authenticated
gh fallbacks create the same intended pull request, issue, comment, response, label, or reaction. - Suppressed-finding responses use the selected route without an initial failed connector call.
- Connector reads remain preferred where they are supported.
- Tests cover known-denied, preflight-denied, connector-authorized, unavailable-
gh, and cross-workflow reuse cases.
Problem
GitHub workflows prefer connector mutations even when that connector cannot write to the target repository.
The attempt then fails with
403 Resource not accessible by integration. The workflow retries through the authenticatedghsession and succeeds.This is a repeated, predictable failure. It adds latency, creates misleading failure output, and asks the connector to perform an operation it cannot authorize.
Recent occurrences include creating PR #804 and posting its required suppressed-finding responses. The authenticated
ghsession and repository context were already verified.The same repository-level denial affects pull request creation, issue creation, PR conversation comments, review responses, labels, reactions, and similar writes.
Desired Behavior
Route directly to authenticated
ghwhen repository write access through the connector is known to be unavailable.Keep connector-first behavior for reads and for repositories where connector write access is available or unknown and cheaply discoverable.
Do not require a failed mutation as the capability probe when a read-only permission check or established session evidence can decide the route.
Apply one repository-level capability decision consistently across publication and review-follow-up workflows.
Scope
ghafter the preflight or cached result shows insufficient connector access.Acceptance Criteria
ghwithout creating or changing GitHub state.ghfallbacks create the same intended pull request, issue, comment, response, label, or reaction.gh, and cross-workflow reuse cases.