[macOS][Remote iOS] Desktop-created active threads are listed but fail to load due to an active-writer conflict

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

1. On macOS, enable Remote Control and keep the Mac awake and online.
2. Create a new local thread in the ChatGPT/Codex desktop app.
3. Start a long-running turn so the desktop app-server remains the active writer.
4. Open ChatGPT on iOS and go to Remote.
5. Confirm that the desktop-created thread appears in the thread list.
6. Open that thread while the desktop turn is still running.
7. Observe “Error loading messages” on iOS.
8. 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

• #37403 reports the opposite handoff direction: a Remote/CLI-owned thread cannot be resumed by Desktop.
• #40167 reports an active CLI thread that cannot be displayed on iOS Remote.
• This report confirms the Desktop-app-to-iOS direction with a desktop-bundled app-server as the active writer, while the iOS client can still list the thread metadata.

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.