Live peer-client co-presence on Codex App Server: per-instance sync, or shared multi-listener?

[parkertoddbrooks]

Background

Filed an RFC issue at #21551: #21551

It was closed as procedural: question rather than feature request. The maintainer reply clarified the current architecture, so I am reposting here as suggested.

Per @etraut-openai's reply: today, "each client starts a new instance of the app server, and these instances currently don't talk to each other. There is a current assumption that only one client will interact with a thread at a time."

What I built

https://github.com/wipcomputer/wip-codex-remote-control/tree/main/OAI

That packet includes a 30s demo video, screenshot, architecture notes, and a narrow Codex-only branch showing one possible implementation shape.

The demo shows live co-presence across TUI, desktop web, and phone web. Each surface originates a turn, and the other two observe it live on the same local thread.

The architecture question

Given the current per-instance non-sync model, the product question for live peer-client co-presence is which direction OpenAI prefers:

1. Keep per-instance App Server ownership and add an inter-instance sync layer. This may also relate to Codex Desktop on Windows refreshes app-server-updated threads only after window focus returns #21177, where Codex Desktop on Windows does not refresh app-server-updated threads until focus returns.
2. Move toward a shared App Server instance with multi-listener semantics. My patch is one shape of this.

Either path could resolve co-presence, but they have different security and lifecycle implications: auth scope per listener, presence and heartbeat semantics, who owns the thread when the originator disconnects, sandbox ownership, and approval routing.

What would be useful

• Which of the two directions matches OpenAI's roadmap, if either is publicly shareable.
• Whether the multi-listener primitive is something OpenAI wants as an upstream contribution under Apache-2.0, or whether there is already another internal direction.
• If neither: the right venue or shape for outside implementers to engage on App Server peer-client work going forward.

Happy to iterate, redirect, or close based on input.

[etraut-openai]

We're actively discussing the topics related to these questions. Any guidance that I provide at this time is likely to be invalidated in the future. I recommend picking a short-term solution that works for your exploration. Then be prepared to pivot in the future.

[parkertoddbrooks]

Thanks! We'll keep building on the patched-fork dogfood path and keep the App Server delta isolated so we can pivot when the direction settles. If anything from the internal discussion becomes shareable later, happy to revisit and adjust.

[parkertoddbrooks]

Congrats on the Codex mobile preview. Exciting to see this workflow become first-party.

I took a quick look through the recent app-server / remote-control PRs. It looks like the first-party path is now moving through managed app-server daemon + remote_control, with active work around remote clients, queued turns, and TUI/app-server state sync.

I also read the new remote connections docs. From the public docs, mobile setup currently runs through the Codex App host, and the setup flow is not available from the CLI or IDE Extension. SSH remotes also appear to route through the Codex App host.

The small primitive I am still trying to track is the one the prototype here needed: live co-presence for an existing thread, where a TUI-owned session and a trusted peer client can observe/send against the same active thread without terminal mirroring, a second runner, or requiring the Codex App host.

I do not see an obvious public PR that fully closes that specific piece yet. Is app-server-daemon / remote_control now the right surface to watch for that, rather than the older generic App Server peer-client path?

cc @tibo-openai in case this is useful context for the Codex mobile / CLI remote-control direction.

[mrclovvn]

I’m seeing a related problem in my App Server workflow.

When I send an automated message to an existing Codex session through App Server / terminal automation, the message is appended, but it does not refresh live in existing observers such as Codex App or CLI/TUI. I often need to close/reopen the App or CLI before the update becomes visible.

My expected behavior is that a change made from one trusted client should be promptly visible across other observer clients. For example, if an automated tool appends a turn, both Codex App and CLI should be able to see it without restart.

A shared App Server multi-listener model or a documented cross-client refresh/invalidation mechanism would solve this use case.