Codex App branch switch uses a different worktree than the task terminal

The exact same issue is happening for me. When I create a new chat with worktrees enabled, a new worktree gets created and the agent operates in it. But the UI widget shows the default worktree's state, and the "Create and checkout new branch" action in the widget operates on the default worktree instead of the actually active one. It started happening after the latest update.

Codex version 26.803.41515, macOS Tahoe 26.5

Not sure about the bug, but this is how I "fixed" the issue.
The section below was written by ChatGPT.

---

The task terminal was correctly running in a managed worktree on the feature branch, but the Environment/branch UI resolved the saved repository checkout instead. In my case, the task metadata and terminal pointed to the OCR worktree and codex/ocr/main, while the UI showed the main checkout and 1.15.2/master. The worktree itself was registered correctly in git worktree list.

What fixed it was re-binding the task through the handoff workflow:

1. Hand the task off to the local checkout.
2. Hand the resulting task back to Local again, which makes Codex reuse the existing managed worktree and re-associate the feature branch.
3. Verify that the task metadata, terminal, and UI all point to the same worktree.

I did not delete or recreate the worktree, and I did not manually move the branch. The handoff preserved the existing uncommitted change. This suggests a stale task-to-worktree association after resume/reconnect; I cannot confirm the underlying cause, but forcing the local-checkout -> managed-worktree rebind cleared it.

This is what Codex came up with when I sent it to investigate:

Status: DONE_WITH_CONCERNS — the release and faulty path are high-confidence; the desktop UI’s original TypeScript source is not public, so I cannot name its internal source commit.

Conclusion

The regression was introduced in Codex desktop 26.803.41515, published August 7, 2026. The immediately preceding production release, 26.730.61639, does not contain the triggering behavior.

The bug is in the desktop renderer’s new “follow an existing thread owner” resume flow—not Git and probably not the open-source Rust app-server.

| Desktop release | Embedded Codex | Relevant behavior |
|---|---:|---|
| 26.730.61639 | 0.147.0-alpha.1.2 | Normal thread hydration |
| 26.803.41515 | 0.147.0-alpha.6.5 | Adds followExistingOwner: true and the faulty early return |
| 26.803.61601 | 0.147.0-alpha.6.5 | Still contains the bug |

This matches the symptoms and version reported in [issue #37591](https://github.com/openai/codex/issues/37591).

Actual cause

The new release changed automatic task resume to send:

maybeResumeConversation({
  // ...
  followExistingOwner: true,
});

When another renderer already owns the task, the resume manager now:

const owner = await findThreadOwner(...);

setConversationStreamRole(threadId, {
  role: "follower",
  ownerClientId: owner,
});

conversation.resumeState = "resumed";
return;

That return happens before the normal thread/read, thread/resume, CWD reconciliation, environment hydration, and workspace-state synchronization.

Consequently:

• The existing owner and task terminal remain attached to the correct managed worktree.
• The newly opened follower renderer retains the CWD loaded from its local thread catalog or default project assignment.
• The branch/environment widget uses that stale renderer state.
• Git commands therefore run against the default or an older worktree and report that the branch is already checked out elsewhere.

The exact new call is visible in the extracted current bundle at [/private/tmp/use-resume.js](/private/tmp/use-resume.js). The preceding release’s equivalent bundle, [/private/tmp/use-resume-prev.js](/private/tmp/use-resume-prev.js), has no followExistingOwner field or owner-discovery shortcut. The early-return implementation is readable in [/private/tmp/chatgpt-app-initial.pretty.js:160660](/private/tmp/chatgpt-app-initial.pretty.js:160660).

That explains all the distinctive observations:

• terminal and branch switcher disagree;
• restarting briefly repairs the UI;
• reconnecting makes it wrong again;
• a local-to-local handoff repairs the association.

A second, latent CWD bug

Both releases also contain this approximate resolver:

const persisted = responseCwd || threadCwd;

return requestedCwd &&
  persisted &&
  isEqualOrDescendant(requestedCwd, persisted)
    ? requestedCwd
    : persisted || requestedCwd || fallbackCwd;

For sibling managed worktrees such as:

requested: ~/.codex/worktrees/7e31/WantPic
stored:    ~/.codex/worktrees/WantPic

the requested directory is not a descendant of the stored directory, so the stale stored directory wins. I reproduced that result directly.

This logic predates 26.803.41515, so it did not create the release boundary, but it can reinforce the same failure during a full resume.

There is also a relevant newer open-source change, [#37198](https://github.com/openai/codex/commit/547080e4d690cdeea12f427a8d9c5165928821ed), which explicitly allows ThreadResumeResponse.thread.cwd to be a persisted CWD while the top-level cwd is the live resumed CWD. That commit was first included in 0.148.0-alpha.1 and was not in the affected 26.803.41515 build, so it is not the original cause. It does, however, make it especially important that the desktop stops treating those two fields as interchangeable. The dual fields are visible in [thread.rs](/Users/cztamas/dev/tools/codex/codex-rs/app-server-protocol/src/protocol/v2/thread.rs:405), and the live response CWD is populated in [thread_processor.rs](/Users/cztamas/dev/tools/codex/codex-rs/app-server/src/request_processors/thread_processor.rs:3462).

Suggested fix

The primary fix belongs in the desktop follower-adoption flow:

1. After discovering an existing owner, request and install the owner’s complete task snapshot before marking the follower resumed.
2. That snapshot must include the canonical active CWD, applied worktree assignment, environments, Git metadata, and runtime workspace roots.
3. Only then set the renderer to follower and return.
4. Branch actions must resolve their Git root from that canonical active CWD—the same value used by the terminal—not from the catalog/default project.

A safe short-term hotfix is to remove followExistingOwner: true until follower workspace synchronization is implemented.

The CWD resolver should also be separated by phase:

// Before resume: an explicit task/worktree selection wins.
const resumeCwd =
  requestedCwd ??
  persistedThreadCwd ??
  fallbackCwd;

// After resume: the app-server's live response is authoritative.
const activeCwd =
  responseCwd ??
  requestedCwd ??
  persistedThreadCwd ??
  fallbackCwd;

thread.cwd should be treated as persisted metadata, not an equivalent alternative to the top-level live response.cwd.

The regression test should create two sibling worktrees, seed stale catalog/thread metadata, open a second renderer as a follower, and assert that terminal CWD, environment CWD, Git root, and branch-switch command CWD all remain the managed task worktree after repeated reconnects.

No repository files were changed. One limitation is structural: OpenAI documents the CLI and app-server as open-source components, but the full desktop renderer is not part of the repository, so the desktop finding came from comparing the signed application bundles rather than source history. [OpenAI’s component list](https://learn.chatgpt.com/docs/open-source) confirms the public repository boundary.