What variant of Codex are you using?
Codex App and the Codex App Server API.
What feature would you like to see?
Please add a supported App Server API for registering a live external agent session as a child of a Codex thread, so that it appears in the Codex App Subagents panel alongside native Codex subagents.
Today the App Server exposes thread creation, forking, status events, descendant lifecycle behavior, and experimental parent/ancestor filters. However, the documented API does not provide a way for an external agent runtime to:
- register an existing live session under a parent Codex thread;
- identify it as an external subagent with display name and provider/runtime metadata;
- update its lifecycle state such as running, completed, failed, or cancelled;
- append bounded progress and final-result records; or
- map a cancellation request from Codex back to the external runtime.
A possible API shape could be an externalAgent/register method, or a supported thread/start variant with fields such as parentThreadId, an external-subagent source kind, external session ID, display metadata, and lifecycle callbacks/events.
The important part is that this should be a real integration contract, not a wrapper that launches a second Codex agent merely to mirror another agent. A wrapper adds model tokens, latency, coordination work, and extra failure modes only to obtain UI visibility.
Additional information
The concrete use case is Aiterm, a persistent MCP terminal that can launch and manage coding-agent sessions such as Codex, Grok, and Composer. Aiterm already owns the external process/session identity and lifecycle events. With a supported registration API, it could map those sessions into the Codex parent thread and Subagents panel without adding another reasoning agent in the middle.
This would also give other agent orchestrators, ACP adapters, IDE integrations, and local multi-agent runtimes a clean way to participate in the Codex App UI while keeping execution ownership in the originating runtime.
This is distinct from importing external-agent configuration or historical chats. Import is a migration operation; this request is for live registration, lifecycle synchronization, and parent-child presentation.
Relevant documentation:
What variant of Codex are you using?
Codex App and the Codex App Server API.
What feature would you like to see?
Please add a supported App Server API for registering a live external agent session as a child of a Codex thread, so that it appears in the Codex App Subagents panel alongside native Codex subagents.
Today the App Server exposes thread creation, forking, status events, descendant lifecycle behavior, and experimental parent/ancestor filters. However, the documented API does not provide a way for an external agent runtime to:
A possible API shape could be an
externalAgent/registermethod, or a supportedthread/startvariant with fields such asparentThreadId, an external-subagent source kind, external session ID, display metadata, and lifecycle callbacks/events.The important part is that this should be a real integration contract, not a wrapper that launches a second Codex agent merely to mirror another agent. A wrapper adds model tokens, latency, coordination work, and extra failure modes only to obtain UI visibility.
Additional information
The concrete use case is Aiterm, a persistent MCP terminal that can launch and manage coding-agent sessions such as Codex, Grok, and Composer. Aiterm already owns the external process/session identity and lifecycle events. With a supported registration API, it could map those sessions into the Codex parent thread and Subagents panel without adding another reasoning agent in the middle.
This would also give other agent orchestrators, ACP adapters, IDE integrations, and local multi-agent runtimes a clean way to participate in the Codex App UI while keeping execution ownership in the originating runtime.
This is distinct from importing external-agent configuration or historical chats. Import is a migration operation; this request is for live registration, lifecycle synchronization, and parent-child presentation.
Relevant documentation: