claude --cloud always creates a bundled session (no remote, no push) despite completed /web-setup and repo-bound web UI

Status Open

Reported on v2.1.220

Maintainer reply None cached

Activity 3 comments · opened Jul 27, 2026

claude --cloud from a git checkout always produces a bundle-upload session with no GitHub binding, even though every documented prerequisite is satisfied. Cloud sessions created from the claude.ai/code web UI work correctly on the same repo, so this looks like the CLI handshake path, same class as #53673.

Environment:

Claude Code 2.1.220, macOS (darwin), claude.ai subscription (Max), logged in
/web-setup completed three times (option 1, browser redirect to claude.ai/code lands fine; note: there is no success confirmation anywhere, which makes this failure invisible)
Also tried: /logout + /login (fresh auth token), then /web-setup again, then a fresh --cloud - still a bundle. claude update reports no newer build than 2.1.220.
Claude GitHub app installed on the org with repository_selection: all
The repo appears in the claude.ai/code repo picker; the web composer binds to it (repo + branch chips shown)
gh authenticated with push access; local checkout has a normal origin remote

Repro:

cd <checkout on branch main, branch exists on origin>
claude --cloud "Diagnostic: run git remote -v and state whether this workspace is a GitHub clone or an uploaded bundle. Change nothing."
Open the created session.

Result, every time (7/7 sessions over two days, including from the repo root on main):

The session container is an uploaded bundle: git remote -v empty, zero remote.* config entries, local-only commits from my machine present in its history
gh is not installed in the container; GH_TOKEN is a ~14-char proxy placeholder
Any authenticated push / api.github.com call answers 403 "GitHub access to this repository is not enabled for this session. Use add_repo to request access" - and no add_repo tool exists in the session (see #76248)

Expected (per docs "From terminal to web"): with GitHub auth configured, the session clones the current directory's GitHub remote and can push.

Impact: the session completes real work, commits it on a branch inside the container, and the work is unreachable: bundled sessions cannot push, and --teleport fetches the session branch from the remote, so there is nothing to fetch. The only recovery is asking the session to attach a git-am patch in chat and applying it by hand.

Two doc/UX asks even if the handshake bug takes time:

A success/failure confirmation for /web-setup, or a status command - today its failure mode is silent and only discoverable N stranded sessions later.
Make --cloud SAY which mode it chose ("cloning from GitHub" vs "uploading a bundle") at creation time - the session link looks identical either way.

View original on GitHub ↗

3 Comments

PabloPereiraBalestra · 17 days ago

Confirming on Windows — with evidence that this is neither OS-specific nor an access/configuration problem on the account.

Environment

Claude Code 2.1.229 (native install), Windows 10 Pro 22H2 (build 19045)
PowerShell 7.6.4 (also reproduced from Windows PowerShell 5.1)
git 2.53.0.windows.2, gh CLI authenticated (keyring, HTTPS)
claude.ai Max account; private repo PabloPereiraBalestra/ppb-system-architect; local clone has a correct origin (verified via git remote -v, remote.origin.url, and upstream tracking)

Repro
From inside the repo clone:

claude --cloud "Report the literal output of: git remote -v && git branch -a"

The CLI prints only Created cloud session: .... The provisioning checklist documented in "Use Claude Code on the web" (cloning the repository, setup script) never appears.
The session lands in the claude.ai/code sidebar under "Other", with no repository association.
Inside the VM: git remote -v is empty and .git/config has no [remote] section at all, while full commit history is present — i.e. the local-bundle path was taken.
Any push then fails. Two variants observed:
fatal: 'origin' does not appear to be a git repository (exit 128)
pushing to the explicit URL: 403 — PabloPereiraBalestra/ppb-system-architect is not in this session's authorized repository set (same string as #76248)

Reproduced 4/4 times over one day:
session_01WzQdkxnE19viaJW8omCtkh (before /web-setup), session_01FYjvVtyBB9YkPU3tbSpXNF, session_0114tMGRUAxE5huDCGbyoPfQ (both after /web-setup), session_01VMwnRkocuy11B7E4iNB43b (after trusting the project; source of the 403 above).

Ruled out — same day, same account, same repo

GitHub access: sessions launched from claude.ai/code or the Desktop app for the same repo clone with origin configured and push successfully (branch verified on GitHub via a local fetch).
/web-setup: completed ("Connected as PabloPereiraBalestra"); CLI-launched sessions still bundle afterwards.
CCR_FORCE_BUNDLE: not set (no CCR*/CLAUDE*/ANTHROPIC* env vars present).
Project trust: accepted the trust prompt; behavior unchanged.
/remote-env: shows the intended environment selected (✔), so it is not the "no environments" case of #19573.
Remote URL shape: standard https://github.com/<owner>/<repo>.git.

Triage notes

The original report here is macOS on 2.1.220; this is Windows on 2.1.229 with identical symptoms, so the cause looks like the CLI→cloud handshake (repository resolution/authorization at session creation), not something OS-specific.
Docs state the bundle fallback activates "when GitHub access isn't available". On this account GitHub access demonstrably is available (the web/Desktop path works), yet --cloud from the CLI always takes the bundle path. Cross-ref #86268 on whether bundling became intentional and the docs are stale.

suleimansh · 14 days ago

Root-caused on my machine (macOS, 2.1.233) with DEBUG=1 logs, plus a working workaround. This should also explain @PabloPereiraBalestra's Windows repro and settle the #86268 "intentional or regression" question: it's a conditional fallback whose condition got much stricter than the product's documented access model.

What the debug log shows

[teleportToRemote] Git remote URL: https://github.com/<org>/<repo>.git
Parsed repository: github.com/<org>/<repo>
Checking GitHub app installation for <org>/<repo>
GitHub app is not installed on <org>/<repo> (status is null)
[teleport] phase: bundle-upload
[teleportToRemote] Bundling (reason: github_preflight_failed)

So the bundle decision is made by a preflight (GET /api/oauth/organizations/{orgUuid}/code/repos/{owner}/{repo}, keyed by the claude.ai org) that requires status.app_installed to be true. Meanwhile:

The docs say either the GitHub App or a connected account (/web-setup) grants cloud sessions repo access — "regardless of which repositories the Claude GitHub App is installed on".
That's demonstrably true: a web-UI session on the same repo, same account, pushes fine (branch verified on GitHub), while the same account's CLI sessions bundle. /web-setup is completed; the repo shows in the repo picker.

So the preflight tests a stricter condition (App install record for the claude.ai org) than the product actually needs (connected account), and every /web-setup-only user lands in the bundle path.

Why this regressed

The CLI contains an optimistic fallback: when the preflight fails and bundle seeding is not enabled, it proceeds repo-bound anyway — which works via the connected account. Bundle seeding is controlled by a server-side gate (tengu_ccr_bundle_seed_enabled). With the gate rolled out, "preflight failed" now means "silently bundle" instead of "try repo-bound", which converted working setups into stranded no-remote sessions with no user-visible signal.

Workaround (verified end-to-end)

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 claude --cloud "<task>" --ref main

With statsig disabled the gate reads false, the same failed preflight now logs [teleportToRemote] Git source: github.com/<org>/<repo>, revision: main, and the created session cloned the repo and successfully pushed a branch to GitHub — the first CLI-created session to do so on this machine across ~10 attempts since 2.1.220.

One caveat: without --ref, the session pins to the current local branch; launching from a local-only (or slash-named) feature branch produced an in-session error "The requested branch or commit was not found in the git_repository source". --ref (undocumented for --cloud) avoids it.

Suggested fixes

Preflight should accept either access form — the connected-account check evidently exists server-side (/schedule accepts either).
When falling back to bundle, say so at creation time ("no GitHub access for this org — creating a bundle session that cannot push") instead of printing only the session link. The silent divergence is what makes this so expensive to diagnose.