Codex Desktop 26.810.41047 can resolve a tracked branch as refs/heads/HEAD when creating a permanent worktree

I can confirm this still reproduces on Codex Desktop 26.810.52044
(build 6662), macOS 26.5.2, bundled codex-cli 0.148.0-alpha.9,
and Git 2.50.1 (Apple Git-155).

The primary worktree is on a normal tracked branch:

git status -sb

main...origin/main

git symbolic-ref -q HEAD
refs/heads/main

The Codex Desktop log shows it invoking:

git worktree add --detach <redacted-worktree-path> refs/heads/HEAD

The operation fails before environment setup with:
fatal: invalid reference: refs/heads/HEAD

This appears to be the same tracked-upstream branch resolution bug.

<img width="583" height="294" alt="Image" src="https://github.com/user-attachments/assets/b49635b0-8131-45f3-9846-e45be293d2cb" />

I can also reproduce this on Windows, so this issue is not macOS-specific and appears to be a cross-platform tracked-branch bug.

Environment:

• Codex Desktop 26.810.7004.0
• Windows 10 Pro, build 19045, x64
• A normal local master branch tracking origin/master

Creating a permanent worktree fails with the same error:

fatal: invalid reference: refs/heads/HEAD

I confirmed the following temporary workaround:

1. Temporarily remove the current branch's upstream:

``bash
git branch --unset-upstream
``

1. Create the permanent worktree in Codex Desktop.

1. Restore the upstream afterward:

``bash
git branch --set-upstream-to=origin/master master
``

Unsetting the upstream only removes the branch tracking configuration temporarily; it does not delete or modify branches or commits. The newly created worktree remains usable after the upstream is restored.

ChatGPT 26.814.41407… It seems that the new version has fixed , right?

ChatGPT 26.814.41407… It seems that the new version has fixed , right?

i still got the issue in this version

By the way, I didn't experience this issue in all repositories, only in some of them

> ChatGPT 26.814.41407… It seems that the new version has fixed , right? i still got the issue in this version By the way, I didn't experience this issue in all repositories, only in some of them

Confirmed — 26.814.41407 still reproduces this for me as well.

The “only some repositories” behavior matches the original A/B results: repos where the current branch tracks an upstream can hit refs/heads/HEAD, while removing the upstream makes permanent worktree creation succeed.

So this still looks like a conditional upstream/ref-resolution bug rather than a repository-specific corruption issue.

I am also hitting this bug, and it is making the development workflow very difficult.

The repository is in a normal local branch state, but Codex fails during worktree creation with:

[info] Starting worktree creation
fatal: invalid reference: refs/heads/HEAD
[stderr] git worktree add failed: fatal: invalid reference: refs/heads/HEAD

This appears consistent with the tracked-branch/ref-resolution issue described above: Codex is treating the literal HEAD as a local branch name and constructing the invalid ref refs/heads/HEAD, instead of resolving the current branch or commit correctly. The failure occurs before the worktree is created, so normal Codex development is blocked.

The temporary workaround of running git branch --unset-upstream, creating the worktree, and then restoring the upstream works, but it is disruptive and should not be necessary.

@smattei-oai Could you please prioritize investigating and fixing this? Codex should handle a normal branch with an upstream tracking configuration and pass a valid branch/ref or commit to git worktree add.

Same here, windows
Checked it on all other agents and cli, this is Codex bug only.

What version of Codex is running?

Codex App for Windows (MSIX) 26.818.5229.0 — also reproduced on 26.818.3698.0 right before the auto-update. The bug is in the app bundle (app.asar), not in the codex core binary.

Which model were you using?

N/A — the failure happens in the worktree-creation dialog before any conversation starts.

What platform is your computer?

Windows 11 Pro 10.0.22631, git version 2.53.0.windows.2.

What steps can reproduce the bug?

1. Open any git repository as a project in the Codex App where the checked-out branch has an upstream. A plain git clone qualifies: main tracks origin/main.
2. Sidebar → project … menu → Create permanent worktree → type a name → Create.

Dialog log:

[info] Starting worktree creation
fatal: invalid reference: refs/heads/HEAD
[stderr] git worktree add failed: fatal: invalid reference: refs/heads/HEAD

The same repository works with a manual git worktree add, with the App's normal per-thread (temporary) worktrees, and with other tools' worktree features — only this dialog fails.

What is the expected behavior?

A new worktree checked out at the project's current HEAD, as the dialog promises ("Create a new git worktree from HEAD, add it as a project, and keep it until you remove it").

What do you see instead?

"Worktree setup failed" at the "Preparing workspace" step, with the log above.

Root cause (read from app.asar, 26.818.5229.0)

The "Create permanent worktree" dialog (i18n id sidebarElectron.createStableWorktree.*) submits the pending worktree with a hard-coded starting state:

startingState: { type: `branch`, branchName: `HEAD` }   // launchMode: `create-stable-worktree`

The starting-ref resolver then treats the literal "HEAD" as a branch name:

1. wraps it → refs/heads/HEAD
2. looks up its upstream → git rev-parse --abbrev-ref --symbolic-full-name HEAD@{u} — this succeeds whenever the checked-out branch has an upstream (returns e.g. origin/main)
3. compares → git rev-list --left-right --count refs/heads/HEAD...refs/remotes/origin/main → exit 128 (refs/heads/HEAD is not a revision) → treated as null
4. since the state is not right-ahead, falls back to { ref: "refs/heads/HEAD" }
5. runs git worktree add --detach <path> refs/heads/HEAD → fatal: invalid reference: refs/heads/HEAD

Minified excerpt (26.818.5229.0):

function o6(e){return e.startsWith(`refs/`)?e:`refs/heads/${e}`}
async function c6(e,t,n){                       // t === "HEAD"
  let r=d6(t),                                  // "refs/heads/HEAD"
      i=await a6(e,t,n);                        // rev-parse --abbrev-ref --symbolic-full-name `${t}@{u}`
  if(i!=null){
    let a=`refs/remotes/${i}`,
        o=await i6(e,`${a}^{commit}`,n)==null?o6(i):a;
    return(await e6(e,r??t,o,n))?.state===`right-ahead`   // rev-list --left-right --count refs/heads/HEAD...origin/main → fails → null
      ?{ref:o}
      :{ref:r??t}                                          // → {ref:"refs/heads/HEAD"}
  }
  ...
}
// later: $(e,[`worktree`,`add`,`--detach`,t,u],...)      // u === "refs/heads/HEAD"

Shell equivalent of the failing sequence (any fresh clone):

git rev-parse --abbrev-ref --symbolic-full-name HEAD@{u}                       # origin/main   (upstream exists)
git rev-list --left-right --count refs/heads/HEAD...refs/remotes/origin/main    # fatal: ambiguous argument ... exit 128
git worktree add --detach /tmp/x refs/heads/HEAD                                 # fatal: invalid reference: refs/heads/HEAD

Why it sometimes "works": when the checked-out branch has no upstream (or HEAD is detached), step 2 fails and a later fallback in the same resolver picks refs/remotes/origin/HEAD (the remote's default branch tip) instead. The worktree then gets created — but from the last-fetched origin/<default>, not from the local HEAD the dialog describes, so any unpushed local commits are silently missing. That is a second bug on the same code path.

Suggested fix

Don't route the literal "HEAD" through the branch-name path. Either:

• have the stable-worktree dialog submit the real current branch / commit (git rev-parse --abbrev-ref HEAD, or git rev-parse HEAD when detached), or
• make the resolver special-case HEAD: never wrap it in refs/heads/, never query HEAD@{u} for it, and resolve it to the local HEAD commit.

Additional information

• Possibly related: #12346 (worktree setup assumes a main branch), #12685 ("Create permanent worktree" doesn't run env setup / isn't listed in Settings → Worktrees), #30954 (local branch as starting branch creates a detached worktree).
• Workaround for users: create the worktree manually (git worktree add -b <branch> <path> <base>) and add the folder as a project.

issues still persists

Still reproducible on macOS Codex App 26.818.41509 (build 6962).

The app executes the following invalid command:

git worktree add --detach <path> refs/heads/HEAD

I reproduced this across multiple unrelated repositories where the current branch tracks an upstream.

I am paying $200 per month for this service, yet this core workflow remains broken across multiple releases. Permanent worktrees are a major reason I use the Codex App, and manually creating and registering worktrees is not an acceptable long-term workaround for a paid product at this price.

The root cause has already been clearly identified in this issue. Please prioritize the fix and provide an update or expected release timeline.

Fix merged this morning all, sorry for the troubles. Looking into getting this released ASAP

Fix should be out by late afternoon today.

This issue is still reproducible in the latest available Codex Desktop release.

Environment

• Codex Desktop: 26.818.61809
• Release date shown in the app: August 24, 2026
• Update status: the app reports that it is up to date
• Build branding: Powered by Codex & OWL
• macOS: 26.5 (Build 25F71)
• Git: 2.50.1 (Apple Git-155)
• Repository: https://github.com/deepseek-ai/deepseek-harness
• Current branch: master
• Upstream: origin/master

Error

Creating a permanent worktree still fails immediately:

[info] Starting worktree creation
fatal: invalid reference: refs/heads/HEAD
[stderr] git worktree add failed: fatal: invalid reference: refs/heads/HEAD

yes still not working

@smattei-oai ChatGPT 26.820.60940 still not working. Please fix this as soon as possible, as it significantly impacts the user experience with the Codex app.

Confirmed: this issue is still reproducible in the latest Codex App version, 26.820.60940, so the recent release has not resolved it for me either. Creating a permanent worktree still fails with:

fatal: invalid reference: refs/heads/HEAD

This makes a core workflow unusable and significantly impacts the user experience with the Codex App.

I am paying $200 per month for this service, and permanent worktrees are one of the main reasons I use the Codex App. Having to manually create and register worktrees is not an acceptable long-term workaround for a paid product at this price.

The root cause has already been identified in this issue. Please prioritize releasing the fix as soon as possible and provide a concrete update or timeline.

Still reproducible for me on macOS with Codex Desktop 26.820.60940 (latest available).

Repository state is healthy: local branch master tracks origin/master, and git rev-parse --verify HEAD resolves successfully. Manual creation works with:

git worktree add <path> -b codex/test HEAD

However, “Create permanent worktree” still fails with:

fatal: invalid reference: refs/heads/HEAD

This appears to be isolated to the permanent-worktree UI flow, which is still treating the literal HEAD as a local branch name. Please release the merged fix or provide an updated build/timeline.

On it, folks! Sorry for the hold up, we're releasing this as soon as we can (should be today's regular Thursday release).