94 Commits

• Support multiple managed environments (#18401)

  ## Summary
  - refactor EnvironmentManager to own keyed environments with
  default/local lookup helpers
  - keep remote exec-server client creation lazy until exec/fs use
  - preserve disabled agent environment access separately from internal
  local environment access
  
  ## Validation
  - not run (per Codex worktree instruction to avoid tests/builds unless
  requested)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-21 15:29:35 -07:00
  ddbe2536be
• fix: fully revert agent identity runtime wiring (#18757)

  ## Summary
  
  This PR fully reverts the previously merged Agent Identity runtime
  integration from the old stack:
  https://github.com/openai/codex/pull/17387/changes
  
  It removes the Codex-side task lifecycle wiring, rollout/session
  persistence, feature flag plumbing, lazy `auth.json` mutation,
  background task auth paths, and request callsite changes introduced by
  that stack.
  
  This leaves the repo in a clean pre-AgentIdentity integration state so
  the follow-up PRs can reintroduce the pieces in smaller reviewable
  layers.
  
  ## Stack
  
  1. This PR: full revert
  2. https://github.com/openai/codex/pull/18871: move Agent Identity
  business logic into a crate
  3. https://github.com/openai/codex/pull/18785: add explicit
  AgentIdentity auth mode and startup task allocation
  4. https://github.com/openai/codex/pull/18811: migrate auth callsites
  through AuthProvider
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-21 14:30:55 -07:00
  be75785504
• app-server: implement device key v2 methods (#18430)

  ## Why
  
  The device-key protocol needs an app-server implementation that keeps
  local key operations behind the same request-processing boundary as
  other v2 APIs.
  
  app-server owns request dispatch, transport policy, documentation, and
  JSON-RPC error shaping. `codex-device-key` owns key binding, validation,
  platform provider selection, and signing mechanics. Keeping the adapter
  thin makes the boundary easier to review and avoids moving local
  key-management details into thread orchestration code.
  
  ## What changed
  
  - Added `DeviceKeyApi` as the app-server adapter around
  `DeviceKeyStore`.
  - Converted protocol protection policies, payload variants, algorithms,
  and protection classes to and from the device-key crate types.
  - Encoded SPKI public keys and DER signatures as base64 protocol fields.
  - Routed `device/key/create`, `device/key/public`, and `device/key/sign`
  through `MessageProcessor`.
  - Rejected remote transports before provider access while allowing local
  `stdio` and in-process callers to reach the device-key API.
  - Added stdio, in-process, and websocket tests for device-key validation
  and transport policy.
  - Documented the device-key methods in the app-server v2 method list.
  
  ## Test coverage
  
  - `device_key_create_rejects_empty_account_user_id`
  - `in_process_allows_device_key_requests_to_reach_device_key_api`
  - `device_key_methods_are_rejected_over_websocket`
  
  ## Stack
  
  This is PR 3 of 4 in the device-key app-server stack. It is stacked on
  #18429.
  
  ## Validation
  
  - `cargo test -p codex-app-server device_key`
  - `just fix -p codex-app-server`

  Ruslan Nigmatullin · 2026-04-21 14:07:08 -07:00
  69c3d12274
• Load app-server config through ConfigManager (#18870)

  ## Summary
  - Load app-server startup config through `ConfigManager` instead of
  direct `ConfigBuilder` calls.
  - Move `ConfigManager` constructor-owned state (`cli_overrides`, runtime
  feature map, cloud requirements loader) behind internal manager fields.
  - Pass `ConfigManager` into `MessageProcessor` directly instead of
  reconstructing it from raw args.
  
  ## Tests
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server`
  - `just fix -p codex-app-server`
  - `just fmt`

  pakrym-oai · 2026-04-21 14:01:02 -07:00
  ffa6944587
• Refactor app-server config loading into ConfigManager (#18442)

  Localize app-server configuration loading in one place.

  pakrym-oai · 2026-04-21 10:22:26 -07:00
  5fe767e8e1
• Move external agent config out of core (#18850)

  ## Summary
  - Move external agent config migration logic and tests from `codex-core`
  into `app-server/src/config`.
  - Keep the migration service crate-private to app-server and update the
  API adapter imports.
  - Remove stale core re-exports and expose only the needed marketplace
  source helper.
  
  ## Testing
  - `cargo test -p codex-app-server config::external_agent_config`
  - `just fmt`
  - `just fix -p codex-app-server`
  - `just fix -p codex-core`
  - `git diff --check`

  pakrym-oai · 2026-04-21 08:33:58 -07:00
  833212115e
• Add session config loader interface (#18208)

  ## Why
  
  Cloud-hosted sessions need a way for the service that starts or manages
  a thread to provide session-owned config without treating all config as
  if it came from the same user/project/workspace TOML stack.
  
  The important boundary is ownership: some values should be controlled by
  the session/orchestrator, some by the authenticated user, and later some
  may come from the executor. The earlier broad config-store shape made
  that boundary too fuzzy and overlapped heavily with the existing
  filesystem-backed config loader. This PR starts with the smaller piece
  we need now: a typed session config loader that can feed the existing
  config layer stack while preserving the normal precedence and merge
  behavior.
  
  ## What Changed
  
  - Added `ThreadConfigLoader` and related typed payloads in
  `codex-config`.
  - `SessionThreadConfig` currently supports `model_provider`,
  `model_providers`, and feature flags.
  - `UserThreadConfig` is present as an ownership boundary, but does not
  yet add TOML-backed fields.
  - `NoopThreadConfigLoader` preserves existing behavior when no external
  loader is configured.
    - `StaticThreadConfigLoader` supports tests and simple callers.
  
  - Taught thread config sources to produce ordinary `ConfigLayerEntry`
  values so the existing `ConfigLayerStack` remains the place where
  precedence and merging happen.
  
  - Wired the loader through `ConfigBuilder`, the config loader, and
  app-server startup paths so app-server can provide session-owned config
  before deriving a thread config.
  
  - Added coverage for:
    - translating typed thread config into config layers,
  - inserting thread config layers into the stack at the right precedence,
  - applying session-provided model provider and feature settings when
  app-server derives config from thread params.
  
  ## Follow-Ups
  
  This intentionally stops short of adding the remote/service transport.
  The next pieces are expected to be:
  
  1. Define the proto/API shape for this interface.
  2. Add a client implementation that can source session config from the
  service side.
  
  ## Verification
  
  - Added unit coverage in `codex-config` for the loader and layer
  conversion.
  - Added `codex-core` config loader coverage for thread config layer
  precedence.
  - Added app-server coverage that verifies session thread config wins
  over request-provided config for model provider and feature settings.

  Rasmus Rygaard · 2026-04-20 23:05:49 +00:00
  7b994100b3
• [codex] Use background task auth for additional backend calls (#18260)

  ## Summary
  
  Splits the larger PR4.1 background task auth rollout by moving
  additional backend/control-plane call sites into this downstream PR.
  
  This PR keeps callers on the same design as PR4.1: most code asks
  `AuthManager` for the default ChatGPT backend authorization header, and
  `AuthManager` decides bearer vs background AgentAssertion internally.
  Task-pinned inference auth remains separate because it needs the
  thread's registered task id.
  
  ## Stack
  
  - PR1: https://github.com/openai/codex/pull/17385 - add
  `features.use_agent_identity`
  - PR2: https://github.com/openai/codex/pull/17386 - register agent
  identities when enabled
  - PR3: https://github.com/openai/codex/pull/17387 - register agent tasks
  when enabled
  - PR3.1: https://github.com/openai/codex/pull/17978 - persist and
  prewarm registered tasks per thread
  - PR4: https://github.com/openai/codex/pull/17980 - use task-scoped
  `AgentAssertion` for downstream calls
  - PR4.1: https://github.com/openai/codex/pull/18094 - introduce
  AuthManager-owned background/control-plane `AgentAssertion` auth
  - PR4.2: this PR - use background task auth for additional
  backend/control-plane calls
  
  ## What Changed
  
  - pass full authorization header values through backend-client and
  cloud-tasks-client call paths where needed
  - move ChatGPT client, cloud requirements, cloud tasks, thread-manager,
  and models-manager background auth usage into this downstream slice
  - make app-server remote control enrollment/websocket auth ask
  `AuthManager` for the local backend authorization header instead of
  threading a background auth mode through transport options
  - keep the same feature-gated bearer fallback behavior from PR4.1
  
  ## Validation
  
  - `just fmt`
  - `cargo check -p codex-core -p codex-login -p codex-analytics -p
  codex-app-server -p codex-cloud-requirements -p codex-cloud-tasks -p
  codex-models-manager -p codex-chatgpt -p codex-model-provider -p
  codex-mcp -p codex-core-skills`
  - `cargo test -p codex-login agent_identity`
  - `cargo test -p codex-model-provider bearer_auth_provider`
  - `cargo test -p codex-core agent_assertion`
  - `cargo test -p codex-app-server remote_control`
  - `cargo test -p codex-cloud-requirements fetch_cloud_requirements`
  - `cargo test -p codex-models-manager manager::tests`
  - `cargo test -p codex-chatgpt`
  - `cargo test -p codex-cloud-tasks`
  - `just fix -p codex-core -p codex-login -p codex-analytics -p
  codex-app-server -p codex-cloud-requirements -p codex-cloud-tasks -p
  codex-models-manager -p codex-chatgpt -p codex-model-provider -p
  codex-mcp -p codex-core-skills`
  - `just fix -p codex-app-server`
  - `git diff --check`

  Adrian · 2026-04-20 07:24:29 -07:00
  19e2f21827
• fix: trust-gate project hooks and exec policies (#14718)

  ## Summary
  - trust-gate project `.codex` layers consistently, including repos that
  have `.codex/hooks.json` or `.codex/execpolicy/*.rules` but no
  `.codex/config.toml`
  - keep disabled project layers in the config stack so nested trusted
  project layers still resolve correctly, while preventing hooks and exec
  policies from loading until the project is trusted
  - update app-server/TUI onboarding copy to make the trust boundary
  explicit and add regressions for loader, hooks, exec-policy, and
  onboarding coverage
  
  ## Security
  Before this change, an untrusted repo could auto-load project hooks or
  exec policies from `.codex/` as long as `config.toml` was absent. This
  makes trust the single gate for project-local config, hooks, and exec
  policies.
  
  ## Stack
  - Parent of #15936
  
  ## Test
  - cargo test -p codex-core without_config_toml
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-17 17:56:58 -07:00
  370bed4bf4
• Async config loading (#18022)

  Parts of config will come from executor. Prepare for that by making
  config loading methods async.

  pakrym-oai · 2026-04-15 19:18:38 -07:00
  bd61737e8a
• app-server: prepare to run initialized rpcs concurrently (#17372)

  ## Summary
  
  - Refactors `MessageProcessor` and per-connection session state so
  initialized service RPC handling can be moved into spawned tasks in a
  follow-up PR.
  - Shares the processor and initialized session data with
  `Arc`/`OnceLock` instead of mutable borrowed connection state.
  - Keeps initialized request handling synchronous in this PR; it does
  **not** call `tokio::spawn` for service RPCs yet.
  
  ## Testing
  
  - `just fmt`
  - `cargo test -p codex-app-server` *(fails on existing hardening gaps
  covered by #17375, #17376, and #17377; the pipelined config regression
  passed before the unrelated failures)*
  - `just fix -p codex-app-server`

  Ruslan Nigmatullin · 2026-04-14 11:24:34 -07:00
  23d4098c0f
• Use AbsolutePathBuf in skill loading and codex_home (#17407)

  Helps with FS migration later

  pakrym-oai · 2026-04-13 10:26:51 -07:00
  ac82443d07
• Run exec-server fs operations through sandbox helper (#17294)

  ## Summary
  - run exec-server filesystem RPCs requiring sandboxing through a
  `codex-fs` arg0 helper over stdin/stdout
  - keep direct local filesystem execution for `DangerFullAccess` and
  external sandbox policies
  - remove the standalone exec-server binary path in favor of top-level
  arg0 dispatch/runtime paths
  - add sandbox escape regression coverage for local and remote filesystem
  paths
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - remote devbox: `cd codex-rs && bazel test --bes_backend=
  --bes_results_url= //codex-rs/exec-server:all` (6/6 passed)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-12 18:36:03 -07:00
  d626dc3895
• app-server: Fix clippy by removing extra mut (#17262)
  Ruslan Nigmatullin · 2026-04-09 14:30:18 -07:00
  ff1ab61e4f
• app-server: Allow enabling remote control in runtime (#16973)

  Refresh the feature flag on writes to the config.

  Ruslan Nigmatullin · 2026-04-07 11:36:17 -07:00
  59af4a730c
• app-server: Add transport for remote control (#15951)
  Ruslan Nigmatullin · 2026-04-06 14:55:59 -07:00
  73dab2046f
• app-server: centralize AuthManager initialization (#16764)

  Extract a shared helper that builds AuthManager from Config and applies
  the forced ChatGPT workspace override in one place.
  
  Create the shared AuthManager at MessageProcessor call sites so that
  upcoming new transport's initialization can reuse the same handle, and
  keep only external auth refresher wiring inside `MessageProcessor`.
  
  Remove the now-unused `AuthManager::shared_with_external_auth` helper.

  Ruslan Nigmatullin · 2026-04-06 12:46:55 -07:00
  1525bbdb9a
• Suppress bwrap warning when sandboxing is bypassed (#16667)

  Addresses #15282
  
  Problem: Codex warned about missing system bubblewrap even when
  sandboxing was disabled.
  
  Solution: Gate the bwrap warning on the active sandbox policy and skip
  it for danger-full-access and external-sandbox modes.

  Eric Traut · 2026-04-03 10:54:30 -07:00
  0f7394883e
• core: remove cross-crate re-exports from lib.rs (#16512)

  ## Why
  
  `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
  which made downstream crates depend on `codex-core` as a proxy module
  instead of the actual owner crate.
  
  Removing those forwards makes crate boundaries explicit and lets leaf
  crates drop unnecessary `codex-core` dependencies. In this PR, this
  reduces the dependency on `codex-core` to `codex-login` in the following
  files:
  
  ```
  codex-rs/backend-client/Cargo.toml
  codex-rs/mcp-server/tests/common/Cargo.toml
  ```
  
  ## What
  
  - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
  `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
  `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
  `codex-tools`, and `codex-utils-path`.
  - Delete the `default_client` forwarding shim in `codex-rs/core`.
  - Update in-crate and downstream callsites to import directly from the
  owning `codex-*` crate.
  - Add direct Cargo dependencies where callsites now target the owner
  crate, and remove `codex-core` from `codex-rs/backend-client`.

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• [codex-analytics] thread events (#15690)

  - add event for thread initialization
  - thread/start, thread/fork, thread/resume
  - feature flagged behind `FeatureFlag::GeneralAnalytics`
  - does not yet support threads started by subagents
  
  PR stack:
  - --> [[telemetry] thread events
  #15690](https://github.com/openai/codex/pull/15690)
  - [[telemetry] subagent events
  #15915](https://github.com/openai/codex/pull/15915)
  - [[telemetry] turn events
  #15591](https://github.com/openai/codex/pull/15591)
  - [[telemetry] steer events
  #15697](https://github.com/openai/codex/pull/15697)
  - [[telemetry] queued prompt data
  #15804](https://github.com/openai/codex/pull/15804)
  
  
  Sample extracted logs in Codex-backend
  ```
  INFO     | 2026-03-29 16:39:37 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3bf7-9f5f-7f82-9877-6d48d1052531 product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=new subagent_source=None parent_thread_id=None created_at=1774827577 | 
  INFO     | 2026-03-29 16:45:46 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3b84-5731-79d0-9b3b-9c6efe5f5066 product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=resumed subagent_source=None parent_thread_id=None created_at=1774820022 | 
  INFO     | 2026-03-29 16:45:49 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3bfd-4cd6-7c12-a13e-48cef02e8c4d product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=forked subagent_source=None parent_thread_id=None created_at=1774827949 | 
  INFO     | 2026-03-29 17:20:29 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3c1d-0412-7ed2-ad24-c9c0881a36b0 product_surface=codex product_client_id=CODEX_SERVICE_EXEC client_name=codex_exec client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=new subagent_source=None parent_thread_id=None created_at=1774830027 | 
  ```
  
  Notes
  - `product_client_id` gets canonicalized in codex-backend
  - subagent threads are addressed in a following pr

  rhan-oai · 2026-03-31 12:16:44 -07:00
  e8de4ea953
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

  ## Why
  
  `argument-comment-lint` was green in CI even though the repo still had
  many uncommented literal arguments. The main gap was target coverage:
  the repo wrapper did not force Cargo to inspect test-only call sites, so
  examples like the `latest_session_lookup_params(true, ...)` tests in
  `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path.
  
  This change cleans up the existing backlog, makes the default repo lint
  path cover all Cargo targets, and starts rolling that stricter CI
  enforcement out on the platform where it is currently validated.
  
  ## What changed
  
  - mechanically fixed existing `argument-comment-lint` violations across
  the `codex-rs` workspace, including tests, examples, and benches
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and
  `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to
  `--all-targets` unless the caller explicitly narrows the target set
  - fixed both wrappers so forwarded cargo arguments after `--` are
  preserved with a single separator
  - documented the new default behavior in
  `tools/argument-comment-lint/README.md`
  - updated `rust-ci` so the macOS lint lane keeps the plain wrapper
  invocation and therefore enforces `--all-targets`, while Linux and
  Windows temporarily pass `-- --lib --bins`
  
  That temporary CI split keeps the stricter all-targets check where it is
  already cleaned up, while leaving room to finish the remaining Linux-
  and Windows-specific target-gated cleanup before enabling
  `--all-targets` on those runners. The Linux and Windows failures on the
  intermediate revision were caused by the wrapper forwarding bug, not by
  additional lint findings in those lanes.
  
  ## Validation
  
  - `bash -n tools/argument-comment-lint/run.sh`
  - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh`
  - shell-level wrapper forwarding check for `-- --lib --bins`
  - shell-level wrapper forwarding check for `-- --tests`
  - `just argument-comment-lint`
  - `cargo test` in `tools/argument-comment-lint`
  - `cargo test -p codex-terminal-detection`
  
  ## Follow-up
  
  - Clean up remaining Linux-only target-gated callsites, then switch the
  Linux lint lane back to the plain wrapper invocation.
  - Clean up remaining Windows-only target-gated callsites, then switch
  the Windows lint lane back to the plain wrapper invocation.

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• app-server: Organize app-server to allow more transports (#15810)

  Make `run_main_with_transport` slightly more flexible by consolidating
  logic spread across stdio and websocket transports.

  Ruslan Nigmatullin · 2026-03-25 17:11:22 -07:00
  d7e35e56cf
• Add cached environment manager for exec server URL (#15785)

  Add environment manager that is a singleton and is created early in
  app-server (before skill manager, before config loading).
  
  Use an environment variable to point to a running exec server.

  pakrym-oai · 2026-03-25 16:14:36 -07:00
  8fa88fa8ca
• feat: add websocket auth for app-server (#14847)

  ## Summary
  This change adds websocket authentication at the app-server transport
  boundary and enforces it before JSON-RPC `initialize`, so authenticated
  deployments reject unauthenticated clients during the websocket
  handshake rather than after a connection has already been admitted.
  
  During rollout, websocket auth is opt-in for non-loopback listeners so
  we do not break existing remote clients. If `--ws-auth ...` is
  configured, the server enforces auth during websocket upgrade. If auth
  is not configured, non-loopback listeners still start, but app-server
  logs a warning and the startup banner calls out that auth should be
  configured before real remote use.
  
  The server supports two auth modes: a file-backed capability token, and
  a standard HMAC-signed JWT/JWS bearer token verified with the
  `jsonwebtoken` crate, with optional issuer, audience, and clock-skew
  validation. Capability tokens are normalized, hashed, and compared in
  constant time. Short shared secrets for signed bearer tokens are
  rejected at startup. Requests carrying an `Origin` header are rejected
  with `403` by transport middleware, and authenticated clients present
  credentials as `Authorization: Bearer <token>` during websocket upgrade.
  
  ## Validation
  - `cargo test -p codex-app-server transport::auth`
  - `cargo test -p codex-cli app_server_`
  - `cargo clippy -p codex-app-server --all-targets -- -D warnings`
  - `just bazel-lock-check`
  
  Note: in the broad `cargo test -p codex-app-server
  connection_handling_websocket` run, the touched websocket auth cases
  passed, but unrelated Unix shutdown tests failed with a timeout in this
  environment.
  
  ---------
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  viyatb-oai · 2026-03-25 12:35:57 -07:00
  6124564297
• app-server: add filesystem watch support (#14533)

  ### Summary
  Add the v2 app-server filesystem watch RPCs and notifications, wire them
  through the message processor, and implement connection-scoped watches
  with notify-backed change delivery. This also updates the schema
  fixtures, app-server documentation, and the v2 integration coverage for
  watch and unwatch behavior.
  
  This allows clients to efficiently watch for filesystem updates, e.g. to
  react on branch changes.
  
  ### Testing
  - exercise watch lifecycles for directory changes, atomic file
  replacement, missing-file targets, and unwatch cleanup

  Ruslan Nigmatullin · 2026-03-24 15:52:13 -07:00
  301b17c2a1
• app-server: Add back pressure and batching to command/exec (#15547)

  * Add
  `OutgoingMessageSender::send_server_notification_to_connection_and_wait`
  which returns only once message is written to websocket (or failed to do
  so)
  * Use this mechanism to apply back pressure to stdout/stderr streams of
  processes spawned by `command/exec`, to limit them to at most one
  message in-memory at a time
  * Use back pressure signal to also batch smaller chunks into ≈64KiB ones
  
  This should make commands execution more robust over
  high-latency/low-throughput networks

  Ruslan Nigmatullin · 2026-03-24 11:35:51 -07:00
  d61c03ca08
• Finish moving codex exec to app-server (#15424)

  This PR completes the conversion of non-interactive `codex exec` to use
  app server rather than directly using core events and methods.
  
  ### Summary
  - move `codex-exec` off exec-owned `AuthManager` and `ThreadManager`
  state
  - route exec bootstrap, resume, and auth refresh through existing
  app-server paths
  - replace legacy `codex/event/*` decoding in exec with typed app-server
  notification handling
  - update human and JSONL exec output adapters to translate existing
  app-server notifications only
  - clean up "app server client" layer by eliminating support for legacy
  notifications; this is no longer needed
  - remove exposure of `authManager` and `threadManager` from "app server
  client" layer
  
  ### Testing
  - `exec` has pretty extensive unit and integration tests already, and
  these all pass
  - In addition, I asked Codex to put together a comprehensive manual set
  of tests to cover all of the `codex exec` functionality (including
  command-line options), and it successfully generated and ran these tests

  Eric Traut · 2026-03-24 08:51:32 -06:00
  45f68843b8
• fix: fall back to vendored bubblewrap when system bwrap lacks --argv0 (#15338)

  ## Why
  
  Fixes [#15283](https://github.com/openai/codex/issues/15283), where
  sandboxed tool calls fail on older distro `bubblewrap` builds because
  `/usr/bin/bwrap` does not understand `--argv0`. The upstream [bubblewrap
  v0.9.0 release
  notes](https://github.com/containers/bubblewrap/releases/tag/v0.9.0)
  explicitly call out `Add --argv0`. Flipping `use_legacy_landlock`
  globally works around that compatibility bug, but it also weakens the
  default Linux sandbox and breaks proxy-routed and split-policy cases
  called out in review.
  
  The follow-up Linux CI failure was in the new launcher test rather than
  the launcher logic: the fake `bwrap` helper stayed open for writing, so
  Linux would not exec it. This update also closes the user-visibility gap
  from review by surfacing the same startup warning when `/usr/bin/bwrap`
  is present but too old for `--argv0`, not only when it is missing.
  
  ## What Changed
  
  - keep `use_legacy_landlock` default-disabled
  - teach `codex-rs/linux-sandbox/src/launcher.rs` to fall back to the
  vendored bubblewrap build when `/usr/bin/bwrap` does not advertise
  `--argv0` support
  - add launcher tests for supported, unsupported, and missing system
  `bwrap`
  - write the fake `bwrap` test helper to a closed temp path so the
  supported-path launcher test works on Linux too
  - extend the startup warning path so Codex warns when `/usr/bin/bwrap`
  is missing or too old to support `--argv0`
  - mirror the warning/fallback wording across
  `codex-rs/linux-sandbox/README.md` and `codex-rs/core/README.md`,
  including that the fallback is the vendored bubblewrap compiled into the
  binary
  - cite the upstream `bubblewrap` release that introduced `--argv0`
  
  ## Verification
  
  - `bazel test --config=remote --platforms=//:rbe
  //codex-rs/linux-sandbox:linux-sandbox-unit-tests
  --test_filter=launcher::tests::prefers_system_bwrap_when_help_lists_argv0
  --test_output=errors`
  - `cargo test -p codex-core system_bwrap_warning`
  - `cargo check -p codex-exec -p codex-tui -p codex-tui-app-server -p
  codex-app-server`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-23 09:46:51 -07:00
  d1088158b8
• feat: support product-scoped plugins. (#15041)

  1. Added SessionSource::Custom(String) and --session-source.
    2. Enforced plugin and skill products by session_source.
    3. Applied the same filtering to curated background refresh.

  xl-openai · 2026-03-19 00:46:15 -07:00
  db5781a088
• Revert "fix: harden plugin feature gating" (#15102)

  Reverts openai/codex#15020
  
  I messed up the commit in my PR and accidentally merged changes that
  were still under review.

  xl-openai · 2026-03-18 15:19:29 -07:00
  86982ca1f9
• fix: harden plugin feature gating (#15020)

  1. Use requirement-resolved config.features as the plugin gate.
  2. Guard plugin/list, plugin/read, and related flows behind that gate.
  3. Skip bad marketplace.json files instead of failing the whole list.
  4. Simplify plugin state and caching.

  xl-openai · 2026-03-18 10:11:43 -07:00
  580f32ad2a
• fix(linux-sandbox): prefer system /usr/bin/bwrap when available (#14963)

  ## Problem
  Ubuntu/AppArmor hosts started failing in the default Linux sandbox path
  after the switch to vendored/default bubblewrap in `0.115.0`.
  
  The clearest report is in
  [#14919](https://github.com/openai/codex/issues/14919), especially [this
  investigation
  comment](https://github.com/openai/codex/issues/14919#issuecomment-4076504751):
  on affected Ubuntu systems, `/usr/bin/bwrap` works, but a copied or
  vendored `bwrap` binary fails with errors like `bwrap: setting up uid
  map: Permission denied` or `bwrap: loopback: Failed RTM_NEWADDR:
  Operation not permitted`.
  
  The root cause is Ubuntu's `/etc/apparmor.d/bwrap-userns-restrict`
  profile, which grants `userns` access specifically to `/usr/bin/bwrap`.
  Once Codex started using a vendored/internal bubblewrap path, that path
  was no longer covered by the distro AppArmor exception, so sandbox
  namespace setup could fail even when user namespaces were otherwise
  enabled and `uidmap` was installed.
  
  ## What this PR changes
  - prefer system `/usr/bin/bwrap` whenever it is available
  - keep vendored bubblewrap as the fallback when `/usr/bin/bwrap` is
  missing
  - when `/usr/bin/bwrap` is missing, surface a Codex startup warning
  through the app-server/TUI warning path instead of printing directly
  from the sandbox helper with `eprintln!`
  - use the same launcher decision for both the main sandbox execution
  path and the `/proc` preflight path
  - document the updated Linux bubblewrap behavior in the Linux sandbox
  and core READMEs
  
  ## Why this fix
  This still fixes the Ubuntu/AppArmor regression from
  [#14919](https://github.com/openai/codex/issues/14919), but it keeps the
  runtime rule simple and platform-agnostic: if the standard system
  bubblewrap is installed, use it; otherwise fall back to the vendored
  helper.
  
  The warning now follows that same simple rule. If Codex cannot find
  `/usr/bin/bwrap`, it tells the user that it is falling back to the
  vendored helper, and it does so through the existing startup warning
  plumbing that reaches the TUI and app-server instead of low-level
  sandbox stderr.
  
  ## Testing
  - `cargo test -p codex-linux-sandbox`
  - `cargo test -p codex-app-server --lib`
  - `cargo test -p codex-tui-app-server
  tests::embedded_app_server_start_failure_is_returned`
  - `cargo clippy -p codex-linux-sandbox --all-targets`
  - `cargo clippy -p codex-app-server --all-targets`
  - `cargo clippy -p codex-tui-app-server --all-targets`

  viyatb-oai · 2026-03-17 23:05:34 +00:00
  0d1539e74c
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• app-server: add v2 filesystem APIs (#14245)

  Add a protocol-level filesystem surface to the v2 app-server so Codex
  clients can read and write files, inspect directories, and subscribe to
  path changes without relying on host-specific helpers.
  
  High-level changes:
  - define the new v2 fs/readFile, fs/writeFile, fs/createDirectory,
  fs/getMetadata, fs/readDirectory, fs/remove, fs/copy RPCs
  - implement the app-server handlers, including absolute-path validation,
  base64 file payloads, recursive copy/remove semantics
  - document the API, regenerate protocol schemas/types, and add
  end-to-end tests for filesystem operations, copy edge cases
  
  Testing plan:
  - validate protocol serialization and generated schema output for the
  new fs request, response, and notification types
  - run app-server integration coverage for file and directory CRUD paths,
  metadata/readDirectory responses, copy failure modes, and absolute-path
  validation

  Ruslan Nigmatullin · 2026-03-13 14:42:20 -07:00
  f8f82bfc2b
• Start TUI on embedded app server (#14512)

  This PR is part of the effort to move the TUI on top of the app server.
  In a previous PR, we introduced an in-process app server and moved
  `exec` on top of it.
  
  For the TUI, we want to do the migration in stages. The app server
  doesn't currently expose all of the functionality required by the TUI,
  so we're going to need to support a hybrid approach as we make the
  transition.
  
  This PR changes the TUI initialization to instantiate an in-process app
  server and access its `AuthManager` and `ThreadManager` rather than
  constructing its own copies. It also adds a placeholder TUI event
  handler that will eventually translate app server events into TUI
  events. App server notifications are accepted but ignored for now. It
  also adds proper shutdown of the app server when the TUI terminates.

  Eric Traut · 2026-03-13 12:04:41 -06:00
  9dba7337f2
• Handle malformed agent role definitions nonfatally (#14488)

  ## Summary
  - make malformed agent role definitions nonfatal during config loading
  - drop invalid agent roles and record warnings in `startup_warnings`
  - forward startup warnings through app-server `configWarning`
  notifications
  
  ## Testing
  - `cargo test -p codex-core agent_role_ -- --nocapture`
  - `just fix -p codex-core`
  - `just fmt`
  - `cargo test -p codex-app-server config_warning -- --nocapture`
  
  Co-authored-by: Codex <noreply@openai.com>

  gabec-openai · 2026-03-12 11:20:31 -07:00
  4fa7d6f444
• feat(app-server): propagate traces across tasks and core ops (#14387)

  ## Summary
  
  This PR keeps app-server RPC request trace context alive for the full
  lifetime of the work that request kicks off (e.g. for `thread/start`,
  this is `app-server rpc handler -> tokio background task -> core op
  submissions`). Previously we lose trace lineage once the request handler
  returns or hands work off to background tasks.
  
  This approach is especially relevant for `thread/start` and other RPC
  handlers that run in a non-blocking way. In the near future we'll most
  likely want to make all app-server handlers run in a non-blocking way by
  default, and only queue operations that must operate in order (e.g.
  thread RPCs per thread?), so we want to make sure tracing in app-server
  just generally works.
  
  Depends on https://github.com/openai/codex/pull/14300
  
  **Before**
  <img width="155" height="207" alt="image"
  src="https://github.com/user-attachments/assets/c9487459-36f1-436c-beb7-fafeb40737af"
  />
  
  
  **After**
  <img width="299" height="337" alt="image"
  src="https://github.com/user-attachments/assets/727392b2-d072-4427-9dc4-0502d8652dea"
  />
  
  ## What changed
  
  - Keep request-scoped trace context around until we send the final
  response or error, or the connection closes.
  - Thread that trace context through detached `thread/start` work so
  background startup stays attached to the originating request.
  - Pass request trace context through to downstream core operations,
  including:
    - thread creation
    - resume/fork flows
    - turn submission
    - review
    - interrupt
    - realtime conversation operations
  - Add tracing tests that verify:
    - remote W3C trace context is preserved for `thread/start`
    - remote W3C trace context is preserved for `turn/start`
    - downstream core spans stay under the originating request span
    - request-scoped tracing state is cleaned up correctly
  - Clean up shutdown behavior so detached background tasks and spawned
  threads are drained before process exit.

  Owen Lin · 2026-03-11 20:18:31 -07:00
  5bc82c5b93
• chore(app-server): stop emitting codex/event/ notifications (#14392)

  ## Description
  
  This PR stops emitting legacy `codex/event/*` notifications from the
  public app-server transports.
  
  It's been a long time coming! app-server was still producing a raw
  notification stream from core, alongside the typed app-server
  notifications and server requests, for compatibility reasons. Now,
  external clients should no longer be depending on those legacy
  notifications, so this change removes them from the stdio and websocket
  contract and updates the surrounding docs, examples, and tests to match.
  
  ### Caveat
  I left the "in-process" version of app-server alone for now, since
  `codex exec` was recently based on top of app-server via this in-process
  form here: https://github.com/openai/codex/pull/14005
  
  Seems like `codex exec` still consumes some legacy notifications
  internally, so this branch only removes `codex/event/*` from app-server
  over stdio and websockets.
  
  ## Follow-up
  
  Once `codex exec` is fully migrated off `codex/event/*` notifications,
  we'll be able to stop emitting them entirely entirely instead of just
  filtering it at the external transport boundary.

  Owen Lin · 2026-03-12 00:45:20 +00:00
  72631755e0
• fix(otel): make HTTP trace export survive app-server runtimes (#14300)

  ## Summary
  
  This PR fixes OTLP HTTP trace export in runtimes where the previous
  exporter setup was unreliable, especially around app-server usage. It
  also removes the old `codex_otel::otel_provider` compatibility shim and
  switches remaining call sites over to the crate-root
  `codex_otel::OtelProvider` export.
  
  ## What changed
  
  - Use a runtime-safe OTLP HTTP trace exporter path for Tokio runtimes.
  - Add an async HTTP client path for trace export when we are already
  inside a multi-thread Tokio runtime.
  - Make provider shutdown flush traces before tearing down the tracer
  provider.
  - Add loopback coverage that verifies traces are actually sent to
  `/v1/traces`:
    - outside Tokio
    - inside a multi-thread Tokio runtime
    - inside a current-thread Tokio runtime
  - Remove the `codex_otel::otel_provider` shim and update remaining
  imports.
  
  ## Why
  
  I hit cases where spans were being created correctly but never made it
  to the collector. The issue turned out to be in exporter/runtime
  behavior rather than the span plumbing itself. This PR narrows that gap
  and gives us regression coverage for the actual export path.

  Owen Lin · 2026-03-11 12:33:10 -07:00
  fa1242c83b
• Order websocket initialize after handshake (#13943)

  ## What changed
  - `app-server` now sends initialize notifications to the specific
  websocket connection before that connection is marked outbound-ready.
  - `message_processor` now exposes the forwarding hook needed to target
  that initialize delivery path.
  
  ## Why this fixes the flake
  - This was a real websocket ordering bug.
  - The old code allowed “connection is ready for outbound broadcasts” to
  become true before the initialize notification had been routed to the
  intended client.
  - On CI this showed up as a race where tests would occasionally miss or
  misorder initialize delivery depending on scheduler timing.
  - Sending initialize to the exact connection first, then exposing it to
  the general outbound path, removes that race instead of hiding it with
  timing slack.
  
  ## Scope
  - Production logic change.

  Ahmed Ibrahim · 2026-03-09 10:27:19 -07:00
  0dc242a672
• Add in-process app server and wire up exec to use it (#14005)

  This is a subset of PR #13636. See that PR for a full overview of the
  architectural change.
  
  This PR implements the in-process app server and modifies the
  non-interactive "exec" entry point to use the app server.
  
  ---------
  
  Co-authored-by: Felipe Coury <felipe.coury@gmail.com>

  Eric Traut · 2026-03-08 18:43:55 -06:00
  da3689f0ef
• feat: simplify DB further (#13771)
  jif-oai · 2026-03-07 03:48:36 -08:00
  cf143bf71e
• app-server: Add streaming and tty/pty capabilities to command/exec (#13640)

  * Add an ability to stream stdin, stdout, and stderr
  * Streaming of stdout and stderr has a configurable cap for total amount
  of transmitted bytes (with an ability to disable it)
  * Add support for overriding environment variables
  * Add an ability to terminate running applications (using
  `command/exec/terminate`)
  * Add TTY/PTY support, with an ability to resize the terminal (using
  `command/exec/resize`)

  Ruslan Nigmatullin · 2026-03-06 17:30:17 -08:00
  e9bd8b20a1
• feat: drop sqlite db feature flag (#13750)
  jif-oai · 2026-03-06 17:57:52 +01:00
  fa16c26908
• treat SIGTERM like ctrl-c for graceful shutdown (#13594)

  treat SIGTERM the same as SIGINT for graceful app-server websocket
  shutdown

  Max Johnson · 2026-03-05 18:16:58 +00:00
  1980b6ce00
• app-server: source /feedback logs from sqlite at trace level (#12969)

  ## Summary
  - write app-server SQLite logs at TRACE level when SQLite is enabled
  - source app-server `/feedback` log attachments from SQLite for the
  requested thread when available
  - flush buffered SQLite log writes before `/feedback` queries them so
  newly emitted events are not lost behind the async inserter
  - include same-process threadless SQLite rows in those `/feedback` logs
  so the attachment matches the process-wide feedback buffer more closely
  - keep the existing in-memory ring buffer fallback unchanged, including
  when the SQLite query returns no rows
  
  ## Details
  - add a byte-bounded `query_feedback_logs` helper in `codex-state` so
  `/feedback` does not fetch all rows before truncating
  - scope SQLite feedback logs to the requested thread plus threadless
  rows from the same `process_uuid`
  - format exported SQLite feedback lines with the log level prefix to
  better match the in-memory feedback formatter
  - add an explicit `LogDbLayer::flush()` control path and await it in
  app-server before querying SQLite for feedback logs
  - pass optional SQLite log bytes through `codex-feedback` as the
  `codex-logs.log` attachment override
  - leave TUI behavior unchanged apart from the updated `upload_feedback`
  call signature
  - add regression coverage for:
    - newest-within-budget ordering
    - excluding oversized newest rows
    - including same-process threadless rows
    - keeping the newest suffix across mixed thread and threadless rows
    - matching the feedback formatter shape aside from span prefixes
    - falling back to the in-memory snapshot when SQLite returns no logs
    - flushing buffered SQLite rows before querying
  
  ## Follow-up
  - SQLite feedback exports still do not reproduce span prefixes like
  `feedback-thread{thread_id=...}:`; there is a `TODO(ccunningham)` in
  `codex-rs/state/src/log_db.rs` for that follow-up.
  
  ## Testing
  - `cd codex-rs && cargo test -p codex-state`
  - `cd codex-rs && cargo test -p codex-app-server`
  - `cd codex-rs && just fmt`

  Charley Cunningham · 2026-03-03 11:17:06 -08:00
  c4bd0aa3b9
• fix(app-server): emit turn/started only when turn actually starts (#13261)

  This is a follow-up for https://github.com/openai/codex/pull/13047
  
  ## Why
  We had a race where `turn/started` could be observed before the thread
  had actually transitioned to `Active`. This was because we eagerly
  emitted `turn/started` in the request handler for `turn/start` (and
  `review/start`).
  
  That was showing up as flaky `thread/resume` tests, but the real issue
  was broader: a client could see `turn/started` and still get back an
  idle thread immediately afterward.
  
  The first idea was to eagerly call
  `thread_watch_manager.note_turn_started(...)` from the `turn/start`
  request path. That turns out to be unsafe, because
  `submit(Op::UserInput)` only queues work. If a turn starts and completes
  quickly, request-path bookkeeping can race with the real lifecycle
  events and leave stale running state behind.
  
  **The real fix** is to move `turn/started` to emit only after the turn
  _actually_ starts, so we do that by waiting for the
  `EventMsg::TurnStarted` notification emitted by codex core. We do this
  for both `turn/start` and `review/start`.
  
  I also verified this change is safe for our first-party codex apps -
  they don't have any assumptions that `turn/started` is emitted before
  the RPC response to `turn/start` (which is correct anyway).
  
  I also removed `single_client_mode` since it isn't really necessary now.
  
  ## Testing
  - `cargo test -p codex-app-server thread_resume -- --nocapture`
  - `cargo test -p codex-app-server
  'suite::v2::turn_start::turn_start_emits_notifications_and_accepts_model_override'
  -- --exact --nocapture`
  - `cargo test -p codex-app-server`

  Owen Lin · 2026-03-02 16:43:31 -08:00
  146b798129
• feat(app-server): add tracing to all app-server APIs (#13285)

  ### Overview
  This PR adds the first piece of tracing for app-server JSON-RPC
  requests.
  
  There are two main changes:
  - JSON-RPC requests can now take an optional W3C trace context at the
  top level via a `trace` field (`traceparent` / `tracestate`).
  - app-server now creates a dedicated request span for every inbound
  JSON-RPC request in `MessageProcessor`, and uses the request-level trace
  context as the parent when present.
  
  For compatibility with existing flows, app-server still falls back to
  the TRACEPARENT env var when there is no request-level traceparent.
  
  This PR is intentionally scoped to the app-server boundary. In a
  followup, we'll actually propagate trace context through the async
  handoff into core execution spans like run_turn, which will make
  app-server traces much more useful.
  
  ### Spans
  A few details on the app-server span shape:
  - each inbound request gets its own server span
  - span/resource names are based on the JSON-RPC method (`initialize`,
  `thread/start`, `turn/start`, etc.)
  - spans record transport (stdio vs websocket), request id, connection
  id, and client name/version when available
  - `initialize` stores client metadata in session state so later requests
  on the same connection can reuse it

  Owen Lin · 2026-03-02 16:01:41 -08:00
  d473e8d56d
• app-server: Replay pending item requests on thread/resume (#12560)

  Replay pending client requests after `thread/resume` and emit resolved
  notifications when those requests clear so approval/input UI state stays
  in sync after reconnects and across subscribed clients.
  
  Affected RPCs:
  - `item/commandExecution/requestApproval`
  - `item/fileChange/requestApproval`
  - `item/tool/requestUserInput`
  
  Motivation:
  - Resumed clients need to see pending approval/input requests that were
  already outstanding before the reconnect.
  - Clients also need an explicit signal when a pending request resolves
  or is cleared so stale UI can be removed on turn start, completion, or
  interruption.
  
  Implementation notes:
  - Use pending client requests from `OutgoingMessageSender` in order to
  replay them after `thread/resume` attaches the connection, using
  original request ids.
  - Emit `serverRequest/resolved` when pending requests are answered
  or cleared by lifecycle cleanup.
  - Update the app-server protocol schema, generated TypeScript bindings,
  and README docs for the replay/resolution flow.
  
  High-level test plan:
  - Added automated coverage for replaying pending command execution and
  file change approval requests on `thread/resume`.
  - Added automated coverage for resolved notifications in command
  approval, file change approval, request_user_input, turn start, and turn
  interrupt flows.
  - Verified schema/docs updates in the relevant protocol and app-server
  tests.
  
  Manual testing:
  - Tested reconnect/resume with multiple connections.
  - Confirmed state stayed in sync between connections.

  Ruslan Nigmatullin · 2026-02-27 12:45:59 -08:00
  69d7a456bb
• Enforce user input length cap (#12823)

  Currently there is no bound on the length of a user message submitted in
  the TUI or through the app server interface. That means users can paste
  many megabytes of text, which can lead to bad performance, hangs, and
  crashes. In extreme cases, it can lead to a [kernel
  panic](https://github.com/openai/codex/issues/12323).
  
  This PR limits the length of a user input to 2**20 (about 1M)
  characters. This value was chosen because it fills the entire context
  window on the latest models, so accepting longer inputs wouldn't make
  sense anyway.
  
  Summary
  - add a shared `MAX_USER_INPUT_TEXT_CHARS` constant in codex-protocol
  and surface it in TUI and app server code
  - block oversized submissions in the TUI submit flow and emit error
  history cells when validation fails
  - reject heavy app-server requests with JSON-RPC `-32602` and structured
  `input_too_large` data, plus document the behavior
  
  Testing
  - ran the IDE extension with this change and verified that when I
  attempt to paste a user message that's several MB long, it correctly
  reports an error instead of crashing or making my computer hot.

  Eric Traut · 2026-02-25 22:23:51 -08:00
  28bfbb8f2b