Repository navigation
Chrome extension: stale active-writer lock prevents creating a chat #38876
Description
What issue are you seeing?
When using the ChatGPT/Codex app, sending a message in an existing chat can fail with this error:
Error creating chat
thread <thread-id> already has an active writer
The error blocks creating or continuing the chat. The thread ID has been redacted.
What steps can reproduce the bug?
- In the ChatGPT/Codex app, open an existing chat thread.
- Enter and send any message in that chat.
- Observe the
thread <thread-id> already has an active writererror. - Close the Codex Chrome extension window and retry sending a message.
- Observe that the error can persist after the extension window is closed.
What is the expected behavior?
The app should allow a message to be sent when no live writer remains. If another view is actively using the thread, the UI should identify that state and provide a way to recover without requiring the user to restart Chrome or abandon the chat.
Additional information
This was observed on macOS. Closing the Chrome extension window did not clear the lock.
Activity
github-actions commentedon Aug 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
zhyuzhyu commentedon Sep 23, 2026
Same root behavior on macOS + Microsoft Edge, with an archive-specific consequence.
Environment
Observed
A thread was opened from the Edge side panel. The extension-side app-server
(
~/.codex/plugins/.plugin-appserver/codex,client_name="codex-chrome-extension-sidepanel")held the writer lock:
This was still held after the side panel was closed via its header X.
The desktop app then could not archive that thread -- it showed "This is open in
another app" / "Close it there to continue here." That instruction was not
actionable:
Open in app,App settings, andEdge computer use settings. There is no archive action in the panel, so theuser cannot archive from the owning surface either.
Recovery required restarting the desktop app. During the incident the desktop app
auto-updated (26.915.31945 -> 26.917.51856), which replaced the extension-side
app-server and terminated pid 44879; the lock file then disappeared from
thread-writer-locks/, andthread/archivesucceeded (verified viaarchived=1/archived_atinstate_5.sqlite, with the rollout moved to~/.codex/archived_sessions/).Uncertainty
I have not isolated whether a plain desktop-app restart (without an auto-update)
also terminates the extension-side app-server. The observed release coincided
with an auto-update. If a plain restart does not, the remaining paths are
killing the extension-side app-server or waiting for the inactive-owner TTL --
and that TTL only runs while the panel page is still alive, so closing the panel
removes the last automatic release path.
Why archive makes this worse than create/send
For archive the deadlock is total: the only surface that can archive is the
desktop app, the panel cannot archive, and the panel does not release the lock
when closed.
Related: #45406, #46647, #38560, #33345