Claude.ai is facing an issue accessing a private github repo, the connector can see only public repos but not private, whats the solution to get claude to access it read only? claude code works fine and has full access
Hmm… apparently this happens more often than I expected, and it doesn’t seem to have a single cause:
The short version is: yes, Claude.ai’s GitHub integration is supposed to support private repositories. Anthropic’s current GitHub integration documentation explicitly describes granting the Claude GitHub App access to either all repositories or selected private repositories.
So I would not start from “private repos are unsupported.” I would start by checking which layer is actually failing:
GitHub App installed on the correct GitHub account/org
↓
the private repo is included in that installation
↓
if organization-owned: SSO / admin / enterprise approval
↓
if all of that is correct:
Claude-side repository enumeration / connector state
The fact that Claude Code works with the repo is useful, because it shows the repository is reachable through at least one Claude/GitHub path. But I would not take that as proof that the Claude.ai GitHub connector is healthy — the web integration has its own GitHub App / connector state.
The first thing I would check
On the GitHub side, open the installed Claude GitHub App and verify that it is installed on the account or organization that actually owns the private repository, and that the repository is included under its repository access.
GitHub distinguishes authorizing a GitHub App from installing it. Installation is where the app gets access to repository resources and where you choose which repositories it may access; authorization is the user-side relationship that lets the app identify you and, where applicable, act on your behalf. GitHub explicitly notes that an app can be authorized without being installed, or installed without being authorized: Authorizing GitHub Apps.
So a UI saying “Connected” is useful information, but it does not by itself prove:
Connected
=
correct GitHub App installation
+
correct repository scope
+
correct org/SSO authorization
+
healthy Claude-side repository enumeration
If the repo is already explicitly selected there, I would move on rather than repeatedly reconnecting it.
One important caveat about “read only”
There are actually two different meanings of “read only” here:
- “I only want to use Claude.ai to read/analyze the repository.”
- “I do not want to grant the GitHub App any write permission at all.”
For (1), the Claude.ai Chat/Projects integration is quite read-oriented. Anthropic says that this integration syncs only the selected branch’s file names and file contents, not commit history, pull requests, or other metadata: What information is retrieved from GitHub?.
For (2), however, there is an important distinction: limiting the app to one repository is not the same thing as making the app’s GitHub permissions read-only.
Anthropic’s current documentation for the official Claude GitHub App says that the app is shared across Claude features that integrate with GitHub and currently has a broader permission set, including read/write access to Contents, Issues, Pull Requests, Actions, Checks, Discussions, Repository hooks, and Workflows. Anthropic also notes that GitHub does not let an installer accept only a subset of that app’s requested permission set: Claude GitHub App permissions.
So if by “read only” you mean strictly no GitHub write permission granted to Claude at all, I would treat that as a separate security requirement rather than assuming that “Only select repositories” makes the official app read-only.
You can substantially reduce exposure by granting the official app access only to the one repository you want Claude to see.
If the repository belongs to a GitHub organization: check SSO/admin approval too
There is a particularly easy-to-miss organization-specific branch.
Anthropic now documents the exact case where:
- GitHub shows as connected in Claude,
- public repositories work,
- but private repositories from a particular organization do not appear.
If the organization requires SSO, each user may need to separately authorize the Claude app for that organization. Until that happens, GitHub can filter the organization’s private repositories out of the repository list even though the general GitHub connection is otherwise working.
Anthropic’s documented path is under the Claude entry in GitHub’s Applications settings:
- Grant if you are allowed to authorize it yourself.
- Request if an organization administrator must approve it.
Importantly, Anthropic specifically says that disconnecting and reconnecting GitHub in Claude does not fix this SSO state. A new Claude connection does not automatically authorize an SSO-protected organization.
See:
- Claude: Repositories from an organization don’t appear after connecting
- GitHub: SAML and GitHub Apps
GitHub’s own documentation explains why: for an SSO-protected organization, you may need an active SSO session when authorizing/installing/requesting the GitHub App. If the app was authorized without the required SSO state, organization resources may be absent from its repository list.
If this is GitHub Enterprise Cloud with Enterprise Managed Users (EMU), Anthropic also notes that enterprise-level approval can be required.
So for an organization-owned repo I would think of it approximately as:
Claude connection
↓
GitHub App installation
↓
repo included in installation
↓
organization approval
↓
SSO authorization
↓
possibly enterprise approval (EMU)
If all GitHub-side permissions already look correct: there are several similar Claude-side reports
This is the part that made me hesitate to call it simply a permissions mistake.
There are multiple reports with roughly the same boundary condition: GitHub appears to grant the repository correctly, but Claude web/Projects still does not enumerate or access it. These reports do not prove that your case has the same root cause, but they are useful comparisons.
1. Personal repositories missing while organization repositories work
That report says:
- the Claude GitHub App was installed;
- both “all repositories” and selected-repository access had been tried;
- GitHub showed the app as configured;
- organization repositories appeared correctly;
- personal repositories did not appear;
- pasting a private repository URL directly produced
Claude cannot access that resource.
That issue is still open as of this writing and is labeled bug, external, and has repro.
The reporter describes it as a backend indexing problem, but I would treat that root-cause explanation as the reporter’s hypothesis, not as an Anthropic-confirmed diagnosis. The useful part is the observed symptom: correct-looking GitHub grants and an incorrect Claude repository list.
2. Claude.ai Projects rejects a private personal repo even after granting it
This one is especially close to the Claude.ai Projects path:
Project → Add from GitHub;- private personal repository;
- tried
All repositories; - tried
Only select repositorieswith the repo explicitly selected; - Claude still returned
Claude cannot access that resource.
The issue is now closed as “not planned,” but the tracker label is essentially “this is not a Claude Code issue”. In other words, I would not read that closure as evidence that the reported Claude.ai behavior was disproven; it was filed in the anthropics/claude-code tracker even though the report itself explicitly concerns claude.ai Projects.
3. “Connected” but the session has no GitHub tools at all
#47535 — GitHub integration connected but no GitHub tools; private repo access fails
This is a somewhat different failure mode.
The reporter had:
- GitHub Integration =
Connected; - Claude GitHub App installed with
All repositories; - direct access to the private repository through Git/GitHub working normally.
But Claude web/Desktop had no GitHub tools available in the session. When asked to inspect the private repository, Claude fell back to generic web requests, which naturally returned 403 for a private repository.
That issue was closed as a duplicate, so again it is evidence of a similar reported symptom, not a confirmed diagnosis for this thread.
This distinction matters because “Claude can see public GitHub repos” can mean two different things:
A. Public repos appear in the GitHub repository picker,
but private repos do not.
B. Claude can open public github.com URLs with ordinary web access,
but private URLs fail.
Those are not necessarily the same problem.
Case A points more toward repository installation/scope/SSO/enumeration.
Case B can also happen when the authenticated GitHub connector is not actually available to the current Claude session and Claude is merely using unauthenticated web access.
4. If public and private repos both fail, that is another branch again
In that report, repositories could be selected and apparently attached, but Claude could not retrieve their contents afterward — including public repositories.
That makes a private-repository permission explanation much less convincing and points instead toward a broader connector/runtime problem.
So the observed failure pattern itself is useful:
| What fails? | First place I would look |
|---|---|
| Only one private repo is absent | GitHub App repo scope / repo-specific state |
| All private repos absent, public repos visible | App installation / SSO / private-repo enumeration |
| Org private repos absent, personal repos work | Org SSO / admin / enterprise policy |
| Personal private repos absent, org repos work | Similar to #18467-class reports |
Repo is listed but Claude cannot access that resource persists |
Grant ↔ Claude-side sync/access mismatch |
| Claude says GitHub is connected but exposes no GitHub tools | Connector/session provisioning |
| Both public and private repos fail | Broader connector/runtime issue |
None of these rows is a root-cause guarantee; they are just useful ways to avoid debugging the wrong layer.
Why Claude Code working does not completely settle the Claude.ai side
I would keep the successful Claude Code access as a useful control:
Claude Code can access the repo
→
the repository and your GitHub access are functioning
through at least one path
But I would not extend that to:
Claude Code can access the repo
→
therefore the Claude.ai GitHub connector installation,
repo grant, SSO state, and repository picker must all be healthy
Claude has multiple GitHub-facing surfaces, and they do not all have to fail or succeed together.
This also explains why a Claude Code success plus a Claude.ai failure is not as contradictory as it first looks: it helps rule out some very basic repository/account problems, but it does not isolate the web connector path.
If strict GitHub-level read-only access is a hard requirement
If the security requirement is specifically:
“Claude must have no GitHub write-capable tools/permissions at all”
then I would not assume the built-in Claude GitHub App satisfies that simply because you only use it for reading.
As mentioned above, Anthropic documents a single broader permission set for the official shared Claude GitHub App, and GitHub does not allow users to approve only part of that app’s requested permissions.
As a useful comparison, GitHub’s own official GitHub MCP Server has an explicit read-only mode. Its documentation describes read-only as a security filter that disables write tools, and the remote server supports X-MCP-Readonly: true: GitHub MCP Server configuration.
That is a much closer example of true tool-level read-only enforcement.
I would treat that as an alternative architecture rather than a drop-in fix for the Claude.ai “Add from GitHub” connector, though. GitHub’s current host-compatibility documentation distinguishes Claude Code/Desktop MCP setup from the built-in Claude.ai GitHub integration, so replacing one with the other adds setup and authentication complexity.
For the ordinary Claude.ai use case, the simpler least-privilege option is still:
official Claude GitHub App
+
Only select repositories
+
select only the repository Claude actually needs
provided that the app’s broader requested GitHub permission set is acceptable to you.
So, in practical terms, I would check it in this order:
1. GitHub side:
Is the Claude GitHub App actually installed on the
GitHub account/org that owns the private repo?
2. Repository scope:
Is that exact private repo included in the installation?
3. If organization-owned:
Check SSO / Grant vs Request / org admin approval
(and EMU approval if applicable).
4. If all of those are already correct:
Don't assume user error.
Compare the exact symptom with the similar Claude-side
reports above.
5. Separately decide what "read only" means:
- reading/analyzing only, or
- absolutely no GitHub write permission granted.
My best guess from the information in the post would be to start with GitHub App installation + repository scope, because that is both the documented private-repo path and the cheapest thing to verify.
But if that exact repo is already selected in GitHub and, where applicable, SSO is already authorized, I would stop repeatedly reconnecting things and treat a Claude-side repository enumeration/sync/connector problem as a real possibility. There are enough similar reports now that I don’t think “Claude Code works, therefore the Claude.ai connector must be configured correctly” is a safe assumption.