mirror of https://github.com/openai/codex.git synced 2026-04-29 00:55:38 +00:00

Files

Eric Traut 1ff39b6fa8 Wire remote app-server auth through the client (#14853 )

For app-server websocket auth, support the two server-side mechanisms
from
PR #14847:

- `--ws-auth capability-token --ws-token-file /abs/path`
- `--ws-auth signed-bearer-token --ws-shared-secret-file /abs/path`
  with optional `--ws-issuer`, `--ws-audience`, and
  `--ws-max-clock-skew-seconds`

On the client side, add interactive remote support via:

- `--remote ws://host:port` or `--remote wss://host:port`
- `--remote-auth-token-env <ENV_VAR>`

Codex reads the bearer token from the named environment variable and
sends it
as `Authorization: Bearer <token>` during the websocket handshake.
Remote auth
tokens are only allowed for `wss://` URLs or loopback `ws://` URLs.

Testing:
- tested both auth methods manually to confirm connection success and
rejection for both auth types

2026-03-25 22:17:03 -06:00

src

Wire remote app-server auth through the client (#14853 )

2026-03-25 22:17:03 -06:00

BUILD.bazel

fix(bazel) add missing app-server-client BUILD.bazel (#14027 )

2026-03-09 03:42:54 +00:00

Cargo.toml

Finish moving codex exec to app-server (#15424 )

2026-03-24 08:51:32 -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.