core/core-agent-ide
8
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
core-agent-ide/codex-rs/app-server-client
History
Eric Traut 9dba7337f2
Start TUI on embedded app server (#14512) 
This PR is part of the effort to move the TUI on top of the app server.
In a previous PR, we introduced an in-process app server and moved
`exec` on top of it.

For the TUI, we want to do the migration in stages. The app server
doesn't currently expose all of the functionality required by the TUI,
so we're going to need to support a hybrid approach as we make the
transition.

This PR changes the TUI initialization to instantiate an in-process app
server and access its `AuthManager` and `ThreadManager` rather than
constructing its own copies. It also adds a placeholder TUI event
handler that will eventually translate app server events into TUI
events. App server notifications are accepted but ignored for now. It
also adds proper shutdown of the app server when the TUI terminates.
2026-03-13 12:04:41 -06:00
..
src Start TUI on embedded app server (#14512) 2026-03-13 12:04:41 -06:00
BUILD.bazel fix(bazel) add missing app-server-client BUILD.bazel (#14027) 2026-03-09 03:42:54 +00:00
Cargo.toml Add in-process app server and wire up exec to use it (#14005) 2026-03-08 18:43:55 -06:00
README.md Add in-process app server and wire up exec to use it (#14005) 2026-03-08 18:43:55 -06:00

README.md

codex-app-server-client

Shared in-process app-server client used by conversational CLI surfaces:

  • codex-exec
  • codex-tui

Purpose

This crate centralizes startup and lifecycle management for an in-process codex-app-server runtime, so CLI clients do not need to duplicate:

  • app-server bootstrap and initialize handshake
  • in-memory request/event transport wiring
  • lifecycle orchestration around caller-provided startup identity
  • graceful shutdown behavior

Startup identity

Callers pass both the app-server SessionSource and the initialize client_info.name explicitly when starting the facade.

That keeps thread metadata (for example in thread/list and thread/read) aligned with the originating runtime without baking TUI/exec-specific policy into the shared client layer.

Transport model

The in-process path uses typed channels:

  • client -> server: ClientRequest / ClientNotification
  • server -> client: InProcessServerEvent
    • ServerRequest
    • ServerNotification
    • LegacyNotification

JSON serialization is still used at external transport boundaries (stdio/websocket), but the in-process hot path is typed.

Typed requests still receive app-server responses through the JSON-RPC result envelope internally. That is intentional: the in-process path is meant to preserve app-server semantics while removing the process boundary, not to introduce a second response contract.

Bootstrap behavior

The client facade starts an already-initialized in-process runtime, but thread bootstrap still follows normal app-server flow:

  • caller sends thread/start or thread/resume
  • app-server returns the immediate typed response
  • richer session metadata may arrive later as a SessionConfigured legacy event

Surfaces such as TUI and exec may therefore need a short bootstrap phase where they reconcile startup response data with later events.

Backpressure and shutdown

  • Queues are bounded and use DEFAULT_IN_PROCESS_CHANNEL_CAPACITY by default.
  • Full queues return explicit overload behavior instead of unbounded growth.
  • shutdown() performs a bounded graceful shutdown and then aborts if timeout is exceeded.

If the client falls behind on event consumption, the worker emits InProcessServerEvent::Lagged and may reject pending server requests so approval flows do not hang indefinitely behind a saturated queue.