Summary
Codex Desktop exposes first-party dynamic tools such as codex_app.list_projects, codex_app.list_threads, and codex_app.navigate_to_codex_page to eligible model turns. A local Codex plugin/MCP application cannot call the same host capabilities directly, so it cannot build a deterministic project picker or open an exact existing Desktop thread without a model-mediated workaround.
Environment
- Windows Codex Desktop:
26.818.8289.0
- Bundled Codex CLI:
0.149.0-alpha.4.3
- Separate local plugin runtime: Codex App Server over stdio
Verified behavior
codex_app.list_projects in a Desktop task returns real project IDs, user-facing names, roots, and host IDs.- The same root can belong to multiple distinct Desktop project IDs, so cwd/root cannot be used as project identity.
- App Server 0.149 exposes
project/list and related project methods.
- A separate App Server process using the same
CODEX_HOME can read existing threads, but project/list returns an empty list and those threads have projectId: null.
- Plugin UI
window.openai.callTool can call the plugin's own MCP tools, but no documented API invokes first-party codex_app host tools.
- App Server does not expose an equivalent of Desktop thread activation/navigation.
thread/resume is not a Desktop navigation operation.
Requested capability
Please expose an authenticated local host bridge for supported Codex Desktop clients/plugins:
Read-only project catalog
desktop/project/list
Returns the same canonical Desktop project identity used by codex_app.list_projects, including at least hostId, projectId, name/label, roots, and repository status.
Activate an existing Desktop thread
desktop/thread/activate
Validates hostId, projectId, and threadId, then opens/focuses that existing task in the most recently focused Desktop window. It must not create, fork, resume, rename, archive, or send a message.
Security expectations
- Loopback or authenticated local transport only.
- Explicit host capability grant for plugins/clients.
- Project and thread identity consistency checks.
- Minimal metadata for list operations; no full history required.
- Clear unsupported/denied/not-found errors.
- No reliance on private Desktop databases or UI automation.
Why existing APIs are insufficient
Using project/import in every external App Server creates a second project registry that must be synchronized with Desktop. Asking a model turn to call codex_app for every picker refresh or navigation click is non-deterministic, consumes tokens, and mutates conversation history. Neither is a stable Desktop integration contract.
Summary
Codex Desktop exposes first-party dynamic tools such as
codex_app.list_projects,codex_app.list_threads, andcodex_app.navigate_to_codex_pageto eligible model turns. A local Codex plugin/MCP application cannot call the same host capabilities directly, so it cannot build a deterministic project picker or open an exact existing Desktop thread without a model-mediated workaround.Environment
26.818.8289.00.149.0-alpha.4.3Verified behavior
codex_app.list_projectsin a Desktop task returns real project IDs, user-facing names, roots, and host IDs.project/listand related project methods.CODEX_HOMEcan read existing threads, butproject/listreturns an empty list and those threads haveprojectId: null.window.openai.callToolcan call the plugin's own MCP tools, but no documented API invokes first-partycodex_apphost tools.thread/resumeis not a Desktop navigation operation.Requested capability
Please expose an authenticated local host bridge for supported Codex Desktop clients/plugins:
Read-only project catalog
desktop/project/listReturns the same canonical Desktop project identity used by
codex_app.list_projects, including at leasthostId,projectId,name/label, roots, and repository status.Activate an existing Desktop thread
desktop/thread/activateValidates
hostId,projectId, andthreadId, then opens/focuses that existing task in the most recently focused Desktop window. It must not create, fork, resume, rename, archive, or send a message.Security expectations
Why existing APIs are insufficient
Using
project/importin every external App Server creates a second project registry that must be synchronized with Desktop. Asking a model turn to callcodex_appfor every picker refresh or navigation click is non-deterministic, consumes tokens, and mutates conversation history. Neither is a stable Desktop integration contract.