mirror of https://github.com/openai/codex.git synced 2026-05-28 23:10:20 +00:00

Files

Joe Florencio 28475c727d Switch runtime to cloud config bundle

Replace the old cloud requirements runtime path with the unified cloud config bundle loader. Config construction now receives a CloudConfigBundleLoader and uses the shared bundle for both cloud-delivered requirements and cloud-delivered config layers, so config and requirements consumers do not race separate backend fetches.

Remove the codex-cloud-requirements crate and legacy CloudRequirementsLoader surface. The new path preserves the existing pull-based load behavior and routes managed requirements through the same composed requirements model while enterprise-managed config fragments are inserted below user/profile/project/session config and above system config. Legacy MDM-delivered managed_config.toml remains the highest-precedence compatibility layer while it is phased out.

Thread the bundle loader through app-server, app-server-client, TUI, core config construction, exec, hooks, network proxy loading, and related tests. Update config-manager error handling and tests to report cloudConfigBundle load failures consistently, and update the loader README to describe the new public argument and the effective config-layer precedence.

Refresh generated Python SDK protocol artifacts from the local app-server schema so downstream clients know about enterpriseManaged config layers and the cloudManagedConfig hook source. The normal SDK generate-types command still targets the pinned runtime package, so this checkpoint regenerated v2_all.py from the checked-in local schema for the branch-local protocol changes.

Add codex_config::test_support::CloudConfigBundleFixture to centralize cloud bundle test setup. The fixture supports quick single-layer enterprise requirement/config loaders, additive enterprise requirement/config layers for multi-layer tests, and conversion into either a bundle or loader, removing copied private helpers from core and app-server tests.

Verification: just fmt; just fix -p codex-config; cargo test -p codex-config test_support; cargo test -p codex-core cloud_config_bundle_take_precedence_over_mdm_requirements; cargo test -p codex-app-server write_value_rejects_feature_requirement_conflict; git diff --cached --check. Earlier checkpoint verification also covered codex-cloud-config, codex-backend-client, codex-hooks, codex-core-plugins, selected codex-core cloud config tests, selected codex-app-server cloud config tests, bazel lock update/check, and a Python SDK smoke test for enterpriseManaged and cloudManagedConfig.

2026-05-26 14:36:56 -07:00

src

Switch runtime to cloud config bundle

2026-05-26 14:36:56 -07: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

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.