›_ Codex Issues
Codex Issues / #9154

Cloud tasks: derive default git ref from environment/repo

Resolved 💬 4 comments Opened Jan 13, 2026 by liqiongyu Closed Feb 23, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Context

  • codex cloud exec / cloud task creation requires a git_ref so the backend knows what to check out.
  • Today, when --branch is not provided, the CLI resolves git_ref from local git state (current branch -> repo default branch from git metadata -> hard-coded fallback "main").

Problem

  • If the CLI can't resolve local git metadata (detached HEAD, missing remote HEAD, not in a checkout, etc.), it falls back to "main".
  • This breaks for repos whose default branch is "master" (see #9111). PR #9149 is a minimal-risk fix (retry master when fallback main is rejected), but the underlying UX remains: in “no local git metadata” scenarios, the CLI is guessing.

Proposal
Make the backend authoritative for the default branch (it already knows which repo a cloud environment is tied to):

Option A (preferred): allow omitting git_ref (or sending null/empty) when --branch isn't provided; backend defaults to the repo's configured default branch.

Option B: add an API endpoint / environment metadata field that returns the repo's default branch, so the CLI can pick it without guessing.

Why not call the GitHub API from the CLI?

  • It would require additional GitHub auth/permissions and doesn't generalize to non-GitHub providers.
  • In cases where the CLI isn't run inside a repo checkout, it may not even know the owner/repo to query.

Acceptance criteria

  • Creating a cloud task without --branch succeeds for repos with default branches named master, main, or anything else, even when local git metadata is unavailable.
  • --branch continues to override.

Related

  • Bug report: #9111
  • Minimal-risk fix: #9149

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 7 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #9111

Powered by Codex Action

liqiongyu contributor · 7 months ago

Thanks for considering this direction.

From a CLI/maintainability standpoint, I think the cleanest fix is to make the backend authoritative for the default branch (env_id already implies the repo), so clients don't have to guess main/master.

A few concrete questions to unblock an implementation PR on the client side:

1) API contract: should new_task.branch be optional (field omitted) to mean “use repo default branch”? Or should it be null / empty string?
2) When to rely on backend default:

  • only when the user did not pass --branch and local git info cannot be resolved?
  • or also via an explicit flag like --use-default-branch (so users can request default branch even if they're currently on a feature branch locally)?

3) Observability: should the backend include the effective branch it used in the response (e.g. in task summary/details), so the UI/CLI can show it?
4) Edge cases: what should happen if an environment isn't tied to a single repo / default branch can't be determined? (explicit error vs fallback)

Once we have answers, I can put up a small PR that (a) stops hard-coding main in “no local git metadata” scenarios and/or (b) adds an explicit “use default branch” switch without changing existing defaults.

liqiongyu contributor · 7 months ago

Opened PR: #9190

etraut-openai contributor · 6 months ago

This feature request hasn't received any upvotes, so I'm closing it.