Forking conversations doesn't exist anymore in the past 6-7 versions of the mac desktop app

Open 💬 2 comments Opened May 1, 2026 by sldx

What version of the Codex App are you using (From “About Codex” dialog)?

26.429.20946 (2312)

What subscription do you have?

Pro

What platform is your computer?

Mac Sequoia

What issue are you seeing?

For the past 6-7 (if not more) of the Codex desktop app, I don't have the ability to fork conversations anymore. The fork button just does not appear on hover. Only Copy and the timestamp.

What steps can reproduce the bug?

Uploaded thread: 019de49d-e56c-7071-9c50-c02f245f838b

What is the expected behavior?

The fork conversation button should appear when hovering messages

View original on GitHub ↗

2 Comments

sldx · 3 months ago

Please somebody help 🙏

sldx · 3 months ago

Update with new findings

I've been digging into this more and found something that's probably related, but isn't the full story. Putting it here because it's a concrete bug regardless.

Finding: the bundled CLI in Codex Desktop is tagging every desktop-created thread as source: vscode.
I have _NEVER_ installed the VS Code extension. Every one of those vscode threads came from the desktop app.

Out of 623 threads in my ~/.codex/state_5.sqlite:

| source             | count                                      |
|--------------------|--------------------------------------------|
| cli                | 329 (from my standalone CLI install)       |
| vscode             | 265 (← all created from Codex Desktop)     |
| exec               | 29                                         |
| electron / desktop | 0                                          |

Looking at the session_meta line of a desktop-created rollout:

{
  "originator": "Codex Desktop",
  "cli_version": "0.128.0-alpha.1",
  "source": "vscode"
}

vs. one created from my standalone CLI:

{
  "originator": "codex-tui",
  "cli_version": "0.128.0",
  "source": "cli"
}

Root cause: in the desktop's workspace-root-drop-handler-*.js (inside app.asar), the env passed to the spawned bundled CLI is:

Ju = "Codex Desktop";
// ...
CODEX_INTERNAL_ORIGINATOR_OVERRIDE: e.defaultOriginator ?? Ju

So the desktop tells the CLI its originator is the human-readable string "Codex Desktop" (with a space). But the bundled CLI binary (0.128.0-alpha.1) only has originator → source mappings for codex_tui and codex_vscode — there's no codex_desktop literal anywhere in the binary. So "Codex Desktop" falls through to a default and the thread gets tagged source: vscode.

Why this might be related to the missing fork button: the per-message hover Fork button never renders for me, on any thread. I suspected it was gated on source != vscode, so I edited my DB to set a test thread's source to cli, then electron, then desktop. Each value persisted across relaunch (the desktop didn't overwrite it), but the fork button still didn't appear. So source alone isn't the gate — but the mistagging is real, and whatever the actual gate is may be reading from something downstream of source (or another field we're missing) on a thread the renderer thinks is a VS Code thread.

Other things ruled out:

Full reinstall of Codex Desktop with deletion of ~/Library/Application Support/Codex/ — bug persists.
Toggling skip-fork-from-older-turn-confirm and agent-mode in ~/.codex/.codex-global-state.json — no effect.

Repro details:

Codex Desktop v26.429.30905 (build 2345)
Bundled CLI: 0.128.0-alpha.1
Standalone CLI: 0.128.0
macOS 15.x (Darwin 24.6.0)
chatgpt_user_id: user-9lYuWbUM61GjDcHf9iF9C5zV — member of labs group, two orgs

Even if the fork-button gate turns out to be a separate Statsig flag on my account, the source: vscode mistagging is its own bug worth fixing — it'll show up in any analytics or behavior that branches on thread source.

Hope this helps