Repo-bound cloud session fails to start when the revision is a slash-containing branch name that exists on the remote

Summary

When claude --cloud creates a repo-bound session, a revision whose branch name contains a slash (team/branch style) fails to resolve in the cloud VM — the session dies at the "Cloned repository" step with:

The requested branch or commit was not found in the git_repository source. Check the spelling of the branch name, verify it exists on the remote, and ensure it hasn't been deleted or renamed.

The branch demonstrably exists on the remote. A slash-free branch name pointing at the same commit clones fine, which isolates the failure to the ref-name shape.

Environment

• Claude Code 2.1.233 (native, macOS), claude.ai Max account
• Private repo under a GitHub org; sessions authenticate via the connected GitHub account
• Repro reaches the repo-bound path with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 (see #81776 for why that env var is needed on this machine at all — independent issue)

Repro (controlled A/B at the same commit)

Both branches point at the same commit 65027490…, both verified present on the remote via git ls-remote before each run:

# A: slash-free ref — WORKS
git push origin 65027490:refs/heads/tf1320-noslash
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 claude --cloud "report git remote -v" --ref tf1320-noslash
# → session clones, `git remote -v` inside the VM shows the repo, works on a claude/… branch
# (session_014vdVpFGaZrivzFZ8ReMwzk)

# B: slashed ref — FAILS
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 claude --cloud "report git remote -v" --ref the-framework/log-row-wash
# → "The requested branch or commit was not found in the git_repository source" → "Session couldn't start"
# (session_01UJwbiJmfFQpVsVtbVquPDq)

Client-side debug logging confirms the request is well-formed in both cases — the session-create payload carries "revision": "the-framework/log-row-wash" and the CLI logs [teleportToRemote] Git source: github.com/<org>/<repo>, revision: the-framework/log-row-wash before the 200 response; the failure happens later, in the VM's clone step.

Also reproduced without --ref: the default pin to the current local branch fails the same way whenever that branch has a slash in its name (git branch --show-current → the-framework/…).

• --ref main → works
• --ref tf1320-noslash → works
• --ref the-framework/log-row-wash → fails (exists on remote, same commit as the working no-slash ref)
• default pin, current branch the-framework/… → fails

Expected

Slash-containing branch names are legal git refs (and a common team convention, e.g. feature/x, user/topic). The revision lookup in the git_repository source should resolve them like any other branch, or the CLI should reject them at creation time with a clear message instead of producing a session that dies at provisioning.

Impact

Any workflow whose branches are namespaced with slashes cannot hand off to a repo-bound cloud session from that branch — the session is created successfully and then fails to start, with an error that (incorrectly) suggests the branch does not exist.

Cross-refs: #81776 (CLI silently bundles when the GitHub-App preflight fails), #86268 (docs vs bundle-trigger behavior). This one is independent of both: it occurs on the repo-bound path itself.