Files
codex/codex-rs/app-server-client
Dmitriy Kovalenko 745d865521 Align Bazel release builds with Cargo and fix platform compatibility (#51848)
## Why

Bazel release builds need Cargo-compatible Rust and native build-script settings. Platform-specific issues also include Windows command-line limits, MSVC runtime conflicts with V8's allocator, and a missing V8 `__clear_cache` symbol on ARM64 musl.

## What changed

- Add `--config=release` settings for thin LTO, four target codegen units, and disabled debug assertions and overflow checks, with separate settings for build tools.
- Add opt-in Cargo release profile support for build-script optimization and debug information, preserving explicit C/C++ flags. Give optimized Bubblewrap builds `-O3`, debug symbols, and enabled native assertions.
- Statically link the MSVC CRT for Rust and C/C++ target and host dependencies, and disable SQLite intrinsics on x64 MSVC to avoid startup crashes on older CPUs.
- Let the Rust process wrapper read its arguments from a multiline parameter file to avoid Windows command-line limits.
- Select the ARM64 musl V8 archive containing compiler-rt builtins and raise the Rust recursion limit to `256` in the app-server client, exec, and TUI entry points for release compilation.

GitOrigin-RevId: 8f61e62b8735c36209ee92e04a0e0339a70badc5
2026-10-07 22:10:23 +00:00
..

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.