Git integration can't mint an installation access token — namespace stuck at isAccessRestricted: true, zero repos visible
Posting this with the actual API responses, since most threads on this only get as far as "reconnect the repo" and that doesn't touch it.
Symptoms Pushes to main produce no deployment at all — nothing in the Deployments list, not even a skipped or errored entry. Creating a Deploy Hook in the dashboard fails with Branch "main" not found in the connected Git repository. vercel --prod from the CLI deploys perfectly, so the project, build settings and root directory are all fine. Nothing was changed on either side when it stopped.
What the API actually returns The project's Git link looks completely correct — right repo, right org, matching repo id, productionBranch: "main", and a gitCredentialId present.
But asking Vercel to list the repo's branches (the same call the Deploy Hook UI makes) returns: { "error": { "code": "github_response_error", "message": "GitHub fetch error - status: 404, message: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/reference/apps#create-an-installation-access-token-for-an-app"}", "upstream": { "provider": "github", "status": 404 } } } So Vercel is failing to mint an installation access token for the GitHub App installation.
Checking the account's Git namespaces: [ { "provider": "github", "slug": "", "installationId": , "isAccessRestricted": true, "ownerType": "user" } ] And searching repositories returns nothing at all:
{ "gitAccount": { "provider": "github", "namespaceId": null }, "repos": [] } Zero repositories visible, and namespaceId is null.
Verified on the GitHub side - all correct Checked with an authenticated GitHub API token for the repo owner:
- The repo exists, is private, default_branch is main, and its repo id matches exactly what Vercel has stored.
- main exists and is at the expected commit.
- Owner has admin on the repo.
- The Vercel GitHub App is installed, scoped to "Only select repositories", with this repo selected.
- The installation id shown at github.com/settings/installations/ matches the id Vercel holds.
- The installation is not suspended — no suspension banner, no unsuspend button.
- There are zero classic webhooks on the repo, which is expected for the GitHub App integration (worth flagging, because the usual advice is "check Settings → Webhooks → Recent Deliveries", and with the App integration there is no classic webhook there to check).
Things I tried that did not help
- Disconnected and reconnected the repository in Project Settings → Git.
- Uninstalled the Vercel GitHub App entirely, then reinstalled it through Vercel's connect flow, selecting only this repo.
- Re-verified the installation's repository access after reinstalling.
- Logged out of Vercel completely and logged back in with "Continue with GitHub" to force re-authorization. After every one of those, isAccessRestricted stayed true and repo search still returned zero repositories.
Two answers that usually come up - both already ruled out "Check Settings → Webhooks → Recent Deliveries." There is no classic webhook to check. The GitHub App integration doesn't create one, and this repo has zero. That advice applies to the old integration, not this one.
"Your git commit author email doesn't match your GitHub/Vercel account." This is the fix that resolved this thread, so I checked it carefully. My commit author email matches my Vercel account email, and GitHub resolves those commits to my user account — querying the commit via the GitHub API returns a populated author object whose id matches the repoOwnerId Vercel has stored for the repo. So attribution is correct and this isn't it.
This looks like it's recurring Same symptoms, all currently unresolved:
- GitHub push not triggering deployments + 500 error on manual redeploy (Hobby plan) — 1 Sept 2026, no replies
- GitHub webhook not being created despite successful connection
- Auto-deploys broken — Deploy Hooks return PENDING jobs that never build
- Vercel auto-deployments failing due to missing GitHub webhooks despite active integration I haven't seen the installation-token 404 or isAccessRestricted: true posted in any of them, so hopefully this adds the missing piece.
What I think is going on Vercel holds a credential for an installation it can no longer mint a token against. Because the installation demonstrably exists, is correctly scoped, and isn't suspended, it looks like the stored credential or the account-to-installation mapping has gone stale server-side — and none of the self-serve reconnect or re-authorization flows reset it.
Question Has anyone found something that actually clears this state, short of support intervention? Specifically interested in whether creating a brand new project against the same repo re-mints the credential, or whether the restriction is account-level and follows you.
Workaround for anyone else stuck here Deploy Hooks are no use in this state (the branch can't be resolved to create one). What does work is deploying from the CLI, and if you want it back on autopilot you can put it in a pre-push git hook so a normal git push still ships. Wait until the pushed commit is confirmed on the remote before deploying, so a rejected push can't publish code that never landed:
#!/bin/bash
.githooks/pre-push (enable with: git config core.hooksPath .githooks)
while read -r local_ref local_sha remote_ref remote_sha; do case "$remote_ref" in */main) ;; *) continue ;; esac [ "$local_sha" = "0000000000000000000000000000000000000000" ] && continue ( for _ in $(seq 1 30); do sleep 2 if [ "$(git ls-remote "$1" main | awk '{print $1}')" = "$local_sha" ]; then vercel --prod --yes > /tmp/vercel-autodeploy.log 2>&1 exit 0 fi done ) /dev/null 2>&1 & done exit 0
