What changed
Claude Code v2.1.243, released 24 August 2026, added two small but genuinely useful pieces to how GitHub access for Claude Code on the web is surfaced:
- A
/statusline showing whether GitHub is connected for Claude Code on the web, specifically for Pro and Max accounts. - A tip pointing claude.ai users who have not connected GitHub to
/web-setup.
Neither is a new capability. /web-setup and GitHub App onboarding already existed. What is new is that Claude Code now tells you, from the terminal, whether the connection your cloud sessions depend on is actually in place, instead of you finding out the hard way when a --cloud session fails to clone.
Why Claude Code on the web needs GitHub at all
Claude Code on the web runs sessions on Anthropic-managed cloud infrastructure, or on your organisation's self-hosted environment when routed there. Those sessions need to clone your repository and push branches, which means they need GitHub access independent of whatever gh or SSH setup exists on your own machine. Without a connection, a cloud session started with claude --cloud or from claude.ai/code has nothing to clone.
Two ways to connect, either is enough
Anthropic documents exactly two connection methods, and you only need one:
| Method | How it works | Best for |
|---|---|---|
| GitHub App | Authorise the Claude GitHub App during web onboarding in the browser | First-time browser onboarding, and teams that want Auto-fix on pull requests |
/web-setup | Run /web-setup in your terminal to sync your local gh CLI token to your Claude account | Developers who already use gh and would rather skip a browser flow entirely |
/schedule, the command behind Claude Code Routines, checks for either form of access on its own and prompts you to run /web-setup if neither is configured. So this is not purely a Claude Code on the web concern: it gates any workflow that needs a cloud session behind the scenes, including scheduled routines.
Running /web-setup
claude
Then, inside a session:
/web-setup
Claude Code reads the token your local gh CLI is already authenticated with (assuming you have run gh auth login at some point) and syncs it to your Claude account, so cloud sessions can use it without you doing anything in a browser.
If you hit repeated login prompts here instead of a clean sync, check your gh CLI version. Claude Code v2.1.243 specifically fixed a bug where an older GitHub CLI, one without gh auth token support, caused /web-setup to keep asking you to log in even though you already had. Updating gh resolves it.
The Quick web setup organisation setting
On Team and Enterprise plans, /web-setup is not available by default; it is hidden until an Owner turns on Quick web setup at claude.ai/admin-settings/claude-code. Turning it on does three things at once:
- Lets members connect GitHub with
/web-setupat all. - Skips the Claude GitHub App install prompt during browser onboarding.
- Has browser onboarding create the Default environment automatically instead of showing the environment configuration form.
If your organisation has Zero Data Retention enabled, /web-setup and cloud session features generally are unavailable regardless of this toggle, since ZDR turns off the class of features cloud sessions depend on.
Checking the connection with /status
Since v2.1.243, running /status in a Pro or Max session includes a line reporting whether GitHub is connected for Claude Code on the web. If it is not, the line points you at /web-setup directly rather than leaving you to work out the fix yourself. This is a small change, but it closes a real gap: previously, the first sign of a missing connection was often a failed --cloud session, well after you had already committed to the workflow.
Run it before you lean on any cloud-session workflow for the first time:
/status
What either connection method actually grants
This is worth being precise about, because it surprises people. With either the GitHub App or /web-setup, a cloud session can access any repository the connecting GitHub account can see, not only repositories the Claude GitHub App happens to be installed on. Installing the App is not a session-level access control at all; its only functional role beyond initial connection is enabling PR webhooks for Auto-fix.
If you need to restrict which repositories your team can reach from cloud sessions, the fix is on GitHub's side: restrict team or repository membership for the connected GitHub accounts. There is no separate Claude-side allowlist that narrows this per repository.
The GitHub App does one more thing
Beyond initial connection, installing the Claude GitHub App on a repository enables Auto-fix: Claude subscribes to CI failures and review comments on a pull request and pushes fixes automatically when it is confident in one. This is the one capability /web-setup alone does not unlock, since Auto-fix depends on GitHub webhooks the App installation wires up. If you only ever use /web-setup, you can still start and drive cloud sessions normally; you just will not get automatic PR monitoring without separately installing the GitHub App on the repositories you want it watching.
One genuine risk worth flagging if you do turn Auto-fix on: repositories using comment-triggered automation, Atlantis, Terraform Cloud, or custom GitHub Actions keyed on issue_comment events, should have Auto-fix reviewed carefully first. Claude may reply to review comment threads as part of resolving them, posted under your GitHub account and labelled as Claude-authored, and that reply can itself trigger comment-driven automation. Anthropic's own documentation calls this out explicitly and recommends disabling Auto-fix for repositories where a PR comment can deploy infrastructure or run privileged operations.
A worked example: getting from zero to a cloud session
For a developer who already has gh set up locally and wants the fastest path to a working cloud session:
# Confirm gh is authenticated locally
gh auth status
# Sync that token to your Claude account
claude
# then inside the session:
/web-setup
# Confirm the connection took effect
/status
# Start a cloud session for the current repository
claude --cloud "Fix the flaky test in auth.spec.ts"
claude --cloud clones your current directory's GitHub remote at your current branch, not your local checkout, so push any local commits first. If you are working from a repository that is not connected to GitHub at all, Claude Code falls back to bundling your local repository directly, a separate mechanism covered in Anthropic's Claude Code on the web documentation, but the GitHub-connected path above is the normal route for anything hosted on GitHub.
Limits that still apply once you are connected
Being connected does not remove every constraint on cloud sessions. A few are worth knowing before you build a workflow around one:
- Rate limits are shared. Claude Code on the web draws from the same rate limits as all other Claude and Claude Code usage on your account. Running several cloud sessions in parallel consumes those limits proportionately faster; there is no separate compute charge for the cloud VM itself, but there is no separate rate-limit pool either.
- GitHub is the only fully supported remote. Cloning and pull request creation require GitHub, including self-hosted GitHub Enterprise Server instances on Team and Enterprise plans. GitLab, Bitbucket, and anything else can still be sent to a cloud session as a local bundle, covered above, but a session started that way cannot push results back to the remote, only forward the working tree it was given.
- Organisation IP allowlisting breaks Anthropic-hosted cloud sessions outright. Cloud sessions call the Anthropic API from Anthropic-managed infrastructure, not from your network. If your organisation has IP allowlisting enabled on its Claude account, every Anthropic-hosted cloud session fails authentication, along with Code Review and any routine that runs on an Anthropic-hosted environment. A routine or session routed to a self-hosted environment instead calls the API from your own network, so it is not affected the same way. Anthropic support can exempt hosted services from an organisation's allowlist on request.
None of these are fixed by reconnecting GitHub or re-running /web-setup; they are separate constraints on the cloud session infrastructure itself, worth checking before assuming a connection problem.
Troubleshooting
/status shows GitHub as not connected, but I know I authorised the app once. App authorisation and the /status check are for the same underlying connection, so if the check still reports disconnected, the authorisation may have been revoked on GitHub's side, or it may have been done under a different GitHub account than the one your Claude account currently uses. Re-run onboarding through claude.ai/code, or run /web-setup from a terminal where gh auth status shows the account you expect.
/web-setup is not a recognised command. You are most likely on a Team or Enterprise plan where Quick web setup has not been turned on. Ask an Owner to enable it at claude.ai/admin-settings/claude-code, or use the GitHub App browser flow instead, which does not depend on that toggle.
A cloud session fails to clone even though /status says GitHub is connected. Check that the connected GitHub account can actually see the specific repository you are targeting. Connection and per-repository visibility are separate: the account might be connected in general but lack access to a private repository your team just created.
Auto-fix is not responding to CI failures on a PR. Auto-fix specifically needs the GitHub App installed on that repository, on top of either connection method. /web-setup alone connects your account for cloning and pushing but does not wire up the webhooks Auto-fix listens on.
/web-setup keeps asking me to log in even after I already have. Update your gh CLI. Versions without gh auth token support triggered this loop before Claude Code v2.1.243 fixed the workaround on its own end.
Why this is worth checking before you rely on it
The pattern behind this change is worth noticing on its own: Claude Code increasingly surfaces the state of things you would otherwise only discover by hitting a failure. /status already reported account information and your current model before this; adding a GitHub connection line to it is a small extension of the same idea, that the terminal should tell you what it knows about your setup rather than waiting for a workflow to fail first. If you are setting up scheduled routines or planning to lean on --cloud sessions regularly, running /status once up front costs nothing and rules out an entire class of "why did this fail" investigation later.
Where to go next
For the wider set of cloud session capabilities this connection unlocks, teleporting a session into your terminal, sharing sessions with teammates, running scheduled work, see Anthropic's own Claude Code on the web documentation. For running scheduled cloud work specifically, see Claude Code Routines versus /loop, which depends on the same GitHub connection this article covers. If your organisation runs its own infrastructure instead of Anthropic-managed cloud sessions, how to self-host Claude Code runners covers the comparable setup on your own compute. Browse the current Claude Code catalogue at getclaudeskills.com/platforms/claude-code, or everything indexed at getclaudeskills.com/skills.
Verified 27 August 2026 directly against Claude Code's own claude-code-on-the-web documentation at code.claude.com, including the GitHub authentication options section, and the v2.1.243 changelog entry at code.claude.com/docs/en/changelog.
