Repository navigation
[bug] GitHub App installation tokens (ghs_) are rejected by the credential preflight #1661
Description
Describe the bug
Sourcebot recognises GitHub App installation tokens as a supported token type —
GitHubTokenType declares 'app_installation' and detectGitHubTokenType() returns it
for the ghs_ prefix (packages/backend/src/github.ts:26,43), with a unit test asserting
exactly that.
However, a connector configured with one fails before listing a single repository.
getGitHubReposFromConfig validates the credential with GET /user (github.ts:185) and
rethrows on failure. An installation token authenticates as an installation, not a user,
so GitHub answers:
403 "Resource not accessible by integration"
No permission grant can satisfy this, because there is no user to return. The check also
cannot be skipped: its guard is isAuthenticated: !!token (github.ts:115), so the only
way to avoid it is to configure no token at all — which limits indexing to public
repositories.
Expected: a connector configured with an installation token indexes normally.
Actual: repository discovery aborts with a 403 at the preflight.
The inconsistency is the bug: every other GitHub path already handles installation
tokens correctly. getRepoAuth builds x-access-token: <token> git credentials from one
(utils.ts:163-177), which is precisely the documented form for installation tokens, and
repos.listForOrg accepts one. Only the preflight rejects it.
Note - The credential is simply an installation token supplied as an ordinary
connector token.
To reproduce
- Register a GitHub App, install it on an organisation, grant
Contents: readand
Metadata: read. - Mint an installation token:
POST /app/installations/{installation_id}/access_tokens(returns aghs_…token). - Configure a GitHub connector with that token and an
orgsentry:{ "type": "github", "token": { "env": "GITHUB_TOKEN" }, "orgs": ["my-org"] } - Start Sourcebot and trigger a connection sync.
Result: sync fails immediately. Logs show Failed to authenticate with GitHub and a 403
Resource not accessible by integration. Zero repositories are discovered.
Substituting a personal access token for the same organisation works, which isolates the
failure to the token type rather than to permissions or configuration.
Sourcebot deployment information
Sourcebot version (e.g. v3.0.1): v5.1.12 (docker.sourcebot.dev/sourcebot-dev/sourcebot),
also reproduced against main at the time of writing.
Additional information
Two further user-context calls exist in the same file and will fail the same way for the
same reason, though only when users: is configured rather than orgs::
repos.listForAuthenticatedUser→GET /user/repos(github.ts:251)rest.search.repos→GET /search/repositories?q=user:…(github.ts:322)
A fix for the preflight is proposed in the linked pull request. Happy to extend it to
those two paths if you would prefer them handled in the same change.
Activity
simmi-tdh commentedon Sep 16, 2026
the fix is proposed in #1662, which carries the full description and reproduction.
brendan-kellam commentedon Oct 9, 2026
Thanks for the detailed write-up.
You're right that GET /user rejects installation tokens. However, installation tokens expire after an hour and can't be rotated through a connection's token field, so we don't support them there. If you want to authenticate as a GitHub App, use Sourcebot's built-in GitHub App integration, which creates and refreshes installation tokens automatically. Closing this one for now.