Why does my GitHub agent get 404 or resource not accessible errors?

Your agent can authenticate, list something, and still fail to open the issue it needs. A more insistent prompt does not change the route, repository selection, or token permission.

One GitHub community question about issue API failures was resolved by correcting /orgs to /repos in the request path. Another asks about triggering a workflow in a different repository. Similar errors hide different causes, so diagnose the exact operation before expanding access.

Why does the API return 404 when I can see the repository?#

GitHub's REST troubleshooting guide explains that an improperly authenticated request for a private resource returns 404. Browser visibility does not prove the agent's credential can reach the same resource.

First verify the HTTP method, endpoint path, owner, repository, and object identifier, as in the route mistake above. Then check the identity and repository selection of the credential the agent uses.

Keep a sanitized failing request and response, with the request ID and relevant headers, and never print the bearer token. Try a minimal read with the same credential path; a read of the exact target repository proves more than a request to an unrelated endpoint.

What does resource not accessible by integration mean?#

This points to a token that lacks the permission the operation requires. GitHub's troubleshooting guide says to inspect endpoint permissions and the accepted-permissions response information.

Map each action to its own permission: reading metadata, listing issues, creating an issue, and updating a workflow are distinct operations, and a successful metadata call says nothing about write permission.

Your agent adapter should return the failed operation and target. "Access denied" tells the operator less than "the connection could read the repository but could not create an issue here," which lets the operator decide whether to allow the write. Never substitute a broader personal credential to make the error disappear.

Can GITHUB_TOKEN access another repository?#

A GitHub Actions job's default token is scoped to the workflow's own repository. GitHub's token authentication guide describes using a GitHub App or other credential when the workflow needs more. Raising the job's permission level does not grant access to a second repository, as in the cross-repository question above.

For an agent that prepares a change across repositories:

• Make the repository list explicit and choose a connection authorized for that list.
• Keep source repository, target repository, installation, and operation together.
• Test the allowed target and a different private repository; failure on the latter is the correct result.

Why does one repository operation work while another fails with the same token?#

These operations have different permission and identity requirements. A template-repository discussion describes creating a normal repository successfully while failing to create from a template. Use such reports to identify the question, then consult the endpoint reference for your operation.

Do not infer write permission from a read, or acting for another user from acting as the token's owner. Check whether the GitHub App installation includes the relevant repository and whether a changed permission has been accepted.

Keep an investigation table with one row per operation: method, route, credential identity, required permission, target, and result. It shows whether the failure follows the endpoint, repository, or connection, which beats "the GitHub integration is broken."

How do I distinguish a permission failure from a rate limit?#

Inspect the response headers and body. GitHub documents rate-limit responses separately from insufficient access, and a 403 alone does not give the recovery strategy; the rate-limit information and retry guidance do. Classify the failure in your adapter before allowing another attempt:

• A rate-limited read needs the documented wait and a capped retry policy.
• A denied operation needs corrected access or a different authorized task.
• An invalid route needs a code correction.

An uncontrolled loop solves none of these.

Once access works, preserve the result so the next task skips the investigation. The GitHub connector guide lists the operations, and the GitHub agent workflow shows how to retain issue, revision, and fix references.

More symptoms: the agent troubleshooting question index.