›_ Codex Issues
Codex Issues / #37450

0.147-alpha (Windows): App keeps thread writer for every opened thread until full app exit; no attach path for external clients

Open 💬 3 comments Opened Aug 7, 2026 by imaximov
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

0.147-alpha (Windows): App keeps thread writer for every opened thread until full app exit; no attach path for external clients

Version: codex-cli 0.147.0-alpha.6.5 (Desktop App bundle), Windows 11 Pro 10.0.26200

Summary

Since 0.147 introduced single-writer thread persistence, codex exec resume <thread-id> fails with:

ERROR codex_core::session::session: failed to initialize thread persistence:
thread-store conflict: thread <id> already has an active writer
whenever the Desktop App has ever opened that thread in the current app run. The writer is not released when the user navigates away from the thread — only a full app exit (including the tray process) releases it.

Reproduction (verified step by step)

Open thread X in the Desktop App → codex exec resume X "hi" → thread-store conflict. Expected? Arguably yes.
Switch to a different thread in the App (thread X no longer displayed) → exec resume X → still conflict. Waiting several minutes does not help.
Close the App window, tray process still running → still conflict.
Fully quit the App (tray → exit) → exec resume X succeeds.
Expected: the writer for thread X is released when the App navigates away from it (or after a short idle period), so CLI/SDK automation can continue threads the user merely viewed.

Impact: any automation built on codex exec resume / the TypeScript SDK resumeThread() (e.g. local review loops that continue a long-lived thread) cannot run while the Desktop App is open if the target thread was viewed at any point. Users must fully restart the App before every automated turn.

Related gap (Windows): there is currently no way to avoid the conflict by attaching to the App as a client instead:

codex app-server daemon start and codex remote-control start → Error: codex app-server daemon lifecycle is only supported on Unix platforms
The Desktop App on Windows does not expose the control socket (~/.codex/app-server-control/app-server-control.sock is absent; no listening TCP port or named pipe from the codex processes).
Either releasing writers on thread switch or providing a Windows daemon/control socket (so external tools share the App's writer via the app-server protocol) would unblock this workflow.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 20 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37403

Powered by Codex Action

1063716500-sketch · 15 days ago

I can confirm the same active-writer behavior on Windows in a mobile Remote Control workflow, and it compounds the system-proxy problem described in #29958.

Environment observed during reproduction:

  • Windows 10 Pro 22H2, build 19045.6466, x64
  • Windows app package: 26.803.10989.0
  • Bundled app-server: codex-cli 0.147.0-alpha.6.6
  • Mobile client: iOS; version not present in the Windows host logs

Reproduction:

  1. Open an existing thread in the Windows desktop app.
  2. Run a second app-server/helper that accepts the already-paired mobile Remote connection.
  3. Open the same thread from iOS Remote and try to load or send a message.
  4. The Remote request reaches the helper, but thread/resume fails with:
failed to initialize thread persistence
thread-store conflict: thread already has an active writer
Failed to create session

The iOS UI then reports that the Codex server returned an error and cannot load or send messages. Fully exiting the Windows desktop app releases the conflict; with only the helper running, the same mobile thread works.

In this environment the helper exists only because the desktop Remote WebSocket does not reliably use the Windows system proxy. Therefore the workaround forces a mutually exclusive choice: keep the desktop UI open, or use mobile Remote, but not both.

Expected: either the desktop app should directly own the functioning Remote connection, or Desktop/Remote app-server instances should have a supported ownership handoff/attach path. A clear host-conflict error would also be preferable to the generic mobile “server returned an error.”

No raw databases, complete logs, pairing data, host IDs, thread IDs, usernames, project names, or tokens are included.

boombx403-byte · 9 days ago

Hi @imaximov, I'm testing a local-first, read-only diagnostic tool (Codex Rescue Alpha5) against local session persistence and rollout anomalies. It evaluates schema compatibility, tool correlation, and state consistency without modifying the original rollout or SQLite databases.

If the affected session is still present locally, you can run:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

No raw data is needed; please redact any private repository paths before sharing results.