mirror of https://github.com/openai/codex.git synced 2026-10-19 17:28:46 +00:00

Files

T

Benjamin Carlsson 8c0f701167 Add connection-bound reply handles for app-server requests (#53049 )

## Why

Server request IDs can be reused across connections. Retained replies need to target the connection that emitted the request, even if the UI selection later changes.

## What changed

- Expose `AppServerReplyHandle` through `AppServerRequestHandle::server_request_reply_handle`, capturing the originating client and request ID for explicit `resolve` or `reject` calls.
- Share single-use completion state across clones so only the first reply is submitted. Dropping a handle sends nothing; stale connections return I/O errors without retrying or switching connections.
- Route existing client reply methods through request handles and use the new API in the managed worktree model test.

## Testing

Add in-process and WebSocket tests for replies on separate connections with identical request IDs, rejection routing, duplicate completion, and stale handles after worker shutdown. Also check that debug output redacts handle details.

GitOrigin-RevId: 940d0951ab67529b05919ca8ec7adb5813834b8c

2026-10-11 06:08:41 +00:00

src

Add connection-bound reply handles for app-server requests (#53049 )

2026-10-11 06:08:41 +00:00

BUILD.bazel

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

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

Cargo.toml

Add support for UDS in codex --remote (#22414 )

2026-05-12 21:17:20 -07:00

README.md

Prevent unread events from blocking in-process requests (#38381 )

2026-08-13 13:57:25 +00: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

Command queues and the embedded runtime remain bounded, using DEFAULT_IN_PROCESS_CHANNEL_CAPACITY by default.
The facade's local consumer event queue is unbounded and preserves notification order. This keeps the worker draining the bounded runtime while a caller waits for a request, preventing unread notifications from blocking its response.
shutdown() performs a bounded graceful shutdown and then aborts if timeout is exceeded.