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

What version of the IDE extension are you using?

26.908.31748 (auto-updated today from 26.901.22334 -> 26.908.40401 -> 26.908.31748)

What subscription do you have?

Plus

Which IDE are you using?

VS Code 1.132.0

What platform is your computer?

Linux 7.0.0-31-generic x86_64

What issue are you seeing?

When a thread is open in the panel, it holds a live OS-level write lock (confirmed with lsof / flock -n), which correctly blocks codex exec resume <id> from the CLI with:

thread already has an active writer (code -32600)

This makes sense as protection against concurrent writers. But there's no supported way to hand off or release that lock intentionally - e.g. to let a CLI automation drive a thread the user was previously working on in the panel, without corrupting it. Is there a planned mechanism for this (explicit release/handoff), or is "one thread = one interface at a time, permanently" the intended model?

What steps can reproduce the bug?

1. Open an existing Codex thread in the VS Code panel (Chats list) - leave it open.
2. From a terminal, use the extension's own bundled CLI binary
   (.../openai.chatgpt-/bin/linux-x86_64/codex) to run:
   codex exec resume "any prompt"
3. Observe the command fails with:
   thread already has an active writer (code -32600)
4. Confirm at the OS level this is a genuine active lock, not a stale one:
   • ls -la ~/.codex/thread-writer-locks/.lock exists
   • lsof shows the extension's app-server process holding
     an open FD on it with the write-lock flag (e.g. "43uW")
   • flock -n -c 'echo got it' fails to acquire it
5. There is no command/menu option in the panel to release, share, or hand
   off that lock to let a CLI process drive the same thread.

What is the expected behavior?

Either:
(a) the panel exposes some explicit way to release/hand off a thread's
write lock so a CLI process (e.g. an automation or a second tool) can
take over driving it intentionally, without corrupting history, or
(b) if "one thread = one writer for its entire open lifetime" is the
intended permanent model, documentation/error messaging should say so
explicitly, so it's clear this isn't a bug or a stuck/stale lock -
right now the error message alone doesn't distinguish "temporarily
busy, retry" from "permanently locked until you close the panel."

Additional information

Extension auto-updated during this investigation: 26.901.22334 -> 26.908.40401 -> 26.908.31748, all within the same day. Behavior was consistent across all three versions - this does not appear to be a regression tied to a specific build.

codex-cli 0.154.0-alpha.6.2, VS Code 1.132.0, Linux 7.0.0-31-generic x86_64.

Start by reproducing the conflict with the bundled codex exec resume command while the thread is open in the VS Code panel. Inspect ~/.codex/thread-writer-locks/.lock and the app-server writer-lock behavior using lsof and flock. Done means establishing the intended handoff or lifetime model and providing the corresponding panel behavior or documentation and error messaging.