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.