[BUG] [P0] [Regression] GitHub connector is authorized at account level but unavailable in Chat (claude.ai/chat)

Preflight Checklist

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

What's Wrong?

GitHub Integration is authorized at the account level but is unavailable inside Chat (claude.ai/chat); Chat falls back to unauthenticated web_fetch, which cannot read private repositories.

Scope: This report concerns ONLY the Chat surface (https://claude.ai/chat/) and the connector settings page (https://claude.ai/customize/connectors). All other GitHub-backed surfaces are out of scope.

Severity: P0 — the GitHub Integration is authorized and shown as connected in Settings, but its advertised Chat capability is fully non-functional, with no in-product workaround.

Environment

• Surface: Claude.ai Chat — web (https://claude.ai/chat/)
• Connector config: https://claude.ai/customize/connectors → GitHub Integration shows authorized / connected

Summary

GitHub is authorized at the account level — the connector settings page (/customize/connectors) confirms the GitHub Integration is connected. When adding a private repository, the redesigned flow even displays this promise:

"Pick a repository and branch — Claude reads it through the GitHub connector when it needs it. Nothing is downloaded now, and sending is never blocked."

In practice, the connector does not attach to / surface in Chat sessions, so the capability the connector page explicitly advertises —

Chat — Attach files directly from a repo when asking Claude a question.

— does not work at all. Chat silently falls back to unauthenticated web_fetch, which cannot reach private repositories.

Bug 1 — Chat defaults to unauthenticated web_fetch for GitHub URLs; does not distinguish public vs private

When a GitHub URL (including a private-repo URL) is referenced in Chat, the assistant's first action is an unauthenticated web_fetch against github.com instead of using the authorized GitHub connector. web_fetch cannot access private repositories:

• Private PR URL → HTTP 404
• Repo tree URL → robots.txt disallowed

Expected: With GitHub authorized, repo content (public or private) must be served through the authenticated connector. Unauthenticated web_fetch must not be the default path for GitHub repository content.

Bug 2 — Authorized connector does not propagate to the Chat session (the P0)

Although Settings shows GitHub authorized, the connector is absent from the Chat session's available connectors. The session exposes only Gmail, Google Calendar, and Google Drive; GitHub never appears. This persists across repeated page refreshes and reconnects. The precise failure is account-authorized → not session-available: authorization succeeds but never reaches the Chat runtime. Combined with Bug 1, there is no path to read a private repo in Chat. This worked before the connector redesign — hard regression.

Expected: Once authorized at the account level, the connector is present in the Chat session and serves repo content on demand.

What Should Happen

With the GitHub Integration authorized in Settings, the connector should be available inside Chat and the advertised capability should work end to end:

1. Authorization propagates to the session. Once GitHub is authorized at the account level, it appears among the Chat session's available connectors (alongside Gmail / Google Calendar / Google Drive). No separate per-chat reconnect should be required.
2. Repo content is served through the authenticated connector — as the connector's own prompt promises ("Claude reads it through the GitHub connector when it needs it"). When a repo file, diff, or PR (public or private) is referenced or attached in Chat, Claude reads it via the authorized connector, not via unauthenticated web_fetch.
3. Public vs private is handled by the connector. Private repositories are accessible because the connector carries the user's GitHub auth; access is never silently downgraded to web_fetch, which cannot authenticate.
4. web_fetch is not the default path for GitHub repository content. It should only ever be a fallback for genuinely public, non-authenticated web pages — never the first action on a github.com repo URL when the connector is authorized.

Net result: a user with GitHub authorized can attach files from a private repo and ask questions about them in Chat, exactly as the connector page describes — restoring the behavior that worked before the redesign.

Diagnostic evidence

• Settings (/customize/connectors): GitHub Integration shows authorized / connected.
• Chat session's available connectors: only Gmail, Google Calendar, Google Drive (GitHub absent).
• web_fetch(<private PR url>) → 404.
• web_fetch(<repo tree url>) → robots.txt disallowed.

Impact

The connector's advertised Chat repo-attach capability is unusable despite valid authorization. Private-repo workflows in Chat are fully blocked; the only workaround is manually pasting file contents — exactly what the connector is meant to replace.

Error Messages/Logs

# Referencing a private-repo PR in Chat triggers an unauthenticated web_fetch:
web_fetch("https://github.com/<owner>/<repo>/pull/<n>")
  -> HTTP 404 (private repo, no auth)

web_fetch("https://github.com/<owner>/<repo>/tree/<branch>")
  -> blocked by robots.txt (automated access disallowed)

# Chat session's available connectors (GitHub absent despite Settings showing it authorized):
  Gmail
  Google Calendar
  Google Drive

Steps to Reproduce

1. In https://claude.ai/customize/connectors, confirm the GitHub Integration shows authorized / connected.
2. In Chat (https://claude.ai/chat/), add a private repository through the connector flow. The redesigned flow displays this prompt when adding the repo:

> "Pick a repository and branch — Claude reads it through the GitHub connector when it needs it. Nothing is downloaded now, and sending is never blocked."

1. Reference content from that private repo — paste a private-repo PR or file URL (e.g. https://github.com/<owner>/<repo>/pull/<n>), and/or try to attach files directly from the repo.
2. Ask Claude to read or summarize that repo content.

Observed:

• Despite the prompt stating "Claude reads it through the GitHub connector when it needs it," Claude instead calls unauthenticated web_fetch on the github.com URL.
• web_fetch on the private PR URL returns HTTP 404; on the repo tree URL it is blocked by robots.txt.
• GitHub does not appear among the Chat session's available connectors — only Gmail, Google Calendar, and Google Drive are present.
• No usable "attach files from a repo" affordance works in the Chat session.
• Refreshing the page and re-opening the chat does not change the result.

Claude Model

N/A — claude.ai Chat connector issue (model-independent)

Is this a regression?

Yes

Last Working Version

The GitHub connector as it behaved prior to its recent redesign (claude.ai web has no user-facing version string)

Claude Code Version

N/A — this is a claude.ai Chat (web) issue, not Claude Code

Platform

Web — claude.ai (browser)

Operating System

N/A — browser-based (OS-independent)

Terminal/Shell

N/A — claude.ai Chat (web); no terminal involved

Additional Information

Root failure mode: account-authorized → not session-available. The GitHub Integration authorizes successfully in Settings but never propagates into the Chat session's connector set, so Chat silently downgrades to unauthenticated web_fetch, which 404s on private repos. Replacing the <owner>/<repo>/pull/<n> and <branch> placeholders with any private repository reproduces it.