Codex Desktop should allow terminal-launched context to reuse the active thread
Open 💬 3 comments Opened Jun 17, 2026 by furkancak1r
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
When Codex Desktop is already open on a thread, launching or handing context from a terminal with environment-variable scoped setup opens a new chat/thread instead of reusing the currently open conversation.
This is disruptive when the terminal setup is meant to apply to the active conversation.
Environment
- OS: Windows
- Surface: Codex Desktop app
- Trigger: terminal-launched Codex / app deep-link style flow with environment variables or command context
- Codex version: 26.611.61753 (released 17 Jun 2026)
Current behavior
- A thread is already open in Codex Desktop.
- I open/use a terminal and pass environment variables or related launch context.
- Codex Desktop starts a new chat/thread instead of applying the context to the currently open thread.
Expected behavior
Codex Desktop should provide one of these:
- a setting to reuse the currently active/open thread for terminal-launched submissions, or
- a documented CLI/deep-link/API path to target the currently active thread, or
- a clear prompt asking whether to use the active thread or create a new one.
Notes
The documented deep links cover codex://threads/new / codex://new?... for new threads and codex://threads/<thread-id> for opening an existing thread, but I could not find a documented setting that prevents this flow from creating a new thread or sends the terminal-provided context to the active Desktop thread.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Reviewed #28650. It is related, but I do not think this is a duplicate.
#28650 asks for exposing a thread automation tool inside Codex App sessions. This issue is narrower: terminal-launched / deep-link / environment-scoped context from Windows Codex Desktop opens a new thread instead of offering a supported way to target or reuse the currently active Desktop thread.
There are the docs for all of the existing deep links:
By my read of it, what this issue is basically asking for is a new deep link (or a variation of an existing one) that would allow sending a 'message' into an existing thread.
codex://threads/<thread-id>seems like the best starting place; and then following existing patterns, it should probably support something like?<query>, withprompt=<text>.So basically:
codex://threads/<thread-id>?<query>codex://threads/<thread-id>?prompt=<text>That would seem to match all of the existing semantics.
---
Another potential variation would be "I don't know the thread ID, but I want the one currently open in my Codex Desktop window", which seems fair enough, though one potential complicating edge-case for that would be "how does this work when there are multiple Codex Desktop windows open" (eg. I currently have 30 open)
---
Edit: I opened a separate issue for the related-but-distinct URL/deep-link window-targeting concern:
That issue is about giving
codex://deep links / protocol URLs an explicit way to choose where the target opens, such as reusing an existing window vs opening a new independent Codex Desktop window. It is a separate concern from sending a prompt/message into a thread, but it highlights a related ambiguity for this issue: if a URL/API call is meant to reuse an existing Codex window, and multiple Codex windows are open, how does Codex decide which window is the target unless the caller can be explicit about it?