Feature request: supported local API to enqueue messages into existing desktop Codex threads

[shichenxi728]

Use case

I am building a personal local Python automation that observes incoming events and routes them to one persistent Codex thread per contact. I want those same threads visible in the desktop app so I can review drafts, add context, and take over manually. The automation and I need to contribute to the same conversation without forking it or quitting the desktop app.

What I tested

On macOS, using the desktop-bundled codex-cli 0.155.0-alpha.9.2:

1. A Python client launches codex app-server over stdio, creates a thread, and successfully runs its first turn.
2. The thread is opened in the desktop app.
3. The Python client launches a separate app-server and calls thread/resume for that thread.
4. Resume fails with code -32600: thread <redacted> already has an active writer.
5. Switching away from the thread in the desktop app did not resolve the failure in our immediate retest.
6. In contrast, the desktop assistant's own send_message_to_thread tool successfully appended a harmless test prompt to that same thread, and the model completed its response.

This suggests there is a working desktop-owned submission path, but I have not found a documented equivalent for an independent local Python process. I have not established whether the ownership behavior is intentional or a bug, and have not tested quitting the desktop app in this reproduction.

Related ownership report: #37403 . This request focuses on a supported local automation submission API, rather than bypassing the single-writer lock.

Requested capability

Please provide a documented local CLI/API that routes submissions through the desktop-owned runtime:

• Append an event to an existing thread by ID, preserving desktop visibility and history.
• Return a durable receipt/event ID, with an idempotency key to avoid duplicate submissions after a retry.
• Explicitly queue a new turn when a thread is busy, or return a clear retryable status. Do not silently interrupt or steer a human's active turn.
• Expose delivery and completion status and the final response, distinguishing accepted, queued, running, completed, and failed.
• Support model/reasoning selection and identify external automation events separately from human messages.
• Keep access local and user-authorized, with documented discovery, permission, and app shutdown/restart behavior.

The interface could be a CLI command, Unix socket, or SDK; I do not need a particular transport. I am not asking to disable writer ownership, manipulate session files, or depend on private desktop IPC.

Why it matters

Without a shared submission path, a successful event read can be followed by a failed thread resume. My automation needs its own durable outbox regardless, but retrying cannot solve a persistent ownership conflict. A desktop-owned queue would let local automations and a human collaborate in the same visible task without creating duplicate conversations.

If an existing supported interface already covers this workflow, a documented Python/CLI example would also resolve the request.