Cloud session: "The requested branch or commit was not found" on a repo where the branch does exist

# Cloud session cannot start: "The requested branch or commit was not found" on a repository where the branch does exist

## Summary

Every attempt to start a Claude Code cloud session for one project fails with

> The requested branch or commit was not found in the repository "ntgptit/memox-v7".
> Check the spelling of the branch name, verify it exists on the remote, and ensure it hasn't been deleted or renamed.

The repository is public, its default branch `main` exists and is current, and the
failure reproduces on a **newly created** session, not only on a resumed one. The
repository side has been verified exhaustively (evidence below) and resolves
correctly, which points at ref state held on the service side rather than at the
repository.

## Environment

| | |
|---|---|
| Client | Claude Code, Android app |
| Model shown | Opus 5 |
| Project | "Memox" |
| Repository | `github.com/ntgptit/memox-v7` (public) |
| Also in use | Claude Code desktop, same repository, working normally |

## Reproduction

1. Open the Android app, project "Memox".
2. Start a session and send a prompt (`review theme của app`).
3. Session initialisation runs and then fails.

Observed on two separate sessions:

| session | kind | time (UTC+7) | result |
|---|---|---|---|
| "Đánh giá theme ứng dụng" | existing | 11:48 | error |
| "App theme review" | newly created | 11:57 | error |

On the first, the setup panel showed:

```
✓ cloud container set up
✓ 1 repository cloned
✗ run setup script
✗ start Claude Code
```

**The clone step reports success and the failure comes after it.** That ordering is
the most useful detail in this report: whatever ref is being resolved is resolved
*after* a working clone exists, so the repository is reachable and readable, and
only the requested ref is missing.

## What was verified on the repository side

All of this was run from a machine with the repository checked out, immediately
before filing:

```
repo default branch : main
repo visibility : public
remote HEAD : 4745f4fa1c7ed1a99a2e880d7c8e4a14bc1d69fe HEAD
refs/heads/main : 4745f4fa1c7ed1a99a2e880d7c8e4a14bc1d69fe refs/heads/main
branches on remote : 19
non-standard refs : none (only refs/heads, refs/tags, refs/pull)
base-branch config in repo: none
- .claude/settings.json contains only a PostToolUse hook
- no baseBranch / base_branch / defaultBranch key anywhere in .claude or .github
```

A fresh `git clone --bare` of the repository succeeds and contains `main` at the
same SHA.

## Two red herrings ruled out, in case they look relevant

**1. A local-only branch.** The desktop machine's primary checkout was sitting on
a branch that had never been pushed. That is a genuine hazard for anything that
resolves a base branch against the remote, so it was fixed — the checkout is on
`main` and local `main` matches `origin/main`. The cloud session still fails.

**2. An orphaned commit from a force-push.** One branch had been force-pushed
(`+ edcd3558...df536ea3 claude/app-theme-review-vc0mha -> origin/... (forced update)`),
orphaning the previous tip. A session pinned to that SHA would legitimately fail.
The commit was recovered and pushed back as `rescue/app-theme-review-edcd3558`,
and a fresh bare clone now resolves it:

```
clone rc=0
git cat-file -t edcd3558 -> commit
branch --contains edcd3558 -> rescue/app-theme-review-edcd3558
```

The cloud session still fails — and a **newly created** session should not be
resolving that commit at all.

## What the report is asking for

Since the repository resolves `main`, resolves its own `HEAD`, and now also
resolves the previously orphaned commit, the remaining variable is the ref the
service asks for. Useful next steps from your side:

- What ref (branch name or SHA) does the failing session actually request? The
error does not include it, which is what makes this undiagnosable from the
user side — **please consider putting the requested ref in the message.**
- If a project stores a "base branch" that can go stale when that branch is
deleted or force-pushed, is there a way to inspect or reset it from the client?
No branch was knowingly set to anything other than the default.
- A newly created session inheriting a failed session's pinned ref would explain
the behaviour; if sessions created while another session of the same project is
open inherit its ref, that is likely the bug.

## Impact

The project cannot be used from mobile at all. Desktop is unaffected, which makes
this a ref-resolution problem specific to the cloud session path rather than
anything about the repository's contents.

Start with the Android cloud-session reproduction and the session-initialisation steps described in the issue, especially the point after the repository clone succeeds. Inspect how the requested branch or commit is selected and propagated for newly created sessions, using the listed repository checks as comparison. Done means identifying the incorrect or stale ref handling and confirming that a new session starts successfully, ideally with the requested ref visible in errors.

Written by the indexing model from the issue text.