GitHub connector links repositories successfully but Claude cannot access content for ANY repository (account-wide, public and private alike) — recent regression

[Antares9879]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Note: This is NOT a Claude Code CLI issue — this is the GitHub connector within claude.ai web chat.

This is a recent regression, not a longstanding issue. It worked correctly as recently as June 19-20, 2026. The failure started June 25, 2026 and is still ongoing as of June 26, 2026. This narrow timeframe should correlate with a specific backend change/deploy on Anthropic's side.

The GitHub connector ("Add content from GitHub") lets me select and "add" a repository to a chat without error, but Claude is never actually able to read its contents afterward. The repository behaves like an inert text reference rather than a working connector link.

This is not isolated to one repository — it happens with every repository I try, both public and private, on every branch. Unlike intermittent-access reports elsewhere, the failure here is consistent every time, not occasional.

What I have tried:

• Confirmed repositories are public (not just private) — rules out a per-repo permission/visibility issue
• Disconnected and re-authorized the Claude GitHub App from scratch — issue persists
• Re-selected repositories and branches multiple times — same result each time

Related to #68517, but distinct: that report describes private repos failing intermittently while public repos on the same account work fine, with a history of the repo being transferred to an organization and back. In my case, both public and private repos fail consistently with no intermittent success and no organization-transfer history — suggesting a broader connector-level failure rather than an issue isolated to private-repo indexing.

This also appears consistent with other reports of GitHub repository sync/access being broken despite the connector showing a "Connected" status (see #10647, #33875, #18467, #27155 for related patterns).

What Should Happen?

After selecting and adding a repository via "Add content from GitHub" (public or private), Claude should be able to read its file tree and contents when asked, consistently — not intermittently and not failing for all repos.

Error Messages/Logs

No explicit error message is shown in the UI. The repository is simply not accessible — Claude cannot retrieve any file or folder content from it, as if no repository were attached at all.

Steps to Reproduce

1. Open a new chat on claude.ai
2. Click the "+" button → "Add content from GitHub"
3. Select any repository from my account (tested with both public and private repos), any branch
4. Click "Add repository"
5. Send a message asking Claude to read the project's folder structure or file contents
6. Observe: Claude has no actual access to the repository content, despite the repo appearing successfully linked in the UI

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A (claude.ai web feature, no version number exposed). Last confirmed working: June 19-20, 2026. Started failing: June 25, 2026. Still broken as of June 26, 2026.

Claude Code Version

N/A — using claude.ai web chat, not Claude Code CLI

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Browser: Chrome 148.0.7778.21
Account type: Free Plan
Example public repository tested: Antares9879/PBL-TRPL210

Cross-reference: see #68517 for a related but distinct pattern (private-repo-only, intermittent, with an organization-transfer history). This report differs in that both public and private repos are affected, consistently, with no transfer history, and the onset is precisely dated (June 25, 2026).

[Antares9879]

Re: the auto-applied "invalid" label — this report is intentionally filed here because the GitHub connector bug affects the same Claude account/app ecosystem, and similar GitHub-integration bugs (e.g. #32479, #33875) have been filed and discussed in this repo despite not being Claude Code CLI issues. Flagging in case a maintainer wants to redirect this to a more appropriate tracker — happy to move it if one exists.

[0x044]

I've been facing this issue too.

Revoked claude connection in both claude.ai and github settings. Relink doesnt work.

Inspected network tab and it does successfully fetch info from github api. (hoping this might narrow somethings down)

Add repository button adds a link to the repo in chat (prev. the interface could retrieve all selected files and sync knowledge before the message was sent)

[nikokonovalov]

same issue here

[davidhunter-em]

Experiencing the same issue today.

[Dave-Murray98]

same issue here today

[zealousteedo]

Same issue here.

[StarLiu1]

it's been almost a week if not longer than that.

[KrynGe-dev]

Same issue here

[groolbg]

Same issue for me.

[dip-del]

Same regression here.

Environment: claude.ai web chat (browser), Claude Pro, Windows 10.

Symptom matches exactly. Adding a repo via "+ → Add from GitHub" in chat completes without error, and my repositories do show up in the picker, but only an inert reference (the bare repo URL) gets attached. Claude cannot read the file tree or any file contents and has no GitHub tools available in the session.

Where the break actually is (network-tab observation): the GitHub-facing calls succeed. After selecting the repo, the frontend successfully loads the repo metadata and the full tree (paths, sizes, SHAs, with "truncated": false). So fetching from GitHub works end to end in the browser, but the data never reaches the model's chat context. This points at the frontend-to-context ingestion step, not at GitHub auth or retrieval.

Ruled out on my side: verified the Claude GitHub App's installed permissions, disconnected and re-authorized the connector from scratch (in both claude.ai and GitHub settings), and re-selected the repository and branch several times. No change. The connection itself is healthy; only the ingestion into chat fails.

One more observation, since I'm not sure whether it's intended: only the repos themselves are listed, with no tree to drill into. This may well be part of the redesign — if file selection is meant to move into the conversation instead of happening up front — but I can't tell from the outside whether it's intentional or a side effect of whatever broke the retrieval.

Addition: Surface-specific, important narrowing: the regression appears limited to the in-chat attach. But the Project knowledge dialog ("Add content from GitHub → select files to add to this project") still shows the full file tree with per-file checkboxes and lets me select individual paths, exactly as before — in a chat inside that project the file content is read correctly there. Same connector, same repo, two entry points, only the chat one is broken.

Still broken as of June 28, 2026. (Written with help from Claude)

[Dave-Murray98]

Hi Guys, this is still going on. Since they removed the bug tag and added the invalid tag, will that mean that they'll just ignore this?

[NeoOne601]

The issue persists and there is no fix yet. I am using repomix as a workaround. As like many other I did verify the Claude GitHub App's installed permissions, disconnected and re-authorized the connector from scratch (in both claude.ai and GitHub settings), and re-selected the repository and branch several times. No change. The connection itself is healthy; only the ingestion into chat fails.

Here is fragment of the chat transcript while i asked it to fetch me the file tree of my repo. [Repo Name changed Intentionally].

'''
The user is asking me to "generate a full file tree of this repository branch so I can confirm you see everything" with a link to https://github.com/NeoOne601/RepoName/tree/main
Let me think about what I actually have access to here:

I don't have live access to the GitHub repo - my earlier attempts to web_fetch this URL failed with ROBOTS_DISALLOWED
What I DO have is the repomix-output.xml file that was uploaded in the previous turn, which contains a directory_structure section that I already read and viewed

The user wants me to "confirm I see everything" - this is a verification/trust check. Given the conversation history, I should:

Be honest that I cannot live-browse the GitHub URL (confirmed earlier - ROBOTS_DISALLOWED error)
What I actually have is the repomix-output.xml snapshot from their last upload, which contains a full directory_structure listing
I should generate the file tree FROM that repomix snapshot, not pretend I'm fetching live from GitHub

This is important for honesty/transparency given the established pattern in this conversation - I already made mistakes by assuming things about the codebase without verification, and the user has been testing/correcting me on this. I should not pretend to fetch the live GitHub URL again (it will fail) or pretend that what I'm showing is a live fetch. I need to be precise: this is the file tree AS OF the repomix-output.xml file they uploaded earlier in this conversation, which represents a snapshot, not necessarily the absolute live HEAD of main if they've pushed anything since then.
Let me try the web_fetch first to see if it works now (maybe worth a quick check), but I recall it failed with ROBOTS_DISALLOWED. Let me just try once via web_search to see if there's a cached/alternate view, but I should not spend too much time on this since I already know from earlier this conversation that:I will eventually fail.
'''