Rank, 14 days: 27 on the Codex sheet
25 people reported

All time, since Sep 17, including 13 thumbs-up on GitHub.

Conversation writer lock blocks continuing

“thread-store conflict: thread <redacted> already has an active writer”

Is this your bug? What gets counted gets fixed. Pile on.

Paste this into your agent. It files your report, with your error and version.

I hit this bug: rapsheet.dev/sheets/codex/themes/191/file
Follow it to file my report. Show me the text before you send.

No install. No account. Public and anonymous. The link asks your agent for one report, nothing else. What it sends

Fading. 2 reports and thumbs-up in the last 7 days and 7 the week before.

5 bugs in this theme

  1. Conversation locked by another appHas a workaround11 people
  2. Mobile conversation stays lockedHas a workaround5 people
  3. Conversation locked after exitHas a workaround5 people
  4. Active writer conflictHas a workaround4 people
  5. Active-writer resume not retriedNo workaround yet2 people

What's included

  • Remote or mobile client (Windows, iPhone, ChatGPT mobile) cannot continue a host conversation; Retry does not clear the "open in another app" banner
  • Lock persists after the other client exits, finishes its turn, or is closed (CLI exit, iOS app closed, phone off)
  • "thread-store conflict: already has an active writer" (-32600) on thread/resume from Desktop, VS Code Remote SSH reconnect, or a competing app-server
  • Forking a conversation keeps the original locked; --no-daemon resume blocked by idle daemon lock
  • Queued follow-ups stay paused, or resume stops retrying after a transient writer conflict

Not included

  • Device pairing failures for Remote that never show the conversation
  • Chats hanging mid-turn for reasons other than the writer lock

Original reports12, newest first

  1. [macOS Desktop 26.1023] Follow-ups stay paused after transient thread writer conflict; resume helper does not retryOn GitHub#58055
  2. [macOS][0.164.0] Completed CLI thread stays locked in Desktop after exit; agents Stop offers no handoffOn GitHub#57004
  3. [Remote][macOS → Windows] Paired client can read chats but cannot continue them: “open in another app” / active writer conflictOn GitHub#56936
  4. [Windows][Desktop Remote SSH] Disconnect leaves conversation writer owned by managed daemon; local Desktop unblocks only after codex app-server daemon stopOn GitHub#56797
  5. [macOS Desktop] Transient active-writer conflict stops resume retries and offers fork despite original recovering seconds laterOn GitHub#56751
  6. [0.163.0][WSL2] Idle daemon locks block --no-daemon recovery; misleading "another app" error and no "Switch here"On GitHub#54738
  7. [macOS] SSH-started app-server competes with Desktop Remote Control, causing persistent active-writer conflicts for an idle threadOn GitHub#52675
  8. [Windows][iOS Remote] Conversation started on iPhone remains locked in Desktop after iOS app is closedOn GitHub#51429
  9. [VS Code Remote SSH] Reconnect hides a live thread behind 'another app' lock with no read-only history or handoffOn GitHub#46936
  10. Regression: resumed conversations are single-writer locked across windows and machinesOn GitHub#46652
Show all 12Show only the newest 10
  1. [CLI][Remote] “Close it there” is impossible from mobile and does not identify the writer-lock ownerOn GitHub#46647
  2. Fork won't release the lock on the original conversationOn GitHub#46355

Do you work on Codex?

Claim its RAP Sheet to see what your users report and answer them in one place.