mirror of https://github.com/openai/codex.git synced 2026-11-10 21:00:47 +00:00

Files

T

Benjamin Carlsson 82e6bacb9c Enable model and reasoning effort selection for Cloud conversations (#60651 )

## Why

Cloud conversations previously used the model returned on activation without exposing model discovery or supporting model changes from the TUI.

## What changed

- Fetch the account-scoped Cloud catalog on demand through `/v2/models`, independently of the submission and attachment queue.
- Let users stage a supported model and reasoning effort for the next new turn in the current conversation. Send these settings with the user message and show acceptance after successful admission.
- Show a loading picker when the catalog is empty, preserve compatibility with Cloud servers that lack discovery, and discard stale catalog results and selections when the account changes.

## Testing

Add coverage for catalog request parameters and queue bypass, deferred discovery and compatibility, model and effort serialization, admission outcomes, account invalidation, and opening the picker after discovery.

GitOrigin-RevId: 2cd0e7fe5f760d4da9258eefe9f0dcbcd23f9b07

2026-11-10 19:52:49 +00:00

src

Enable model and reasoning effort selection for Cloud conversations (#60651 )

2026-11-10 19:52:49 +00:00

tests

Add managed command checkpoints requiring fresh human approval (#58045 )

2026-10-29 11:23:51 +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 a gated Cloud backend to the TUI (#59828 )

2026-11-06 05:26:52 +00: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.