Summary
After updating the ChatGPT Desktop client on macOS on August 7, 2026, an existing workflow that previously worked stopped working:
- During off-hours, I use ChatGPT mobile Remote Control to continue a Codex CLI thread on my Mac.
- During the day, I open the same thread in the Desktop client and continue from there.
After the latest Desktop update, the Desktop/CLI handoff fails because the thread is reported as already having an active writer.
This appears to be a regression in thread ownership / writer handoff between the Desktop-bundled app-server/runtime and the CLI/Remote Control runtime.
Environment
- Platform: macOS (iMac)
- Standalone CLI:
- ChatGPT Desktop bundled Codex runtime:
/Applications/ChatGPT.app/Contents/Resources/codex --version
codex-cli 0.147.0-alpha.6.5
- The issue started immediately after installing the latest ChatGPT Desktop update on August 7, 2026.
- The same Remote Control / CLI / Desktop workflow worked before that update.
Steps to reproduce
- Keep Codex Remote Control enabled on the Mac.
- Use ChatGPT mobile Remote Control to open/continue a Codex CLI thread.
- Later, on the same Mac, try to resume/open that same thread from the Desktop client.
- Observe that the thread cannot be resumed because another writer is considered active.
Actual behavior
The resume attempt fails with an error like:
Failed to resume session from ~/.codex/sessions/YYYY/MM/DD/rollout-...jsonl:
thread/resume failed during TUI bootstrap:
thread/resume failed: thread <redacted-thread-id> already has an active writer (code -32600)
A key observation:
- With the Desktop client running, the thread hits the
already has an active writer conflict.
- If I fully quit the Desktop client, the same session can immediately be opened/resumed normally from the standalone CLI.
The session JSONL itself therefore appears intact; the problem looks like writer ownership/lifecycle rather than session corruption.
Expected behavior
Remote Control is intended to let the same work continue across mobile and desktop usage. A thread used through Remote Control / CLI should be able to hand off cleanly to Desktop when the user returns to the Mac.
Expected flow:
Mobile Remote Control / CLI thread
↓
user stops actively using mobile
↓
Desktop resumes the same thread
↓
ownership/writer handoff succeeds
The user should not need to disable Remote Control, kill app-server processes, fork the conversation, or create a new thread just to switch between mobile and Desktop.
Impact
This breaks a core daily workflow:
- Desktop during work hours
- Mobile Remote Control after work
- Same Codex thread/context across both surfaces
Because Remote Control needs to remain enabled, simply turning it off is not a practical workaround.
Regression evidence
The behavior changed immediately after the latest Desktop update. No CLI configuration or session files were changed at the time.
The standalone CLI and Desktop-bundled runtime are different builds:
Standalone: 0.147.0
Desktop bundled: 0.147.0-alpha.6.5
This may be related to stricter single-writer enforcement without a corresponding Desktop ↔ Remote Control ownership handoff.
Privacy note
The local username, exact session path, thread ID, repository/project names, and conversation contents are intentionally omitted. I can provide additional sanitized diagnostics if maintainers request them.
Summary
After updating the ChatGPT Desktop client on macOS on August 7, 2026, an existing workflow that previously worked stopped working:
After the latest Desktop update, the Desktop/CLI handoff fails because the thread is reported as already having an active writer.
This appears to be a regression in thread ownership / writer handoff between the Desktop-bundled app-server/runtime and the CLI/Remote Control runtime.
Environment
Steps to reproduce
Actual behavior
The resume attempt fails with an error like:
A key observation:
already has an active writerconflict.The session JSONL itself therefore appears intact; the problem looks like writer ownership/lifecycle rather than session corruption.
Expected behavior
Remote Control is intended to let the same work continue across mobile and desktop usage. A thread used through Remote Control / CLI should be able to hand off cleanly to Desktop when the user returns to the Mac.
Expected flow:
The user should not need to disable Remote Control, kill app-server processes, fork the conversation, or create a new thread just to switch between mobile and Desktop.
Impact
This breaks a core daily workflow:
Because Remote Control needs to remain enabled, simply turning it off is not a practical workaround.
Regression evidence
The behavior changed immediately after the latest Desktop update. No CLI configuration or session files were changed at the time.
The standalone CLI and Desktop-bundled runtime are different builds:
This may be related to stricter single-writer enforcement without a corresponding Desktop ↔ Remote Control ownership handoff.
Privacy note
The local username, exact session path, thread ID, repository/project names, and conversation contents are intentionally omitted. I can provide additional sanitized diagnostics if maintainers request them.