Roadmap clarification: will standalone TUI move to app-server-backed runtime for multi-client live sync?

[KaminariOS]

Request

Could the team clarify the roadmap for TUI architecture:

• Is the standalone TUI expected to migrate to an app-server-backed runtime?
• If yes, is that a near-term or long-term direction?
• If no, what is the intended long-term model for cross-client live sync?

Why this matters

Right now, users can share a threadId across processes, but live sync is process-local unless clients share the same app-server runtime. In practice this causes confusion:

• TUI in one process + app-server in another process do not share live in-memory turn events.
• Sync is eventual via rollout/resume/read, not true real-time multi-client state.
• Users building custom clients need to know which architecture to target.

What would help

A short guidance note in docs would unblock design decisions:

1. Recommended architecture for true multi-client live sync (today).
2. Whether TUI-over-app-server is an intended destination.
3. If there are planned APIs for cross-process sync/refresh (or if that is explicitly out of scope).

Context

I found app-server transport progress (e.g. websocket support in #10693) and related sync issues, but no explicit roadmap statement tying this to standalone TUI direction.

[KaminariOS]

I use TUI when I am using my laptop but I also want to access the same session on my phone.

[etraut-openai]

We've had some discussions about switching the TUI to the app server interface. Architecturally, it makes sense, and it would reduce maintenance costs somewhat. But it will also be somewhat disruptive. It's not a high priority at the moment relative to many other things we are working on.

[KaminariOS]

In the past few days, I have been trying to port the TUI to use the app-server websocket with Codex.

I took the wrong strategy, so it took more time than it should.

Basically, we just need to create a codex-core shim that translates functional calls into JSON/RPC calls to the app server. In addition, the resume-picker passes pathbuf, not thread-id, so I also changed it to use thread-id for remote connections.

At the end, I only need to change the lib.rs file of the TUI crate and add a shim file. If I had better knowledge of the codex project before, I could have just finished it in a few hours.

If anyone is interested, check out my repo: https://github.com/KaminariOS/crabbot.

I have also built a Proof of concept React Native Android app to connect to the WebSocket, and it works. However, currently, the app-server rejects some WS security header(sec-websocket-), so I have to strip the header with a WebSocket relay daemon.