Support external-origin callers for Desktop native task messaging

What variant of Codex are you using?

Codex Desktop on macOS, version 26.908.40834 (build 8881); bundled CLI 0.154.0-alpha.6.2.

What feature would you like to see?

A documented, opt-in, capability-scoped way for an external coding agent or MCP integration to request the existing Desktop codex_app.send_message_to_thread operation against an exact original task. The user should be able to install the integration and coordinate between ordinary agents without keeping a manually operated forwarding task open.

An automatically managed, app-authorized ephemeral helper would also work if its startup/teardown and quota/latency costs are supported and visible. A model call is an acceptable implementation detail; a user-operated relay is not the desired workflow.

Could you clarify whether Desktop exposes a supported app-owned control endpoint for codex app-server proxy, and whether mcpServer/tool/call may invoke the app-configured codex_app.send_message_to_thread with legitimate thread/turn authority? If another extension or caller entitlement is intended, please document its provisioning and lifecycle.

The interface should keep account credentials inside the app, authorize the exact task/host, distinguish the actual native helper principal from the authenticated external source, preserve native active-turn behavior without interrupting a running command, and define receipts, cancellation and uncertain outcomes. Please state whether independently launched CLI/TUI recipients are eligible; they should not silently be treated as Desktop tasks. A stable event/idempotency contract would help integrations avoid replay after uncertain delivery.

Additional information

A controlled app-hosted task previously demonstrated the desired native behavior: the original target acknowledged the built-in message during its active turn while its original command continued and later completed naturally. That proves a Desktop capability, not an external integration.

A prior standalone app-tools client was rejected on read-only tools/list with untrusted-code-signing-identity, before any native send. That check was not bypassed or retried. Current read-only checks found no running endpoint at the default managed AppServer control socket; the inspected Desktop backends use stdio. Task deep links only prefill/navigation in this build, without automatic submission. These are bounded observations, not a claim that every legitimate entry point is unavailable.

The public App Server reference documents mcpServer/tool/call and generic turn operations, but we did not find the supported Desktop authorization/provisioning contract needed here. Generic turn/steer, injected tool-output lookalikes, and Stop/queue fallback do not establish invocation of the actual Desktop operation. We are requesting a supported path, not a way around signature or account checks.

Related but distinct: #42973 concerns missing task tools for Desktop SSH callers. This request concerns automatically provisioned external-origin callers on a Desktop host. No private task IDs, conversations, credentials, addresses, local paths, or raw logs are included.

Start with the public App Server reference, especially mcpServer/tool/call, and inspect the Desktop backends that the report says use stdio. Define whether a supported external-origin path exists, including authorization, provisioning, lifecycle, receipts, cancellation, and eligibility of CLI/TUI recipients. Done means the supported contract is implemented and documented, or the request is explicitly documented as unsupported.