No thread works both in the panel and via CLI at the same time (writer-lock vs. panel-visibility conflict) #45406

Activity

1. mrehan37

   added

   extensionIssues related to the VS Code extensionIssues related to the VS Code extension

   on Sep 14, 2026
2. github-actions

   added

   enhancementNew feature or requestNew feature or request

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   execIssues related to the `codex exec` subcommandIssues related to the `codex exec` subcommand

   on Sep 14, 2026
3. github-actions commented on Sep 14, 2026

   

   github-actionsBot

   on Sep 14, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Remote Control: threads viewed in the iOS app stay locked in the daemon, desktop fails with "already has an active writer" #44449

   Powered by Codex Action
4. abruption commented on Sep 15, 2026

   

   abruption

   on Sep 15, 2026

   More actions

   Proposal: owner-cooperative release and handoff for live thread writers

   I investigated this together with the related Remote Control case in #44449 and
   several real lock holders on macOS. The important distinction is that these are
   usually live kernel locks held by a legitimate Codex process, not stale lock-file
   residue. Deleting <thread-id>.lock cannot release such a lock and can make the
   state harder to reason about.

   Current main already has most of the safe owner-side lifecycle machinery:

   • WriterLockCoordinator uses a real nonblocking OS lock and removes only
     unlocked stale files.
   • thread/unsubscribe removes a connection's subscription.
   • an unsubscribed, inactive thread is flushed, shut down, removed, and emits
     thread/closed after thread_unload_delay_secs (60 seconds by default, zero
     for immediate unloading).

   What appears to be missing is an explicit, observable handoff contract between
   products/processes. I suggest building that contract around cooperative release
   by the process that owns the writer, rather than allowing another process to
   delete files or kill the owner.

   1. Owner-side release operation

   Either add an optional immediate mode to thread/unsubscribe, or introduce a
   small thread/release operation. A possible request is:

   {
     "threadId": "...",
     "mode": "ifIdle"
   }

   The response should be structured rather than inferred from an error string:

   released | busy | subscribersRemain | notLoaded | notOwner
   

   ifIdle should release only when the owning app-server can prove that:

   • there is no active turn, delegated work, pending tool call, or elicitation;
   • the requesting connection is unsubscribed and no other subscriber still
     requires the loaded runtime;
   • pending rollout items have been flushed and the recorder shuts down cleanly.

   Only then should it remove the runtime and drop WriterLockGuard. The existing
   thread/closed notification can be the acknowledgement that ownership was
   actually released. A contender should retry thread/resume only after that
   acknowledgement.

   2. Product lifecycle integration

   • The panel should expose an explicit Release / Hand off action for an idle
     thread.
   • Remote Control clients should unsubscribe when the view is closed, backgrounded,
     or disconnected, and viewing history alone should not keep unrelated threads
     resumed indefinitely.
   • Reconnection should restore subscriptions only for threads the client is
     actually observing or running, rather than every recently viewed thread.

   This directly addresses #44449 without weakening single-writer protection.

   3. Structured conflict diagnostics

   When thread/resume encounters a live writer, its JSON-RPC error data could
   include non-sensitive fields such as:

   {
     "threadId": "...",
     "reason": "liveWriter",
     "ownerKind": "cli | appServer | remoteControl | unknown",
     "retryable": true,
     "suggestedAction": "releaseInOwner"
   }

   PID, command line, TTY, and cwd are useful for an opt-in local diagnostic command,
   but probably should not be exposed in normal protocol errors. Lock-file presence
   alone must never be reported as proof of a live owner; the OS lock probe and
   process metadata are separate evidence.

   4. Suggested regression coverage

   1. An active turn refuses ifIdle release and keeps its writer lock.
   2. An idle final subscriber can release; the rollout is flushed and unchanged
      after shutdown.
   3. Other subscribers prevent release.
   4. Remote disconnect/backgrounding releases idle threads instead of retaining
      every previously viewed thread.
   5. A second app-server initially receives a conflict, waits for thread/closed,
      then resumes successfully.
   6. Crash residue is removed only when a real nonblocking lock probe succeeds.

   An incremental first step could be the owner-side ifIdle release plus structured
   conflict data; panel and Remote Control affordances could then use the same
   protocol without changing the lock's safety model.
5. peixotorms commented on Sep 22, 2026

   

   peixotorms

   on Sep 22, 2026

   More actions

   This is an example of something unnecessary. It should just takeover and thats it.
6. HenryFone commented on Oct 1, 2026

   

   HenryFone

   on Oct 1, 2026

   More actions

   Windows data point that may be useful for the release/handoff discussion here (Desktop 26.924.22138, CLI 0.158.0-alpha.2.1):

   • The desktop app holds %USERPROFILE%\.codex\thread-writer-locks\<thread-id>.lock for every thread it has loaded, and keeps holding it long after the thread is idle in the UI. A second process gets the -32600 active-writer conflict, exactly as reported.
   • The lock file is opened with FILE_SHARE_DELETE, so a non-owner can rename the canonical name away while the owner keeps its handle. After renaming, an archive of that idle thread through the bundled CLI succeeded immediately (verified exit 0, DB and archived_sessions consistent, reversible via unarchive).
   • I am deliberately not proposing rename-based takeover for resume/handoff: for a thread that might actually be written, only the owner can know whether it is idle, and letting a second writer in would defeat the lock. I only used the rename as a stopgap for the archive path on provably idle threads.

   That is why I think the owner-side ifIdle release plus structured conflict diagnostics you outlined is the right shape: a contender's lock probe cannot distinguish "live owner, idle thread" from "live owner, active turn", and today no supported request lets an owner drop the lock on demand.

   For anyone stuck on the archive path meanwhile, I put the rename + official CLI (archive/unarchive/delete) flow in a small stdlib-only local tool: https://github.com/HenryFone/codex-archive-manager (Windows 11 + 26.924 tested; 127.0.0.1 only; never edits the SQLite DB itself). Untested on Linux/macOS, and it does not implement resume or handoff.
7. abreza commented on Oct 8, 2026

   

   abreza

   on Oct 8, 2026

   Last edited by abreza

   More actions

   Please add a read-only “Follow CLI” mode to the VS Code extension, showing live progress, tool output, and diffs from a CLI session running in background or tmux. The CLI should remain the sole writer, and closing the extension should not interrupt its work.
8. mrehan37 commented on Oct 12, 2026

   

   mrehan37

   on Oct 12, 2026

   Last edited by mrehan37

   Author

   More actions

   Queue helps,

   i used claude to give codex the prompt/instructions so the lock thing effect me and thats why i made this thread but the same day i got the solution that queue can help, even for nomal message when the chat is not doing anything you just use the queue function cuz without queue you cant directly add anything to the chat, so tell your ai or update the scripts of yours to QUEUE everything it wanna send to the codex, by this way you can quue multiple commands