Submitting cloud tasks from Codex CLI fails with "Provided git ref main does not exist" when master branch is used
What version of Codex is running?
codex-cli 0.80.0
What subscription do you have?
ChatGPT Business
Which model were you using?
Not visible in the errored cloud logs, whatever Codex Cloud uses by default I guess.
What platform is your computer?
Darwin 25.1.0 arm64 arm (Not sure why you need this since the error is in Cloud)
What issue are you seeing?
On our repos which have a master branch instead of a main branch, tasks sent to Codex Cloud try to check out the main branch. The default is master here, which is correctly configured in Github too. main is never mentioned anywhere in the .git info or on our GitHub settings.
What steps can reproduce the bug?
- Have repo where the default branch is not named main (e.g. master).
- Submit new task from codex cloud CLI.
What is the expected behavior?
The submitted task would run against the default branch, regardless of it's name.
Additional information
Output in codex:
<img width="799" height="534" alt="Image" src="https://github.com/user-attachments/assets/851b3296-bdc3-41dc-86d1-ccab1562e153" />
Git config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = https://github.com/***/***.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
vscode-merge-base = origin/masterGit default branch setting:
<img width="746" height="180" alt="Image" src="https://github.com/user-attachments/assets/3f644982-c2c7-43cc-8011-f10c97a8acf5" />
9 Comments
Thanks for the bug report.
I'm struggling to reconcile the behavior you're seeing with the current logic. It first attempts to get the current branch, then falls back on the default branch, then falls back on a hard-coded branch name of "main".
Is it possible that you're using a detached HEAD? Or perhaps there are no remotes defined for your local git repo?
Hi, i'm not sure what you mean. I'm submitting a new cloud task through the CLI so my local git repo shouldn't matter, right?
Proposed fix in PR #9149: when the CLI can't resolve a branch locally and falls back to 'main', retry once with 'master' if the backend reports that 'main' doesn't exist.
I still don't understand what my local environment has to do with spinning up a Cloud task? Do you mean that the Codex CLI infers the branch name from whatever local branch is active? Isn't the whole point of spinning up a Cloud task that it's.... a cloud task? Otherwise i'd just continue with the local agent in my current environment. This seems like an odd functionality, I think the most common workflow would be: 'Fire up a cloud agent to do something else while you're working on something locally', in which case you probably DON'T want it to checkout your local branch, since you want it to work on some other feature.
Good question — even though the task runs in the cloud, the backend API still needs a
git_refso it knows what to check out.Today, when you don’t pass
--branch, the CLI picks a default like this:1)
--branchoverride (if provided)2) current local branch (when run inside a git repo)
3) repo default branch (via git metadata)
4) hard-coded fallback
"main"So your local repo only matters for selecting that default ref; the task itself still runs entirely in the cloud.
The failure in #9111 happens when (2) and (3) can’t be resolved (e.g. detached HEAD / missing remote HEAD / not in a git checkout), we hit the hard-coded
"main", and the backend rejects it for repos whose default branch is"master".PR #9149 keeps the change narrowly scoped: if we used the fallback
"main"and the backend reports that"main"doesn’t exist, retry once with"master".Workaround today: explicitly pass
--branch masterwhen creating the cloud task.If you’d prefer the default to always be the repo default branch (rather than the current local branch), I agree that’s a reasonable UX discussion — but I kept #9149 focused on fixing the hard failure.
Alright, thanks for the explanation, i'll try it with the branch override until that PR is merged.
To me, it sounds more logical to, if there's no git metadata, just get the default branch as configured in GitHub instead, since there is already a GitHub integration anyways.
Thanks — I agree.
In the “no local git metadata” cases (not in a checkout / detached HEAD / remote HEAD missing), hard-coding
main/masterisn't ideal. Your suggestion (use the repo's configured default branch from GitHub) makes sense, but the CLI doesn't currently call the GitHub API, and in some of these scenarios it may not even know whichowner/repoto query. Also, adding a GitHub auth flow to the CLI would be a bigger product/API decision.The cleanest direction is to make the backend authoritative for the default branch (it already knows which repo the cloud environment is tied to). I opened a follow-up issue to track that: #9154.
PR #9149 is intentionally a minimal-risk stopgap to prevent the hard failure for
master-default repos when we fall back tomain. In the meantime,--branch masteris the reliable workaround.Quick update: PR #9149 has been closed by maintainers as not the right fix. The proposed long-term direction is now tracked in #9154 (backend-authoritative default branch), and I've added a checklist of open API/behavior questions there.
Until #9154 is implemented, the reliable workaround remains passing
--branch <name>(e.g.--branch master).Update: I opened PR #9190 (refs #9154) which plumbs an optional git ref and omits the new_task.branch field when local git metadata can't be resolved, allowing the backend to use the repo's default branch (with a compatibility retry for backends that still require a branch).