What version of Codex is running?
- ChatGPT desktop app:
26.818.61809
- Desktop-bundled Codex runtime:
codex-cli 0.149.0-alpha.4.3
- Persistent Remote app-server:
0.149.1
What platform are you using?
- Host: macOS 26.5.2, Apple Silicon
- Client: ChatGPT iOS Remote Control (exact mobile app version was not captured)
What issue are you seeing?
A thread created and actively running in the macOS desktop app is visible in the iOS Remote thread list, including its title and changed-file summary. However, opening that thread on iOS fails with “Error loading messages.”
This is not a general connectivity failure:
- the Mac remains awake and online;
- the Remote persistent app-server is running;
- the control socket exists;
codex doctor reports the Remote WebSocket connected with HTTP 101 Switching Protocols;- the desktop-created thread remains visible in the iOS list;
- threads created from iOS Remote load normally.
At the exact time the iOS client attempted to open the desktop-created thread, the persistent Remote app-server repeatedly logged:
failed to initialize thread persistence: thread-store conflict: thread <redacted> already has an active writer
Failed to create session: thread-store conflict: thread <redacted> already has an active writer
The conflict was emitted repeatedly while the desktop app-server was the active writer for the same rollout file. The rollout file continued to grow normally on disk, and the state databases passed integrity checks, so there is no evidence that the thread data is missing or corrupt.
The Remote-side thread inventory reported the thread as notLoaded: metadata was available, but its messages could not be loaded.
Steps to reproduce
- On macOS, enable Remote Control and keep the Mac awake and online.
- Create a new local thread in the ChatGPT/Codex desktop app.
- Start a long-running turn so the desktop app-server remains the active writer.
- Open ChatGPT on iOS and go to Remote.
- Confirm that the desktop-created thread appears in the thread list.
- Open that thread while the desktop turn is still running.
- Observe “Error loading messages” on iOS.
- Inspect the persistent Remote app-server log and observe the
already has an active writer / Failed to create session errors.
Expected behavior
Remote should be able to display the history and live progress of a desktop-owned active thread without attempting to acquire a second writer.
If interaction requires writer ownership, Remote should either perform an explicit ownership handoff or enter a stable read-only/follower state. Merely opening an active thread for monitoring should not fail to load its messages.
This is also the behavior implied by the Remote documentation, which says existing chats on the connected host can be continued and reviewed from the phone:
https://learn.chatgpt.com/docs/remote-connections
Why this appears distinct
Together these reports suggest that Remote is trying to initialize writable thread persistence even when it only needs to read and display an active thread owned by another app-server.
Additional diagnostics
codex doctor also reported:
Background Server
app-server: running (persistent mode)
status: running
app-server version: 0.149.1
Connectivity
websocket: connected (HTTP 101 Switching Protocols)
There is a runtime-version difference between the desktop-bundled Codex runtime (0.149.0-alpha.4.3) and the persistent Remote app-server (0.149.1). I cannot establish whether that mismatch is causal, but it may be relevant to ownership/handoff behavior.
Privacy
The username, repository path, project name, exact thread ID, conversation contents, and raw logs are intentionally omitted. Sanitized diagnostics can be provided if maintainers need them.
What version of Codex is running?
26.818.61809codex-cli 0.149.0-alpha.4.30.149.1What platform are you using?
What issue are you seeing?
A thread created and actively running in the macOS desktop app is visible in the iOS Remote thread list, including its title and changed-file summary. However, opening that thread on iOS fails with “Error loading messages.”
This is not a general connectivity failure:
codex doctorreports the Remote WebSocket connected withHTTP 101 Switching Protocols;At the exact time the iOS client attempted to open the desktop-created thread, the persistent Remote app-server repeatedly logged:
The conflict was emitted repeatedly while the desktop app-server was the active writer for the same rollout file. The rollout file continued to grow normally on disk, and the state databases passed integrity checks, so there is no evidence that the thread data is missing or corrupt.
The Remote-side thread inventory reported the thread as
notLoaded: metadata was available, but its messages could not be loaded.Steps to reproduce
already has an active writer/Failed to create sessionerrors.Expected behavior
Remote should be able to display the history and live progress of a desktop-owned active thread without attempting to acquire a second writer.
If interaction requires writer ownership, Remote should either perform an explicit ownership handoff or enter a stable read-only/follower state. Merely opening an active thread for monitoring should not fail to load its messages.
This is also the behavior implied by the Remote documentation, which says existing chats on the connected host can be continued and reviewed from the phone:
https://learn.chatgpt.com/docs/remote-connections
Why this appears distinct
already has an active writerafter latest update #37403 reports the opposite handoff direction: a Remote/CLI-owned thread cannot be resumed by Desktop.Together these reports suggest that Remote is trying to initialize writable thread persistence even when it only needs to read and display an active thread owned by another app-server.
Additional diagnostics
codex doctoralso reported:There is a runtime-version difference between the desktop-bundled Codex runtime (
0.149.0-alpha.4.3) and the persistent Remote app-server (0.149.1). I cannot establish whether that mismatch is causal, but it may be relevant to ownership/handoff behavior.Privacy
The username, repository path, project name, exact thread ID, conversation contents, and raw logs are intentionally omitted. Sanitized diagnostics can be provided if maintainers need them.