Codex Desktop: request an authorized local bridge for project catalog and thread activation

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

1. codex_app.list_projects in a Desktop task returns real project IDs, user-facing names, roots, and host IDs.
2. The same root can belong to multiple distinct Desktop project IDs, so cwd/root cannot be used as project identity.
3. App Server 0.149 exposes project/list and related project methods.
4. 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.
5. Plugin UI window.openai.callTool can call the plugin's own MCP tools, but no documented API invokes first-party codex_app host tools.
6. 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.