Open in app allows two app-server processes to write the same rollout, merging divergent histories after restart

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

Codex App 26.707.72221 (bundle com.openai.codex)

Bundled app-server: codex-cli 0.144.2

What subscription do you have?

Pro 20x

What platform is your computer?

Darwin 25.3.0 arm64 arm

Chrome extension: ChatGPT 1.2.27203.26575

What issue are you seeing?

Starting a local Codex task from the ChatGPT Chrome extension and selecting Open in app leaves both the browser extension and Codex App able to continue the same thread.

The two surfaces use different app-server processes and maintain independent in-memory conversation histories, while both processes append to the same rollout JSONL under the same thread ID. lsof showed two different codex app-server PIDs holding writable file descriptors for that rollout at the same time.

Before restart, each surface only sees its own branch. After restarting Codex App, the rollout is replayed from disk and messages from both divergent branches appear merged into one conversation.

This is not Edge-specific: I first observed it with Edge and reproduced it with Chrome.

What steps can reproduce the bug?

1. Start a local Codex task from the ChatGPT Chrome extension.
2. Send one or more messages.
3. Select Open in app.
4. Continue sending messages independently from both Chrome and Codex App.
5. Ask each surface about the preceding messages. Each surface answers from a different conversation history.
6. Inspect the rollout with lsof. Two different app-server processes have writable file descriptors for the same rollout JSONL.
7. Restart Codex App.
8. Open the task again.
9. Messages from both previously divergent histories are now displayed as one merged conversation.

Observed thread ID:

019f63f5-db08-79a1-9b55-722fb497cc1a

Observed rollout:

$CODEX_HOME/sessions/2026/07/15/rollout-2026-07-15T12-08-04-019f63f5-db08-79a1-9b55-722fb497cc1a.jsonl

What is the expected behavior?

Open in app should perform an exclusive handoff. After the handoff, the browser surface should become read-only or stop its app-server session. Alternatively, both surfaces should attach to one shared runtime.

If concurrent attachment is unsupported, Codex should reject the second writer or fork it to a new thread ID and rollout file. Two processes should never independently append divergent histories to the same rollout.

Additional information

Archiving the task in Codex App also causes cross-surface inconsistencies: the browser process can remain active while the App considers the task archived, and a subsequent Open in app no longer reopens it normally.

A screenshot of the merged history after restarting the App is available. The text above describes the observable result because the issue template prefers text over screenshots.

Related issues, but none appears to cover the same two-writer/cold-replay behavior:

• #32793 reports process-local ownership allowing concurrent work across two app-server processes, but only for automatic goal continuation.
• #31114 reports concurrent lineages under one thread ID, but explicitly observed one process and one writer.
• #15320 states that concurrent clients on one thread are currently unsupported; in this reproduction, Open in app creates that unsupported topology without handing off, rejecting, or forking the original client.
• #14722 is the broader request for CLI/app-server session synchronization.
• #11907 covers archive and cross-surface refresh gaps.