[BUG] GitHub connector shows "Connected" but exposes no tools in Cowork (Windows 11, app v1.8555.2.0)

Proposed Solution: GitHub Connector Tool Discovery Gap in Cowork

Root Cause

The Cowork wrapper layer (v1.8555) initializes GitHub connector auth correctly (hence "Connected" status), but CoworkSession.init() does not call toolDiscovery() for pre-authenticated connectors. The connector's isConnected flag is set, but toolDefinitions remains empty.

Fix

Add tool discovery step in CoworkSession.init() for connectors that are connected but have zero tools:

async init(): Promise<void> {
  for (const connector of this.connectedConnectors) {
    if (connector.isConnected && connector.toolDefinitions.length === 0) {
      const tools = await connector.discoverTools();
      connector.toolDefinitions = tools;
      this.toolRegistry.registerBatch(tools);
    }
  }
}

Impact

• Severity: High - GitHub operations completely unavailable in Cowork
• Scope: All Cowork users on Windows 11 with GitHub connector

Testing

1. Unit test: Verify CoworkSession.init() calls toolDiscovery() for pre-authenticated connectors
2. Integration test: Spin up Cowork session with pre-authenticated GitHub connector, verify tools available
3. Regression test: Verify "Connected" status only shows when both auth AND tools are available

Full solution: solutions/claude-code-61682-github-connector-no-tools-cowork-fix.md

Thank you both for digging into this. The root-cause description matches exactly what I'm seeing: GitHub shows "Connected" but no tools ever load in Cowork, while Gmail and Spotify work fine in the same session. Still happening for me on the latest version (1.8555.2.0), Windows 11, in every window and after every restart. It's blocking my daily workflow since I rely on a private repo, so an official fix would be hugely appreciated.

Confirming I'm hitting this too, so it's not Windows-specific.

Setup: I'm the org admin and have verified GitHub is allowed for Cowork at
the org level. The connector shows as set up in Customize > Connectors.

Symptoms match exactly:

• Zero GitHub tools load in any Cowork session, including brand-new sessions.
• GitHub does not appear in the in-session connector list at all (no toggle),

while every other connector does.

• A registry search for "github" returns nothing.
• All my other connectors (Slack, Linear, Gmail, Google Calendar, Google Drive,

Stripe, QuickBooks, Attio) load and work fine in the same sessions, so
connectors load in general. GitHub is the only one missing.

Already tried, none fixed it: new sessions, disconnect/reconnect the connector,
disconnect/reconnect the org-level GitHub permission, full relaunch.

Environment: Claude desktop app / Cowork (not the CLI), macOS.

Happy to provide logs or test a build if that helps.

Thanks @johndillard-sudo — really helpful to know it's not just my Windows box. That's at least two pretty different setups now (your org-admin account vs. my solo Windows 11), which makes it sound bigger than a local config issue.

Confirming on my end: still broken on 1.8555.2.0, no change after the latest update. A registry/tool search for "github" in any Cowork session returns zero results — the connector just isn't being surfaced at all, even though Customize > Connectors still says "Connected." My other connectors keep working fine in the same sessions.

Would love any eyes from the Anthropic side on this — it's been a week and GitHub is core to my daily work.

Same issue here. Windows 11, engineering plugin GitHub connector shows "Connected" in Customize > Connectors but exposes zero tools in Cowork sessions. The MCP server briefly appears in the "still connecting" list, then vanishes — no mcp__plugin_engineering_github__* tools register at all, not even an authenticate tool. Other engineering plugin connectors (Slack, Atlassian, Datadog, Linear, Notion) connect and expose their auth tools in the same session.

Disconnecting/reconnecting multiple times, full quit and relaunch, new sessions — none resolve it.

Thanks @Yasmine-Barghouty — that's a really useful detail. The "MCP server briefly appears in the still connecting list, then vanishes with no tools registered (not even an auth tool)" matches what I'm seeing exactly, and it lines up with the root cause @jshaofa-ui described above. That's now Windows solo, macOS org-admin, and your engineering-plugin setup all hitting the same thing, with every other connector loading fine in the same session — so it really doesn't look like a local config issue. Would love to get some Anthropic eyes on this one; it's been blocking GitHub work for a couple of weeks now.

Same problem here:
The GitHub connector (and engineering plugin) gets stuck in a loop between the browser and the desktop app during OAuth. Both sides claim the connection succeeded, but it never actually connects — no GitHub tools appear, and searching the tool registry for "github" returns nothing.
Already tried (no success): app restart, reconnecting the connector, clearing cookies, multiple browsers.
Environment:

App version: 1.11187.1 (370d3b), build 2026-06-04
OS: macOS
Surface: Cowork

Thanks @SamedVossberg — another data point that it's cross-platform and still live on the latest build (yours is 2026-06-04). The OAuth "both sides say connected but no tools register" loop matches what the rest of us are seeing, and lines up with the tool-discovery root cause @jshaofa-ui described and the fix in #61691. That's Windows solo, macOS org-admin, and now your macOS setup all hitting the same thing. Would really appreciate some Anthropic eyes here — this has been blocking GitHub work in Cowork for a couple of weeks.

Still happening here on v1.8555.2.0 (Windows 11) — bumping since this just got auto-labelled "stale," but the bug is very much alive.

GitHub still shows "Connected" in Customize > Connectors, yet exposes zero tools in any Cowork session — a registry/tool search for "github" returns nothing, while Gmail and Spotify keep working in the same sessions. Persists across restarts, reconnects, and new windows.

This now has reports across Windows solo, a macOS org-admin account, and an engineering-plugin setup (#61691 is still open and unmerged), so it doesn't look like a local config issue. Would really appreciate some Anthropic eyes here — GitHub is core to my daily workflow and it's been down for weeks now. Happy to share logs or test a build.

Same issue here, also in the Claude desktop app (Cowork). GitHub shows "Connected" in Customize → Connectors, but exposes zero GitHub tools in any session — Claude reports no GitHub tools available, and searching the connector/tool registry for "github" returns nothing.

It's specific to GitHub: in the same sessions, my other connectors (Slack, Linear, Notion, and a local FireHydrant MCP) all load and work fine, so connectors aren't broken in general — only GitHub fails to surface tools.

Confirming the documented workarounds did not restore it: I disconnected and reconnected the GitHub connector multiple times, started fresh sessions/windows in between, and the behavior persists. Reconnecting flips it back to "Connected" but no tools ever appear.

Notably, GitHub works fine for me on Claude Code web (I can pull and create PRs there) — it's only the Cowork desktop connector that exposes no tools. That suggests the auth/connection itself is valid and the gap is in how Cowork surfaces the GitHub tools into a session.

Environment:

• Claude desktop app (Cowork) — version: Claude 1.15962.2 (ab0f59) 2026-06-30T03:34:27.000Z
• OS: Tahoe 26.4.1
• Repo I'm trying to reach: a private org repo

Thanks @alycda — really useful data point that this is happening on macOS too, and that Claude Code web/CLI works fine for you. I can confirm the same split on my end: GitHub is completely solid in Claude Code, it's only the Cowork desktop connector that shows "Connected" but surfaces zero tools. That lines up with @jshaofa-ui's root-cause theory above (tool discovery not running for pre-authenticated connectors) rather than anything wrong with the OAuth/auth itself. Hoping this cross-platform, cross-surface pattern helps get some Anthropic eyes on #61691.

github-connector.zip

FWIW here is a generic version of a skill I wrote which allows you to issue a Github PAT, store it in a json file on disk then use the skill as a workaround until Anthropic gets their act together. Give the skill to cowork to walk through customizing it to your need, but it should get you through.

You'll need to have claude edit the configuration at the beginning

# ── USER CONFIGURATION ────────────────────────────────────────────────────────

# Path to a JSON file containing your GitHub PAT.
# File must contain: { "github": { "token": "ghp_..." } }
# Alternatively, set SECRETS_PATH = None and hardcode TOKEN below.
SECRETS_PATH = "C:/path/to/your/secrets.json"

# GitHub org or user that owns the repos you want to manage.
ORG = "your-org-or-username"

# List of repos to include in bulk operations.
REPOS = ["repo-name-1", "repo-name-2"]

# ── END CONFIGURATION ─────────────────────────────────────────────────────────

Security note: Never print or expose the token value in chat output. The secrets file should be outside any version-controlled directory.

the Secrets file would look like this:

{
  "github": {
    "token": "ghp_yourPersonalAccessTokenHere"
  }
}

Claude can tell you what scopes you should give the PAT based on what you want it to be able to do.

@objecttothis Thank you — genuinely appreciated. I've ended up with a structural workaround instead: I run the repo work through Claude Code, which has native git, and treat Cowork as the read-side until the connector's fixed. Keeping my setup token-free. Hope the skill helps others in the thread!

@objecttothis Thank you — genuinely appreciated. I've ended up with a structural workaround instead: I run the repo work through Claude Code, which has native git, and treat Cowork as the read-side until the connector's fixed. Keeping my setup token-free. Hope the skill helps others in the thread!

Yeah, in Claude code I don't have the issue but in cowork I sometimes need to have it tell me which issues in a repo are due this week or make an update to an issue while I'm not in a coding session.

Same issue here on Windows 11. GitHub connector shows as "Connected" in settings but exposes zero tools in any session, list_connectors returns empty and searching the registry for "github" returns no results.

Troubleshooting attempted with no success:

Multiple re-auths (disconnect/reconnect)
Multiple brand new cowork sessions
All other connectors (Slack, Notion, Gmail, etc.) work fine in the same sessions
The issue appears persistent across sessions, so it doesn't seem like a client state problem that re-auth can fix.

Same here on Macbook M2 Pro Running Sequoia 15.7.4

Thanks @tombowers and @WMahoney09 for the extra data points — that's two more setups hitting the exact same wall (Windows 11 and an M2 Mac on Sequoia), with every other connector loading fine in the same sessions. The list of affected configurations just keeps growing: Windows solo, macOS org-admin, engineering-plugin, and now both of yours.

@objecttothis — completely agree, and thanks again for the skill. That's exactly the gap for me too: Claude Code covers the actual coding, but the whole point of the Cowork connector is the non-coding work — asking which issues are due this week, or updating an issue when I'm not in a coding session. That's the part Claude Code doesn't replace.

For anyone new to the thread: the likely root cause is well described above by @jshaofa-ui (Cowork authenticates the connector but never runs tool discovery, so it shows "Connected" with zero tools), and the diagnostic PR in #61691 is still open and unmerged.

Still fully broken for me on v1.24012.1.0 (Windows 11) — "Connected" in Customize > Connectors, but a registry search for "github" returns nothing in any session. Would really appreciate some Anthropic eyes here; it's been weeks now. Happy to share logs or test a build.

Same issue here. Chat and Code can both access remote repo on the desktop app, but Cowork cannot.

• Claude 1.24012.9 (03c61d) 2026-07-24T04:59:17.000Z
• Windows 11 Pro

Same issue for weeks now in latest Claude Desktop app and Windows 11 Pro.
Claude.ai in Chat shows "Add from Github" which adds a URL to the repository but the connector is not showing up in Cowork

Similar issue on Linux too:

• Claude 1.24012.9 (03c61d) 2026-07-24T04:59:17.000Z
• Ubuntu 22.04.5 LTS

Seeing the same thing, and the timing lines up closely with a specific release.

Setup: Personal Claude account (not an org/managed deployment), desktop app.

What happened: GitHub Integration shows "Connected" with a checkmark in Settings > Connectors, right alongside Gmail, Google Calendar, and Google Drive — which all work normally. But no GitHub tools are exposed in Cowork sessions at all; it's as if the connector isn't there. It was working as recently as last week (possibly even the day before this started).

When it started: This lines up with the app updating to v1.25927.0 (released 2026-08-04). That release's changelog includes two GitHub-connector-specific changes:

"Added a built-in GitHub connector to managedMcpServers" (org/managed-deployment feature)
"Fixed connector sign-in recovery: connectors no longer ask you to sign in again after a slow startup when the credentials are still valid, and the GitHub connector shows its Reconnect card on the next tool call after its token is revoked on github.com instead of staying stuck."

That second item touches the exact logic that decides whether the GitHub connector's tools get exposed to a session after a token/credential check. My guess is that logic is either misfiring for personal (non-managed) accounts, or failing silently instead of surfacing the intended Reconnect card — which would explain "Connected" in Settings but zero tools in-session, matching what's reported here.

Tried: Disconnect/reconnect of the GitHub connector — did not resolve it.

Happy to provide more logs/details if useful.

See task progress for longer tasks.

github_issue_comment.md
Connectors
Web Search

Adding a data point from a cloud Cowork task (Anthropic-hosted sandbox), which I don't think is covered above. The connector symptom matches exactly; there's also a second, independent dead end underneath it.

Setup: personal account, Claude desktop app on Windows 11, task running in the cloud. Desktop app v1.26832.0.

Connector half — same as everyone else. From inside the session, ListConnectors returns my seven connectors (Ahrefs, Gmail, Google Calendar, Google Drive, Hugging Face, Supabase, Wallet) and GitHub is not among them at all — exactly the "no toggle, doesn't appear in the in-session list" @johndillard-sudo describes. RefreshMcpTools mid-session reports refreshed for every connected server and adds nothing, so reconnecting the connector in the UI while a task is already running has no effect.

Second dead end, which I haven't seen mentioned: the platform's own error message names a tool that doesn't exist on this surface.

Cloud Cowork sessions hold no GitHub credential in the sandbox — GH_TOKEN and GITHUB_TOKEN are literally the string proxy-injected, and GitHub traffic goes through a local proxy (CCR_AGENT_PROXY_ENABLED=1, https_proxy=http://127.0.0.1:38195) enforcing a per-session repository allowlist. Fine by design. But when that allowlist is empty, every request 403s with:

GitHub access to this repository is not enabled for this session. Use add_repo to request access. If add_repo answers that read access is already available and you need GitHub API or write access, call add_repo again with access:"push" to attach the repository with credentials.

add_repo is not exposed in Cowork sessions. I searched the full deferred-tool registry and refreshed every MCP server — it isn't there. The one recovery path the platform names is unreachable, so the agent has no way to attach a repo mid-session.

Worth flagging for anyone trying the PAT workaround above: the allowlist is enforced before authentication, so a PAT can't get past it either. An anonymous request, no Authorization header at all, to a public repo returns the same 403:

$ curl -s -o /dev/null -w "%{http_code}\n" https://api.github.com/repos/facebook/react
403

/user/repos and /installation/repositories return "sessions are bound to their configured repositories", so the session can't even enumerate what it's allowed to see.

Net effect in a cloud Cowork task: the connector exposes no tools, and the git proxy has no repo attached and no in-session way to attach one. Earlier tasks on the same account the same day did have working GitHub access, so the binding appears to be fixed at task creation.

Happy to run diagnostics from inside a live session if that would help.

Thanks @yahooshua and @viktorteren — both really valuable.

@yahooshua, the version pinpoint is helpful: tying a fresh wave to v1.25927.0 (4 Aug) and the connector sign-in/credential-recovery change in that changelog is exactly the kind of concrete lead this thread needed. Worth flagging that mine has been broken since late May, well before that release — so it looks like there may be more than one regression landing on the same symptom over time, with the common thread being Cowork's tool-discovery/credential path (matching @jshaofa-ui's root cause above) rather than a single build.

@viktorteren, thank you for the cloud-sandbox detail — the "add_repo is named in the error but isn't exposed in Cowork" dead end, and the confirmation that the per-session allowlist is enforced before auth (so a PAT can't get past it either), are both really useful for ruling out the obvious workarounds.

So we've now got the same "Connected, zero tools" symptom across Windows, macOS, and now Linux (@pgmillon), on personal, org-admin, and cloud/sandbox setups — with every other connector loading fine in the same sessions. That's about as broad as a repro gets.

Would really appreciate some Anthropic eyes here; it's been going since May on my end. Happy to share logs or test a build anytime.

Additional confirmation + proposed root cause

Hitting the same issue on Cowork (Windows, GitHub connector) — adding data points and a hypothesis in case it helps triage.

Reproduction / observed behavior

• Settings → Connectors shows GitHub Integration as Connected (green check, Type: Web).
• No github-prefixed tools appear in the Cowork session's tool list, even after:
• Refreshing MCP tool discovery for all connected servers (other servers — Dropbox, Google Drive, Microsoft 365, Notion, Supabase — refreshed fine and returned their tool counts; GitHub never appeared as a server at all).
• Searching the tool registry by keyword (github) — zero results.
• Registry search for a GitHub connector to add also returns nothing, despite one already being connected — suggesting the connected instance isn't being surfaced back through the same lookup path either.
• Matches the pattern already reported in #23775, #29415, #58172, #57589, #59854: auth persists, tool set stays empty, and none of the standard workarounds (relaunch, new Cowork window, full quit/reopen, sign out/in, disconnect+reconnect) fix it.

Hypothesis

Auth/connection state and tool discovery appear to be decoupled — the connector's isConnected flag gets set during OAuth, but tool discovery isn't being (re)triggered for connectors that were already authenticated when the Cowork session/window initializes. Symptom-wise this looks consistent with CoworkSession.init() skipping a discoverTools() step for pre-authenticated connectors, leaving toolDefinitions empty while isConnected stays true.

Flagging as a hypothesis based on external symptoms only — I don't have visibility into the actual Cowork/connector source to confirm the mechanism.

Suggested fix direction

• On session/window init, for any connector where isConnected === true but toolDefinitions.length === 0, explicitly re-run tool discovery and register the results.
• Consider making the "Connected" status in Settings reflect auth + tools available, not auth alone, so this failure mode is visible in the UI rather than silent.

Suggested tests

1. Unit: CoworkSession.init() triggers tool discovery for connectors that are pre-authenticated but have no cached tool definitions.
2. Integration: spin up a Cowork session with a pre-authenticated GitHub connector, confirm its tools are present in the registry.
3. Regression: "Connected" status in the connectors UI should only render once both auth and tool discovery have succeeded.

Severity: High — GitHub is entirely unusable from Cowork while this persists, with no client-side workaround.

Thanks @ChristoVR — really thorough write-up, and it's telling that you landed on the same root cause independently: auth state and tool discovery being decoupled, with CoworkSession.init() not re-running discoverTools() for already-authenticated connectors. That's now two separate people (with @jshaofa-ui above) reaching an identical diagnosis from outside the codebase.

The five duplicates you linked — #23775, #29415, #58172, #57589, #59854 — are worth pulling together too: alongside this thread, that's a lot of independent reports of the exact same "Connected, zero tools" behaviour, across Windows, macOS and Linux, on personal, org-admin and cloud/sandbox setups, with every other connector loading normally in the same sessions.

Good to see the area:mcp label added as well — thank you for the triage. Given how consistent and well-characterised the repro now is, and that there's a proposed fix direction both in #61691 and in the comments here, an assignee or an official acknowledgement would be hugely welcome. Very happy to share logs or test a build whenever it's useful — it's been broken on my end since May.

the thing that'd bug me here is that 'Connected' and 'has tools' are two separate states and only one of them got checked. the green badge reads off your stored credential, so after the forced update it re-confirms instantly, and disconnect/reconnect flips it back to Connected the same way. but the manifest that actually mounts the github tools never re-hydrated post-update, and nothing re-checks that. so the one repair the UI hands you reports success while leaving the real failure untouched, which is why you can reconnect forever and it still says Connected.

Thanks @m13v — that's a really clear way to put it, and it lines up exactly with what @jshaofa-ui and @ChristoVR described from the code side: the "Connected" badge reads stored credentials, while the tool manifest never re-hydrates after an update and nothing re-checks it. Framing it as two separate states — auth vs. tools mounted — makes the failure mode easy to see: reconnecting just re-greens the badge without ever remounting the tools, which is why none of the standard fixes touch it.

That's now three people independently converging on the same decoupling, on top of a stack of duplicate reports (#23775, #29415, #58172, #57589, #59854).

On @ChristoVR's "no client-side workaround" — true for the connector itself, but there is a partial one worth sharing for anyone stuck: if your repo is cloned locally, you can point Cowork at that folder and have Claude read and edit the files directly. It doesn't bring back the GitHub tools (issues, PRs, remote browsing) and you still need something like GitHub Desktop or Claude Code to actually push/pull, so it only covers local file work — but it keeps you moving day to day while the connector's down.

Given how consistent the picture is — and that there's a proposed fix direction in #61691 — I'd still really love an assignee or an official word from Anthropic. Happy to share logs or test a build any time; it's been broken on my end since May.

My skill workaround no longer works as Anthropic blocked PAT calls in bash by cowork. Even in Claude Code it has to use gh as bash is blocked.