[Feature]: Release a Codex thread on demand so Codex Desktop / CLI can resume it

[bricelb]

What I'm trying to do

I use T3 Code (background service on macOS, reached from the iOS app over Tailscale) alongside the Codex app in ChatGPT Desktop and the Codex CLI. All three share the same ~/.codex home, so a Codex thread started in one shows up in the others. That is great for picking up a long Codex conversation from my phone.

What happens

As soon as a Codex thread is opened in T3, the T3 server spawns its own codex app-server and holds that thread. ChatGPT Desktop then shows "Conversation opened in another application — close it there to continue here" and refuses to continue it (only "Retry" or "Duplicate chat").

Quitting the T3 desktop app and the iOS app does not help, because the background service keeps the provider session alive. The only ways I found to get the thread back in Codex:

• wait for the idle release (DEFAULT_IDLE_TIMEOUT_MS, 30 min, in ProviderSessionManager.ts), or
• run t3 service restart, which interrupts every T3 thread on that host.

t3 thread only has list, start, send and show, so there is no way to release a single thread.

In practice this means a long-running Codex thread with a lot of context can't be shared between T3 and Codex without either duplicating it or restarting the whole service, which removes much of the value of driving existing Codex work from T3.

Proposal

Any of these would solve it:

1. A "Release session" action on a thread (desktop, web and mobile) that closes its provider session right away, so another Codex client can take over. The next T3 turn would resume it as it does after an idle release.
2. A CLI equivalent, e.g. t3 thread release <thread-id>.
3. A configurable idle timeout (for example in service.env), so users who switch between clients can shorten the 30 minutes.

It would also help to show in the thread UI that T3 currently holds the provider session, so it's clear why Codex reports the conversation as open elsewhere.

Environment

• T3 Code 0.1.7, background service (t3 service install) on macOS, desktop app with Local environment off, iOS app
• Codex CLI 0.167.0 and the Codex app in ChatGPT Desktop, sharing the default ~/.codex

[Sauzze]

+1 from the Claude Code side. Same situation: T3 keeps the thread's claude --resume=<id> process alive for up to 30 minutes after the last turn. Claude Code doesn't lock the session, so a terminal claude --resume <id> opens with no warning. In my test that forked the JSONL, and the terminal turn was then silently dropped from context. A t3 thread release <threadId> that returns once the process has exited would fix it for both providers. I wrote up a CLI-only proposal (import one session by id, plus release) here: #6873 (comment).