7919 Commits

This Branch

This Branch

All Branches

• Extract TUI plugin catalog rendering (#28768)

  This mechanically extracts the existing TUI plugin catalog and detail
  popup rendering from `chatwidget/plugins.rs` into a new
  `chatwidget/plugin_catalog.rs` module. `plugins.rs` now keeps the
  stateful plugin workflow and orchestration, while `plugin_catalog.rs`
  owns the presentation-heavy catalog/detail popup construction and its
  pure helpers. The goal is to keep `plugins.rs` focused before later
  plugin sharing work adds more catalog behavior.
  
  - Moves existing catalog/detail popup builders and related pure helpers
  into `plugin_catalog.rs`
  - Leaves plugin fetch/state/key handling in `plugins.rs`
  - Adds only minimal sibling-module visibility/import wiring
  - Intentionally makes no product behavior or UI changes beyond the code
  move

  canvrno-oai · 2026-06-17 11:57:19 -07:00
  b668abb488
• [codex] Restore thread recency with compatible migration history (#28671)

  ## Summary
  
  - Revert #28655, restoring the thread `recencyAt` behavior introduced by
  #27910.
  - Move `threads_recency_at` to migration 0039 so it no longer collides
  with `external_agent_config_imports` at version 0038.
  - Repair databases that already applied the recency migration as version
  38 by moving the matching migration-history row to version 39 before
  SQLx validation. The current version-38 migration can then apply
  normally.
  
  ## Validation
  
  - `just test -p codex-state
  migrations::tests::repairs_recency_migration_that_was_applied_as_version_38`
  - `just test -p codex-state -p codex-rollout -p codex-thread-store -p
  codex-app-server-protocol -p codex-tui`: 3,439 passed; six TUI tests
  could not open the machine's existing read-only incident database at
  `~/.codex/sqlite/state_5.sqlite`.
  - `just fix -p codex-state`
  - `just fmt`
  - Verified that state migration versions are unique.

  Jeremy Rose · 2026-06-17 18:52:18 +00:00
  7dc7096ae1
• feat: add run task identity primitives (#19047)

  ## Stack
  
  This is PR 1 of the simplified HAI single-run-task stack:
  
  - [#19047](https://github.com/openai/codex/pull/19047) Agent Identity
  assertion and task-registration primitives, including the shared
  run-task helper used by existing Agent Identity JWT auth.
  - [#19049](https://github.com/openai/codex/pull/19049)
  Disabled-by-default ChatGPT auth opt-in that provisions/reuses persisted
  Agent Identity runtime auth and its single run task.
  - [#19051](https://github.com/openai/codex/pull/19051) Run-scoped
  provider auth that uses one backend-owned task id for first-party
  inference and compaction requests.
  
  [#19054](https://github.com/openai/codex/pull/19054) collapsed out of
  the active stack because the simplified design no longer needs a
  separate background/control-plane task helper.
  
  ## Summary
  
  The simplified POC shape is one backend-owned task per Agent Identity
  run. This PR makes the first layer match that final shape directly
  instead of introducing task targets, caller-owned external task refs, or
  intermediate wrappers that later PRs would need to undo.
  
  What changed:
  
  - keeps the `AgentAssertion` wire payload as `agent_runtime_id`,
  `task_id`, `timestamp`, and `signature`
  - exposes `register_agent_task` as the single task-registration helper
  for both existing Agent Identity JWT auth and the ChatGPT-registration
  path added later in the stack
  - makes task registration send only the signed registration timestamp;
  the backend owns the returned opaque task id
  - removes the unused target/task-kind/external-task-ref surfaces from
  `codex-agent-identity`
  - keeps Agent Identity JWT JWKS lookup separate from agent/task
  registration URL derivation
  - updates Agent Identity JWT auth to register one run task during auth
  construction and share that task across cloned auth handles
  
  This PR intentionally does not enable ChatGPT-derived Agent Identity.
  That opt-in and config gate are added in the next PR.
  
  ## Testing
  
  - `just test -p codex-agent-identity`

  Adrian · 2026-06-17 11:23:39 -07:00
  d9e0551564
• Scope command approvals by execution environment (#28738)

  ## Why
  
  Command approval cache keys included the command and working directory,
  but not the execution environment. An approval for `/workspace` locally
  could therefore be reused for the same command and path on an executor.
  
  ## What changed
  
  - Include the selected environment ID in shell and unified-exec approval
  cache keys.
  - Carry that ID through the normal command approval request so clients
  can show which environment is being approved.
  - Expose the environment through app-server as a required nullable
  `environmentId` and show it in the inline TUI approval prompt.
  - Keep older recorded approval events compatible when the environment is
  absent.
  
  For example, `echo ok` in local `/workspace` and `echo ok` in executor
  `/workspace` now produce different approval keys and separate prompts.
  
  ## Scope
  
  This PR does not change network approvals, Guardian review actions, MCP
  elicitation, full-screen TUI rendering, or environment-ID validation.
  Remote `shell_command` execution itself remains in #28722; this PR only
  makes its approval key environment-aware.

  jif · 2026-06-17 19:52:43 +02:00
  1391d786bc
• Tell codex to avoid changing rollout format. (#28632)

  Just adds a requirement to the path-types skill to nudge Codex away from
  touching rollout types while migrating paths.

  Adam Perry @ OpenAI · 2026-06-17 10:51:41 -07:00
  b947695a98
• [codex] Repair invalid skill frontmatter scalars (#28628)

  ## Why
  
  The community marketplace audit found many skill frontmatter parse
  failures where values were intended as prose, but were not valid YAML.
  Common examples include unquoted scalar values with `: `, such as
  `description: Build for AWS: ECS` or `argument-hint: <duration: e.g.
  7d>`, and flow-looking values such as `tags: [next,@supabase/ssr]`.
  
  `serde_yaml` does not expose a permissive mode for this. The parser
  fails before unknown frontmatter fields can be ignored, so a
  compatibility repair has to happen before retrying YAML parsing.
  
  ## What changed
  
  Skill frontmatter loading still uses `serde_yaml` as the primary parser.
  If that parse fails, the loader performs a line-oriented repair of
  scalar frontmatter field values, then retries parsing.
  
  The fallback now:
  
  - applies to any frontmatter mapping field, not just `description` /
  `short-description`
  - quotes unquoted scalar values that contain a YAML colon separator such
  as `: `
  - quotes invalid flow-looking scalar values that start with `[`, `{`,
  `@`, or backtick
  - preserves already quoted values
  - skips `|` / `>` block scalar bodies so multiline descriptions are not
  rewritten
  - returns the original YAML error if the repaired frontmatter still
  cannot parse
  
  ## Examples
  
  This previously failed because the second `: ` was parsed as YAML
  structure:
  
  ```yaml
  description: AWS deployment patterns: ECS Fargate, Lambda, and S3
  ```
  
  The fallback now parses it as if it had been written explicitly as:
  
  ```yaml
  description: 'AWS deployment patterns: ECS Fargate, Lambda, and S3'
  ```
  
  The same repair now applies to ignored frontmatter fields that still
  need to be valid YAML for the parser to get through the document:
  
  ```yaml
  argument-hint: <duration: e.g. 7d, 2w>
  tags: [next,@supabase/ssr]
  ```
  
  Valid YAML multiline descriptions continue to work through normal
  parsing without repair:
  
  ```yaml
  description: |-
    Build for AWS: ECS
    and Lambda
  ```
  
  ## Validation
  
  - Added loader coverage for unquoted `description` values containing `:
  `.
  - Added loader coverage for unquoted `metadata.short-description` values
  containing `: ` and an apostrophe.
  - Added loader coverage for unrecognized frontmatter fields that need
  quoting, including `argument-hint` and `tags`.
  - Added block-scalar coverage to ensure multiline description bodies are
  preserved while other fields are repaired.
  - `just test -p codex-core-skills` (106 passed)
  - `just fix -p codex-core-skills`

  charlesgong-openai · 2026-06-17 10:37:14 -07:00
  0065c3a17d
• Run fs helper through Windows sandbox wrapper (#28359)

  ## Why
  
  This is the final PR in the Windows fs-helper sandbox stack and contains
  the actual bug fix.
  
  The exec-server filesystem helper is a direct-spawn path: it asks
  `SandboxManager` for a `SandboxExecRequest`, then launches the returned
  argv itself. That works on macOS and Linux because the transformed argv
  is already a self-contained sandbox wrapper. On Windows, the transformed
  request carried `WindowsRestrictedToken` metadata, but the direct-spawn
  fs-helper runner still launched the helper argv directly.
  
  That means Windows filesystem built-ins backed by the fs-helper could
  run with the parent Codex process permissions instead of the configured
  Windows sandbox. This PR makes the direct-spawn transform produce a
  self-contained Windows wrapper argv before fs-helper launches it.
  
  ## What Changed
  
  - Added `SandboxManager::transform_for_direct_spawn()` for callers that
  launch the returned argv themselves.
  - Wrapped Windows restricted-token direct-spawn requests with `codex.exe
  --run-as-windows-sandbox` and then marked the outer request as
  unsandboxed, matching the macOS/Linux wrapper argv shape.
  - Updated `exec-server/src/fs_sandbox.rs` to use the direct-spawn
  transform for fs-helper launches.
  - Materialized the inner `codex.exe --codex-run-as-fs-helper` executable
  into `.sandbox-bin` so the sandboxed user can run it.
  - Carried runtime workspace roots through `FileSystemSandboxContext` as
  `PathUri` values so `:workspace_roots` policies resolve correctly
  without sending native client paths over exec-server JSON.
  - Preserved wrapper setup identity environment needed by Windows sandbox
  setup without changing the serialized inner helper environment.
  
  ## Verification
  
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just test -p codex-sandboxing transform_for_direct_spawn_windows`
  - `just test -p codex-exec-server fs_sandbox::tests`
  - `just fix -p codex-windows-sandbox -p codex-sandboxing -p
  codex-exec-server -p codex-core -p codex-file-system`
  
  Local note: `just fmt` completed Rust formatting, but this workstation
  still fails the non-Rust formatter phases because uv cannot open its
  cache and the local buildifier/dotslash path is missing.

  iceweasel-oai · 2026-06-17 10:00:42 -07:00
  ef75171f18
• [ez][codex-rs] Support apps._default.default_tools_approval_mode (#27965)

  [from codex]
  
  ## Summary
  
  - add `default_tools_approval_mode` to `[apps._default]` and expose it
  through app-server v2 `config/read`
  - apply it after managed, per-tool, and per-app approval settings,
  before the built-in `auto` fallback
  - document the precedence, regenerate config/app-server schemas, and add
  unit plus end-to-end approval coverage
  
  ## Configuration
  
  ```toml
  [apps._default]
  default_tools_approval_mode = "prompt"
  ```
  
  The effective precedence is managed requirements, tool-specific
  `approval_mode`, app-specific `default_tools_approval_mode`,
  `apps._default.default_tools_approval_mode`, then `auto`.
  
  ## Test plan
  
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `just write-app-server-schema --experimental`
  - `just test -p codex-core app_tool_policy`
  - `just test -p codex-core mcp_turn_metadata`
  - `just test -p codex-config`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server config_read_includes_apps`
  - `just fix -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-app-server`
  - `just fmt`

  Alex Zamoshchin · 2026-06-17 08:50:39 -07:00
  c78911e37f
• Replace SkillsManager with SkillsService (#28705)

  ## Why
  
  Host skill discovery was still exposed as a manager even though it is a
  process-owned service shared by sessions, the app-server catalog, and
  file-watcher invalidation. The skills extension also consumed an ad hoc
  loaded-skills wrapper instead of a named immutable snapshot.
  
  ## What changed
  
  - replace `SkillsManager` with concrete `SkillsService`
  - make the service cache and return immutable `HostSkillsSnapshot`
  values
  - migrate the skills extension host provider to the snapshot boundary
  - migrate app-server catalog, watcher, and invalidation paths to the
  service
  
  This keeps the service limited to host discovery, caching, roots, and
  invalidation. Catalog rendering and invocation remain extension
  responsibilities for the next stacked change.

  jif · 2026-06-17 17:01:06 +02:00
  0318381762
• app-server: keep the model cache warm (#28699)

  ## Why
  
  The app server is long-lived, but its shared model cache otherwise
  refreshes only when a caller needs it. Once the five-minute cache
  expires, starting a thread or calling `model/list` can wait for
  `/models` on the request path.
  
  Refresh the cache in the background before it expires so foreground
  callers normally use fresh local state.
  
  ## What changed
  
  - Start an app-server worker that refreshes models immediately and then
  every three minutes using the existing models-manager API.
  - Hold only a weak reference to the models manager between refreshes, so
  the worker does not extend its lifetime.
  - Stop scheduling refreshes when the app-server lifecycle handle is shut
  down or dropped. A refresh already in progress is allowed to finish.
  - Adjust affected app-server test fixtures to distinguish the background
  `/models` probe from the connection they are testing.
  
  The existing models-manager cache, refresh strategies, auth handling,
  ETag behavior, and concurrency semantics are unchanged.
  
  ## Testing
  
  -
  `models_refresh_worker::tests::refreshes_immediately_periodically_and_stops_when_dropped`
  -
  `suite::v2::remote_control::listen_off_honors_persisted_remote_control_enable`
  -
  `suite::v2::attestation::attestation_generate_round_trip_adds_header_to_responses_websocket_handshake`

  jif · 2026-06-17 16:18:39 +02:00
  5935a90619
• Add join key for MAv2 inter-agent messages (#28561)

  ## Summary
  This keeps inter-agent communication on the existing raw response item
  path and adds a join key for MAv2 tool calls.
  
  MAv2 `spawn_agent`, `send_message`, and `followup_task` now stamp the
  originating tool call id into `ResponseItemMetadata.source_call_id` on
  the raw `ResponseItem::AgentMessage`. App-server clients can join that
  raw item back to the existing tool/activity event by call id, while
  using the raw agent message's existing sender, receiver, and content
  fields.
  
  No new app-server `ThreadItem` or notification type is added.
  
  ## Tests
  - `just fmt`
  - `just write-app-server-schema`
  - `just test -p codex-protocol`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-core
  multi_agent_v2_spawn_returns_path_and_send_message_accepts_relative_path`
  - `just test -p codex-core
  multi_agent_v2_followup_task_completion_notifies_parent_on_every_turn`
  - `just fix -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core`

  jif · 2026-06-17 14:48:56 +02:00
  45f603302c
• Back off registry retries during exec recovery (#28546)

  ## Why
  
  PR #28512 retries a failed session recovery every 100 ms. Every Noise
  recovery attempt first asks the environment registry for a fresh
  connection bundle, even when the eventual failure comes from the
  WebSocket or initialize handshake. During an outage, that could make
  each disconnected client call the registry about 250 times during the
  25-second recovery window.
  
  ## What changes
  
  All retryable Noise recovery failures now use a separate backoff
  schedule:
  
  ```text
  base:    500 ms -> 1 s -> 2 s -> 4 s -> 5 s maximum
  actual:  500-750 ms, 1-1.5 s, 2-3 s, 4-6 s, 5-7.5 s
  ```
  
  The extra 0-50% is deterministic per-session jitter so disconnected
  clients do not retry together. Direct WebSocket recovery keeps the
  existing 100 ms retry because it does not re-enter the registry.

  jif · 2026-06-17 11:52:23 +02:00
  a5229e0686
• Resume exec-server sessions after disconnect (#28512)

  Supersedes #28288 (closed).
  
  ## Why
  
  A short WebSocket interruption currently ends every client-side process
  handle, even though exec-server keeps the server session and its
  processes alive for a short time.
  
  This is especially visible for executor-backed stdio MCP servers: a
  temporary connection loss becomes a permanent `Transport closed` error.
  The server already has the information needed to resume the session, but
  the client opens a fresh session instead of using it.
  
  This change reconnects below the process and MCP layers. Existing
  process handles stay valid, missed output is recovered, and the same
  server-side processes continue running.
  
  ## State machine
  
  One logical `ExecServerClient` stays alive while its underlying RPC
  connection changes generations.
  
  ```text
                           transport closes
         +------------------------------------------------+
         |                                                v
  +-------------+                                  +-------------+
  |  Connected  |                                  | Recovering  |
  +-------------+                                  +-------------+
         ^                                                |
         | session resumed, processes caught up           | retryable error
         +------------------------------------------------+ loops until deadline
                                                          |
                                                          | deadline or permanent error
                                                          v
                                                    +-------------+
                                                    |   Failed    |
                                                    +-------------+
  ```
  
  ### `Connected`
  
  - New RPC calls use the current connection.
  - Process notifications are published in sequence order.
  - A disconnect only starts recovery if it came from the current
  connection generation. Late events from older generations cannot replace
  the active connection.
  
  ### `Recovering`
  
  - New calls wait instead of choosing a half-connected RPC client.
  - Existing process handles, wake subscriptions, and event subscriptions
  stay open.
  - Streaming HTTP response bodies fail immediately because their byte
  streams cannot be resumed safely.
  - Recovery first waits for process starts that were already in flight. A
  start whose result became ambiguous is cleaned up after reconnection
  instead of being silently adopted.
  - The client reconnects with the learned `session_id`. The server may
  briefly report that the old connection is still attached, so that error
  is retried until the detach finishes.
  - The notification consumer starts before the resume handshake
  completes. This prevents a busy process from filling the notification
  queue and blocking the initialize response.
  - Before installing the new connection, the client catches up every
  recoverable process with `process/read`.
  
  ### `Failed`
  
  - Recovery stops after 25 seconds or after a permanent error.
  - Waiting calls are released with one stable disconnect error.
  - Existing process sessions receive a terminal failure instead of
  waiting forever.
  
  ## Recovering process events
  
  Output, exit, and close events share one sequence. During normal
  operation, the client buffers early events until every lower sequence
  has been published.
  
  After reconnection, the client reads each process starting after its
  last published sequence:
  
  1. Retained output chunks are inserted by sequence number.
  2. Exit and close state are reconstructed in their sequence positions.
  3. Events already received as live notifications are ignored as
  duplicates.
  4. Newly contiguous events are published in order.
  5. If the server no longer retains enough output to fill a sequence gap,
  only that process is terminated and failed. The recovered connection
  remains usable for other processes.
  
  The server reports its full next event sequence for unbounded reads,
  including exit and close events. Closed processes remain readable for
  the same 30-second window used to retain detached sessions.
  
  ## Other details
  
  - Detached server sessions are retained for 30 seconds, leaving margin
  around the client's 25-second recovery deadline.
  - Session attach and detach update the active notification sender under
  the same attachment lock, so an old connection cannot clear a newly
  attached sender.
  - A dedicated error code distinguishes the temporary "session is still
  attached" race from permanent initialization errors.
  - Process starts are identity-checked on both client and server. Cleanup
  from an older start cannot remove a newer process that reused the same
  ID.
  - Mutating requests that were already in flight when the transport
  closed are not replayed, because the client cannot know whether the
  server applied them. Requests started after recovery is known wait for
  the replacement connection.
  - We assume the server/client version stays in sync (on the before/after
  this PR)
  
  ## User impact
  
  Long-running commands and stdio MCP servers can survive a temporary
  exec-server WebSocket interruption without changing process IDs or
  losing output produced during the outage.

  jif · 2026-06-17 10:20:39 +02:00
  cf17e1bc20
• [codex] Persist built-in image results reported as generating (#28656)

  ## Why
  
  #27920 stopped persisting image-generation items unless their status was
  `completed`, preventing failed standalone extension items with empty
  results from being saved. Built-in image generation can instead emit a
  terminal `response.output_item.done` containing a complete base64 PNG
  while the item status remains `generating`. In that case, app-server
  emits no `savedPath`, so Codex Apps can render the inline image but
  cannot expose a file artifact.
  
  ## What changed
  
  - Persist image-generation items whenever `result` contains image data.
  Failed terminal items still have empty results and remain unpersisted.
  - Update the existing built-in image-generation integration test to
  cover a terminal `generating` item and verify both `saved_path` and the
  written PNG bytes.
  
  ## Validation
  
  - Confirmed with a raw built-in websocket trace: the image progressed
  through `in_progress`, `generating`, and `partial_image`, then emitted
  one `response.output_item.done` with `status: "generating"` and a
  complete PNG result.
  - `just test -p codex-core builtin_image_generation_call_persisted` is
  currently blocked before test execution by a pre-existing compile error
  in `thread-store/src/thread_metadata_sync.rs:171`.

  Won Park · 2026-06-17 06:03:00 +00:00
  1315198853
• core: remove redundant TurnContext and Prompt fields (#28638)

  ## Why
  
  `TurnContext` had accumulated dead fields and cached projections of
  values already owned by its per-turn `Config` or `ModelInfo`. Keeping
  both copies made ownership unclear and allowed artificial split-brain
  states, such as a compatibility hash differing from the model metadata
  it came from.
  
  `Prompt` similarly carried a write-only personality after personality
  selection had already been materialized into its base instructions.
  
  This makes the canonical owner explicit: configuration-backed values
  come from `config`, model-derived values come from `model_info`, and
  prompts contain only data consumed by request construction.
  
  ## What changed
  
  - Remove the unused `ghost_snapshot`, `codex_self_exe`, and
  `thread_source` fields.
  - Remove duplicate `comp_hash`, `truncation_policy`, `features`,
  `shell_environment_policy`, `codex_linux_sandbox_exe`, `compact_prompt`,
  and `tool_mode` fields.
  - Read those values directly from `TurnContext::config` or
  `TurnContext::model_info` at their consumers.
  - Remove the write-only `Prompt::personality` field and its constructor
  assignments.
  - Preserve review-turn inheritance of the parent turn's shell policy,
  Linux sandbox executable, and compact prompt through the review config.
  
  ## Testing
  
  - `cargo check -p codex-core --tests`

  pakrym-oai · 2026-06-16 22:17:24 -07:00
  172b2218a5
• Revert thread recencyAt for sidebar ordering (#28655)

  ## Why
  
  Revert #27910 to remove the newly introduced thread `recencyAt`
  persistence and API behavior from `main`.
  
  ## What changed
  
  This reverts commit `fac3158c2a783095768076489815f361fa9b0db4`,
  including the state migration, thread-store propagation, app-server API
  surface, generated schemas, and related tests.
  
  ## Validation
  
  Not run before opening; relying on CI for the initial fast signal.

  pakrym-oai · 2026-06-16 21:39:30 -07:00
  cb15c64760
• [codex] Test code-mode variable truncation (#28471)

  ## Summary
  
  Code mode has two separate truncation points: the nested tool result
  returned to JavaScript and the code-mode output later recorded for the
  model. These tests now verify those behaviors independently.
  
  - Report whether `result.output` was truncated before printing it.
  - Verify omitted or sufficiently large nested limits produce `Variable
  truncated: False`, while allowing the printed value to be truncated
  downstream.
  - Verify an explicit nested limit produces `Variable truncated: True`
  when the command output exceeds it.
  - Use a token-policy model fixture so downstream truncation is visible
  as `…N tokens truncated…`.
  - Align the explicit nested-truncation expectation with the warning
  header.
  
  This PR changes test coverage only; runtime truncation behavior is
  unchanged.
  
  ## Validation
  
  - `env -u CODEX_SANDBOX_NETWORK_DISABLED RUST_MIN_STACK=8388608 cargo
  test -p codex-core --test all code_mode_exec -- --nocapture` (8 passed)

  Ahmed Ibrahim · 2026-06-16 20:14:23 -07:00
  0a3ad4c4ba
• code-mode: move cell state into library actor (#28599)

  A code-mode cell is a single JavaScript execution that can produce
  output, call tools, wait for asynchronous work, resume, or be
  terminated. This PR extracts the existing per-cell run loop into a
  dedicated actor that owns the cell’s lifecycle state. It is primarily an
  ownership change rather than a new lifecycle contract: existing behavior
  now has one clear implementation boundary.
  
  ### Architecture
  The session service remains responsible for session-wide concerns:
  allocating cell IDs, storing shared values, creating cells, and routing
  requests to them.
  
  Once a cell is created, its execution state belongs to its actor.
  Callers interact with the actor through a handle. The actor receives two
  kinds of input: runtime events and control requests.
  
  A single event loop serializes these inputs and applies the lifecycle
  rules. It tracks the current observer—the caller waiting for an
  update—along with accumulated output, outstanding callbacks, runtime
  state, yield deadlines, and termination progress. Observation,
  termination, completion, and cleanup therefore have one consistent
  owner.
  
  When the runtime has no immediately runnable work and is waiting only on
  timers or tool results, the actor can return accumulated output and
  information about outstanding tool calls while keeping the cell
  available to resume. On completion or termination, it performs the
  appropriate callback cleanup before publishing the final result and
  removing the cell from the session.
  
  A small host interface connects the actor to session-owned facilities
  such as tool dispatch, notifications, stored values, and final cell
  removal, keeping those responsibilities outside the actor itself.
  
  ### Why
  Previously, cell lifecycle state and coordination lived alongside
  session management. The actor boundary makes each cell a self-contained
  state machine with a single writer, while the service becomes a registry
  and adapter around it.
  
  This makes lifecycle behavior easier to reason about and test in
  isolation. It also establishes a clean boundary for later changing where
  cells run or how they communicate without recreating their lifecycle
  rules.

  Channing Conger · 2026-06-16 19:28:55 -07:00
  e2f074e16c
• [codex] Support object-valued plugin MCP manifests (#28580)

  ## Summary
  This fixes plugin manifest parsing for MCP servers declared as an object
  directly in `plugin.json`.
  
  Before this change, Codex modeled `mcpServers` as only a string path,
  for example:
  
  ```json
  {
    "name": "counter-sample",
    "version": "1.1.1",
    "mcpServers": "./.mcp.json"
  }
  ```
  
  Some migrated plugins instead provide the server map directly in the
  manifest:
  
  ```json
  {
    "name": "counter-sample",
    "version": "1.1.1",
    "description": "Plugin that declares MCP servers in the manifest",
    "mcpServers": {
      "counter": {
        "type": "http",
        "url": "https://sample.example/counter/mcp"
      }
    }
  }
  ```
  
  That object form previously failed during install/load with an error
  like:
  
  ```text
  failed to parse plugin manifest: invalid type: map, expected a string
  ```
  
  ## What changed
  - Add a manifest representation for `mcpServers` as either
  `Path(Resource)` or `Object(map)`.
  - Parse `plugin.json` `mcpServers` as either a string path or an object.
  - Route object-valued MCP server maps through the existing plugin MCP
  config parser instead of adding a second parser.
  - Apply existing per-plugin MCP server policy to object-valued MCP
  servers the same way as file-backed MCP servers.
  - Include object-valued MCP server names in plugin telemetry/capability
  metadata.
  - Support object-valued MCP config for executor plugins without
  requiring a `.mcp.json` filesystem read.
  - Update the bundled plugin-creator validator and `plugin-json-spec.md`
  so generated-plugin validation accepts the same object-valued shape.
  
  ## Compatibility
  Existing plugin manifests that use `"mcpServers": "./.mcp.json"`
  continue to work. Plugins can now also use the object shape shown above.
  
  ## Tests
  Added coverage for the new manifest attribute shape at the install,
  normal load, telemetry, and executor-provider layers:
  
  - `install_accepts_manifest_mcp_server_objects`
  - `load_plugins_loads_manifest_mcp_server_objects`
  - `plugin_telemetry_metadata_uses_manifest_mcp_server_objects`
  - `reads_manifest_object_config_without_executor_file_system_access`
  
  Also smoke-tested the plugin-creator validator against both supported
  forms:
  
  - `mcpServers` as a direct object in `plugin.json`
  - `mcpServers` as `"./.mcp.json"` with a companion `.mcp.json`
  
  ## Validation
  - `just test -p codex-plugin`
  - `just test -p codex-core-plugins`
  - `just test -p codex-mcp-extension`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fmt`
  - `git diff --check`
  - Focused rename/object-form rerun: `just test -p codex-core-plugins
  manager::tests::load_plugins_loads_manifest_mcp_server_objects
  manager::tests::plugin_telemetry_metadata_uses_manifest_mcp_server_objects
  store::tests::install_accepts_manifest_mcp_server_objects`
  - Focused executor rerun: `just test -p codex-mcp-extension
  executor_plugin::provider::tests::reads_manifest_object_config_without_executor_file_system_access`
  - `python3
  codex-rs/skills/src/assets/samples/plugin-creator/scripts/validate_plugin.py
  /private/tmp/codex-validator-object`
  - `python3
  codex-rs/skills/src/assets/samples/plugin-creator/scripts/validate_plugin.py
  /private/tmp/codex-validator-path`

  charlesgong-openai · 2026-06-16 19:22:57 -07:00
  1883dedc0e
• thread-store: fix response fixture compilation (#28642)

  ## Why
  
  A `codex-thread-store` test fixture still constructs
  `ResponseItem::FunctionCallOutput` without its required `metadata`
  field, preventing the crate's test targets from compiling on `main`.
  
  ## What changed
  
  - Set the fixture's response-item metadata to `None`.
  
  ## Testing
  
  - `cargo check -p codex-thread-store --tests`

  pakrym-oai · 2026-06-16 19:16:16 -07:00
  6f77491e95
• [codex] core: restore absolute turn context cwd (#28629)

  ## Why
  
  #28152 jumped the gun on moving the rollout format to store URIs, and
  would likely break compat with some features that don't go through the
  same types as the core logic.
  
  ## What
  
  Make `TurnContextItem.cwd` an `AbsolutePathBuf` again, remove test added
  for `PathUri` serialization in rollouts. Also drops a bunch of error
  paths that are no longer needed.

  Adam Perry @ OpenAI · 2026-06-16 19:05:26 -07:00
  3d02c443bc
• [codex] Gate remote plugin catalog by auth (#28625)

  ## Summary
  
  - Treat the remote global plugin catalog as active only when
  `remote_plugin` is enabled and the current auth uses the Codex backend.
  - Skip the local OpenAI curated marketplace for remote-enabled ChatGPT
  users while preserving configured marketplaces.
  - Keep the local curated marketplace for API-key users, unauthenticated
  fallback, and ChatGPT users with `remote_plugin` disabled.
  - Apply the same effective-remote gate to the remote
  installed-marketplace cache.
  
  ## Root cause
  
  The tool-suggestion discovery path unconditionally included the local
  OpenAI curated marketplace. For remote-enabled ChatGPT users, that made
  remote discovery additive: Codex parsed every local curated
  `plugin.json` before also loading the remote catalog.
  
  ## Validation
  
  - `just fmt`
  - `cargo build -p codex-cli --bin codex`
  - Targeted auth/feature matrix tests pass, including API-key auth with
  `remote_plugin` enabled.
  - Manual CLI validation confirmed:
    - ChatGPT + remote off includes local curated.
    - ChatGPT + remote on excludes local curated.
    - API-key auth keeps local curated when remote is enabled.
  - `just test -p codex-core-plugins`: 235 passed; one unrelated existing
  marketplace test failed because it loaded the developer's home
  marketplace configuration.

  xl-openai · 2026-06-16 17:24:48 -07:00
  69bc0645ac
• Revert "Tell codex about PathUri serde compat. (#28595)" (#28627)

  This reverts commit bd2a786326, which
  didn't capture all the nuance we need for this migration.

  Adam Perry @ OpenAI · 2026-06-16 17:18:20 -07:00
  bfe90188ad
• Add thread recencyAt for sidebar ordering (#27910)

  ## Summary
  
  Add a server-owned `recencyAt` timestamp and `recency_at` thread-list
  sort key for product recency ordering while preserving the existing
  meaning of `updatedAt` as the latest persisted thread mutation.
  
  This is the server-side alternative to #27697. Rather than narrowing
  `updatedAt`, clients can sort the sidebar by `recency_at` and continue
  treating `updatedAt` as mutation time.
  
  Paired Codex Apps PR:
  [openai/openai#1024599](https://github.com/openai/openai/pull/1024599)
  
  ## Contract
  
  - `recencyAt` initializes when a thread is created.
  - A turn start advances `recencyAt` monotonically.
  - Commentary, agent output, tool results, token/accounting updates, turn
  completion, archive, unarchive, resume, and generic metadata writes do
  not advance it.
  - `updatedAt` retains its existing behavior and continues to advance for
  persisted thread mutations.
  - Current servers populate `recencyAt`; the response field is optional
  in generated TypeScript so clients connected to older servers can fall
  back to `updatedAt`.
  - Filesystem-only fallback uses existing updated/mtime ordering when
  SQLite is unavailable.
  
  ## Persistence and compatibility
  
  Migration 0038 adds second- and millisecond-precision recency columns,
  backfills them from the existing updated timestamp, creates list
  indexes, and includes an insert trigger so older binaries writing to a
  migrated database seed recency without causing later mutations to
  advance it.
  
  Generic metadata upserts preserve existing recency values. Turn-start
  updates use a dedicated monotonic touch, and process-local allocation
  keeps millisecond cursor values unique. State DB list, search, read,
  filtered-list repair, rollout fallback propagation, and app-server
  conversions all carry the new field.
  
  ## API
  
  `Thread` responses include:
  
  ```ts
  recencyAt?: number
  ```
  
  `thread/list` and `thread/search` accept:
  
  ```json
  { "sortKey": "recency_at" }
  ```
  
  Generated TypeScript and JSON schemas are included.
  
  ## Validation
  
  - `just test -p codex-state` — 146 passed
  - `just test -p codex-rollout` — 69 passed
  - `just test -p codex-thread-store` — 81 passed
  - `just test -p codex-app-server-protocol` — 231 passed
  - Focused app-server list ordering, response mapping, archive/unarchive,
  and resume lifecycle tests passed
  - Scoped `just fix` for state, rollout, thread-store,
  app-server-protocol, and app-server
  - `just fmt`
  - `git diff --check`
  - Independent correctness, simplicity, elegance, security, and
  test-quality reviews; actionable ordering, lifecycle, query-projection,
  and timestamp-uniqueness findings were addressed

  Jeremy Rose · 2026-06-16 17:06:22 -07:00
  fac3158c2a
• PAC 1 - Add system proxy feature config surface (#26706)

  ## Summary
  
  Introduces the default-off `respect_system_proxy` feature flag used to
  gate first-class system PAC/proxy support for Codex-owned native
  clients.
  
  With the feature disabled or absent, behavior remains unchanged. This PR
  establishes the configuration and managed-requirement surface; proxy
  discovery and request routing are implemented by follow-up PRs.
  
  ## Configuration
  
  User configuration uses the standard boolean feature form:
  
  ```toml
  [features]
  respect_system_proxy = true
  ```
  
  Managed feature requirements use the corresponding boolean key. The
  effective runtime configuration is exposed as a boolean and defaults to
  `false`.
  
  ## Implementation
  
  - Registers `respect_system_proxy` as an under-development, default-off
  feature.
  - Resolves user configuration and managed feature requirements into
  `Config.respect_system_proxy`.
  - Provides bootstrap resolution for startup paths that must evaluate the
  feature before full configuration loading completes.
  - Uses the standard feature CLI and config-editing behavior.
  - Excludes `features.respect_system_proxy` from project-local
  configuration.
  - Updates the generated configuration schema.
  
  ## End-user behavior
  
  - No networking behavior changes when the feature is absent or disabled.
  - Enabling the feature makes the boolean available to the native
  proxy-routing implementation in follow-up PRs.
  - Repository-local configuration cannot enable the feature.
  
  ## Test coverage
  
  Covers scalar configuration and CLI override resolution, managed
  requirement constraints, bootstrap resolution, and project-local
  filtering.

  canvrno-oai · 2026-06-16 16:54:37 -07:00
  f0cb96bcb1
• [codex] [4/4] Simplify recommended plugin install schema (#28403)

  ## Summary
  - Simplify recommendation-context `request_plugin_install` arguments to
  `plugin_id` and `suggest_reason`.
  - Derive plugin type and install action from the matched candidate while
  preserving Codex-owned elicitation metadata.
  - Keep the legacy list-backed schema unchanged and accept resumed calls
  that still use `tool_id`.
  
  ## Stack
  - #28399
  - #28400
  - #27704
  - This PR
  
  ## Validation
  - `just test -p codex-tools -p codex-core request_plugin_install` (25
  passed)
  - `just fix -p codex-tools -p codex-core`
  - `just fmt`
  - `git diff --check`

  Alex Daley · 2026-06-16 23:44:42 +00:00
  a397b59887
• core: render remote environment cwd natively (#28152)

  ## Why
  
  Model-visible `<environment_context>` should match the environment of
  the executor, not of the app server.
  
  Stacked on #28146.
  
  ## What
  
  - Keep selected environment cwd values as `PathUri` while building
  environment context.
  - Render cwd text using the path convention represented by the URI, with
  the canonical URI as a fallback.
  - Preserve compatibility with legacy `TurnContextItem.cwd` values when
  reconstructing and diffing context.
  - Extend the Wine-backed remote Windows test to assert that the model
  sees `powershell` and `C:\windows`.

  Adam Perry @ OpenAI · 2026-06-16 16:17:47 -07:00
  4c79527e31
• [codex] [3/4] Activate endpoint plugin recommendations (#27704)

  Summary\n- Await endpoint recommendation selection while constructing
  each authenticated turn, removing the first-turn cache race.\n- Snapshot
  and filter endpoint candidates once per turn, then use that same set for
  the bounded contextual user fragment, tool exposure, and exact install
  validation.\n- Keep recommendation selection ephemeral: do not persist
  recommendation state in or gate resumed threads on prior context.\n-
  Hide the legacy list tool in endpoint mode and preserve legacy discovery
  unchanged when the endpoint is disabled or unavailable.\n- Keep remote
  plugin and connector app identities out of model-visible context and
  attach them only to Codex-owned elicitation metadata.\n\nStack\n- 3/4,
  based on #28400.\n- Endpoint client and cache: #28399.\n- Generalized
  suggestion presentation: #28400.\n- Install-schema follow-up:
  #28403.\n\nValidation\n- \n- \n- \n- \n- Full : 2,649 passed and 88
  environment-dependent tests failed because this sandbox cannot write ,
  nest Seatbelt, or locate auxiliary test binaries.

  Alex Daley · 2026-06-16 23:04:07 +00:00
  a34da3b295
• [codex] [2/4] Generalize plugin suggestion presentation (#28400)

  Summary
  - Add list-backed and developer-context presentations for plugin
  suggestion candidates.
  - Let tool planning, install validation, and request-tool copy follow
  the selected presentation.
  - Keep every production caller on the existing list-backed presentation,
  preserving the current list tool, request schema, connector behavior,
  and model-visible copy.
  - Leave developer-context presentation latent until the final PR in the
  stack.
  
  Stack
  - 2/3, based on #28399.
  - Follow-up: #27704 activates endpoint recommendations.
  
  Validation
  - `just test -p codex-core request_plugin_install`
  - `just test -p codex-core spec_plan`
  - `just fix -p codex-core`
  - `just fmt`
  - `git diff --check`

  Alex Daley · 2026-06-16 22:44:10 +00:00
  587487df9e
• [codex] [1/4] Add recommended plugin endpoint cache (#28399)

  Summary
  - Add authenticated parsing for `/ps/plugins/suggested?scope=GLOBAL`,
  including remote plugin and connector app identities.
  - Validate, deduplicate, sort, and cap endpoint candidates before
  caching them by backend and account identity.
  - Deduplicate concurrent cache misses and warm recommendations from the
  existing remote-installed-plugin refresh path used at startup and after
  account changes.
  - Keep endpoint results model-invisible in this PR; failures and
  responses without `enabled: true` resolve to legacy mode.
  
  Stack
  - 1/3. Follow-up: #28400 generalizes plugin suggestion presentation
  without activating endpoint recommendations.
  - Final activation: #27704.
  
  Validation
  - `just test -p codex-core-plugins recommended_plugins`
  - `just fix -p codex-core-plugins`
  - `just fmt`
  - `git diff --check`

  Alex Daley · 2026-06-16 22:22:21 +00:00
  7e735b59ce
• Tell codex about PathUri serde compat. (#28595)

  This addresses another wrinkle I keep having to re-prompt codex about
  when migrating to cross-OS paths.

  Adam Perry @ OpenAI · 2026-06-16 15:01:22 -07:00
  bd2a786326
• app-server: preserve target-native environment cwd (#28146)

  ## Why
  
  app-server may run on a different OS from the selected exec-server
  environment. Parsing that environment’s cwd with the Codex host’s path
  rules prevents thread startup.
  
  ## What
  
  Carry environment cwd values as `LegacyAppPathString` at the app-server
  boundary and `PathUri` internally. Existing tool-call schemas and
  relative-path behavior stay host-native; remaining local-only consumers
  convert explicitly and leave follow-up TODOs.
  
  The Wine integration test verifies app-server can start a thread and
  complete an ordinary turn with a Windows environment cwd from Linux.
  
  ## Validation
  
  - `bazel test //codex-rs/core/tests/remote_env_windows:smoke-test
  --test_output=errors`
  - focused app-server environment-selection and protocol schema tests
  - scoped Clippy for `codex-core` and `codex-app-server-protocol`

  Adam Perry @ OpenAI · 2026-06-16 21:42:28 +00:00
  f8850cab1d
• Record invariants for path migration. (#28589)

  ## Why
  
  Help Codex understand how to execute the migration to support cross-OS
  paths.
  
  ## What
  
  Expand the path-types skill with our goals and constraints.

  Adam Perry @ OpenAI · 2026-06-16 21:05:32 +00:00
  33d50234a8
• Clarify model-generated and legacy app path types (#28577)

  ## Why
  
  `ApiPathString` kind of implies that it can be used anywhere we pull a
  path out of JSON, but it's not really appropriate for tool arguments
  when the model might generate relative paths.
  
  Prefer `String` for model-generated paths and we can handle the
  conversion per feature for now and define a shared abstraction later if
  it makes sense.
  
  # What
  
  Rename `ApiPathString` to `AppLegacyPathString` to clarify its role.
  
  Expand the `path-types` skill to tell the model to leave tool args as
  bare strings.

  Adam Perry @ OpenAI · 2026-06-16 20:47:43 +00:00
  322b83de5e
• [codex] test exec relative additional permissions (#28587)

  ## Why
  
  Review caught some would-be regressions in changes to unified_exec that
  weren't surfaced in CI.
  
  ## What
  
  Add coverage for requesting permissions through unified exec when there
  are additional permissions. Previously this flow was only tested against
  shell_command.

  Adam Perry @ OpenAI · 2026-06-16 20:45:57 +00:00
  a50671e748
• code-mode: extend test coverage to lock in cell lifecycle (#28468)

  This PR establishes the intended behavior as an executable contract
  before a refactor of the cell runtime begins. It also fixes cases where
  a second observer or termination request could replace an existing
  response channel and leave the original caller unresolved.
  
  ### Behavior codified
  - A cell can yield output and subsequently resume to completion.
  - A caller can run a cell until it has no immediately runnable work,
  receive its accumulated output and outstanding tool-call IDs, and then
  resume the same cell when the awaited work is available.
  - Each cell admits one active observer:
     - a second observer receives an explicit busy error
     - the existing observer remains registered and is not displaced
  - A natural result (conclusion of the js module) that has already
  reached the cell controller wins over a later termination request.
  - Otherwise, termination preempts execution and resolves both:
    - the active observer, if present
    - the caller requesting termination
  - Repeated termination requests are rejected while termination is
  already in progress.
  - Terminal responses are sent only after outstanding callback work has
  been handled:
  - natural completion drains notifications and cancels outstanding tool
  calls
  - termination cancels and drains both notification and tool callbacks.
  - Cell removal and cell_closed notification happen after callback
  cleanup

  Channing Conger · 2026-06-16 13:34:16 -07:00
  e93516e259
• [codex] re-enable absolute workdir integration test (#28581)

  ## Why
  
  In #28146 I missed the invariant that an absolute `exec_command` workdir
  must override the environment cwd. The existing integration test would
  have caught that regression, but it was ignored as flaky.
  
  ## What
  
  Re-enable `unified_exec_respects_workdir_override`.
  
  ## Validation
  
  `just test -p codex-core unified_exec_respects_workdir_override`

  Adam Perry @ OpenAI · 2026-06-16 20:19:41 +00:00
  4b7351700f
• [codex-app-server-test-client] Plugin Install/Uninstall Analytics Smoke Test (#27100)

  ## This PR
  
  The original [combined remote plugin analytics PR
  #26281](https://github.com/openai/codex/pull/26281) mixed reusable
  analytics test infrastructure, two manual smoke workflows, a metadata
  refactor, and the final identity behavior. This PR adds the
  account-mutating validation workflow separately so its cleanup and
  recovery guarantees can be reviewed without the final analytics behavior
  change.
  
  - Add a manually invoked remote plugin install/uninstall smoke workflow.
  - Require explicit account-mutation confirmation and an initially
  uninstalled plugin.
  - Validate the current `codex_plugin_installed` contract, where
  `plugin_id` is the backend ID.
  - Restore and verify the original uninstalled state, with a dedicated
  recovery command.
  
  This baseline intentionally does not require `codex_plugin_uninstalled`,
  because production does not emit that event yet. The final PR will
  update this smoke to require local `plugin_id`, `remote_plugin_id`, and
  uninstall emission. Review this PR as the net diff against #27099.
  
  ## Testing
  
  - `just test -p codex-app-server-test-client` (3 focused
  capture/validation tests passed)
  - The live workflow was previously exercised on the green combined
  reference branch, and the original uninstalled account state was
  restored.
  - CI is green across the required platform matrix.
  
  ## Split Overview
  
  ```text
  main
  ├── #27093  Debug analytics capture
  │   └── #27099  Non-mutating plugin smoke
  │       └── #27100  Remote install/uninstall smoke  ← you are here
  └── #27102  Plugin telemetry metadata refactor
  
  After #27093, #27099, #27100, and #27102 merge:
  └── Final PR: add remote_plugin_id to plugin analytics
  ```
  
  Review order and dependencies:
  
  1. [#27093 Add debug-only analytics event
  capture](https://github.com/openai/codex/pull/27093) (based on `main`)
  2. [#27099 Add a plugin analytics smoke
  workflow](https://github.com/openai/codex/pull/27099) (stacked on
  #27093)
  3. [#27100 Add a remote plugin analytics mutation smoke
  workflow](https://github.com/openai/codex/pull/27100) **(this PR,
  stacked on #27099)**
  4. [#27102 Centralize plugin telemetry metadata
  construction](https://github.com/openai/codex/pull/27102) (independent,
  based on `main`)
  5. Final remote-ID behavior PR (created after PRs 1-4 merge)
  
  The original [#26281](https://github.com/openai/codex/pull/26281)
  remains open as the green aggregate reference until the final PR is
  published.

  jameswt-oai · 2026-06-16 12:28:45 -07:00
  8a40200880
• [codex] Route MCP file uploads through environment filesystem (#27923)

  ## Why
  
  Codex Apps tools can mark arguments with `openai/fileParams`, but the
  execution path resolved and opened those files directly on the host.
  That bypassed the selected turn environment and prevented annotated file
  arguments from working with remote environments.
  
  ## What changed
  
  - resolve annotated file arguments against the primary turn environment
  - read file metadata and contents through that environment's sandboxed
  `ExecutorFileSystem`
  - reject files over the 512 MiB limit from metadata before reading or
  transferring them
  - retain the buffered upload-size check as defense in depth
  - make the OpenAI upload API accept a filename and buffered contents
  instead of owning local filesystem access
  - describe the model-visible argument as a path in the primary
  environment
  
  This builds on #27927, which added `size` to internal filesystem
  metadata.
  
  ## Testing
  
  - `just test -p codex-api upload_openai_file_returns_canonical_uri`
  - `just test -p codex-mcp
  tool_with_model_visible_input_schema_masks_file_params`
  - `just test -p codex-core mcp_openai_file`
  - `just test -p codex-core
  codex_apps_file_params_upload_environment_files_before_mcp_tool_call`

  pakrym-oai · 2026-06-16 11:27:46 -07:00
  7baf7e467e
• ci: run code-mode unit tests on all bazel targets (#28562)

  ## Why
  
  V8 should be stable under Bazel, so the `codex-code-mode` unit tests
  should run across the Bazel platform matrix. If these tests prove
  unstable, we should fix the tests rather than exclude them from CI.
  
  ## What changed
  
  - Remove the explicit `//codex-rs/code-mode:code-mode-unit-tests`
  exclusion from the macOS and Linux Bazel test jobs.
  - Remove the same exclusion from the native Windows post-merge job.
  - Keep the existing Windows gnullvm shard coverage.
  
  ## Bazel test coverage
  
  The target contains 26 unit tests. A fresh uncached local Bazel
  execution ran all 26 with 0 failures, 0 ignored tests, and 0 filtered
  tests.
  
  PR Bazel CI selected the target on every enabled platform and reported a
  cached pass:
  
  | Platform | Passing CI job |
  | --- | --- |
  | macOS aarch64 | [Bazel test
  passed](https://github.com/openai/codex/actions/runs/27636617545/job/81725447804)
  |
  | macOS x86_64 | [Bazel test passed in
  2.2s](https://github.com/openai/codex/actions/runs/27636617545/job/81725448008)
  |
  | Linux GNU | [Bazel test passed in
  0.4s](https://github.com/openai/codex/actions/runs/27636617545/job/81725447898)
  |
  | Linux musl | [Bazel test passed in
  0.4s](https://github.com/openai/codex/actions/runs/27636617545/job/81725448117)
  |
  | Windows gnullvm | [Bazel test passed in shard 4/4 in
  1.6s](https://github.com/openai/codex/actions/runs/27636617545/job/81725448166)
  |

  Channing Conger · 2026-06-16 11:26:33 -07:00
  009a2bb93d
• feat(tui): add rate-limit reset redemption to /usage (#28154)

  ## Why
  
  Codex users can earn personal rate-limit reset credits, but the CLI does
  not currently provide a way to view or redeem them. The `/usage` command
  restored in #27925 is intended to be the entry point for usage-related
  actions, so reset redemption belongs there rather than in a separate
  dashed slash command.
  
  Depends on #28143 for the app-server and backend-client reset-credit
  APIs.
  
  ## What changed
  
  - Turn bare `/usage` into a menu with entries for token activity and
  earned rate-limit resets while preserving `/usage daily`, `/usage
  weekly`, and `/usage cumulative`.
  - Add loading, empty, confirmation, success, retry, and error states
  with a caller-generated UUID idempotency key reused across retries of
  the same logical reset.
  - Show an availability hint only for backend-classified rate-limit
  errors with credits available.
  - Hide the reset entry for workspace accounts.
  
  ## Validation
  
  - `just test -p codex-tui chatwidget::tests::usage` — 19 passed.
  - `just fix -p codex-tui` — passed.
  - `just fmt` — passed.
  - `cargo insta pending-snapshots` from `codex-rs/tui` — no pending
  snapshots.
  
  ## Examples
  <img width="1168" height="304" alt="image"
  src="https://github.com/user-attachments/assets/caa4c1e3-e996-494d-ae17-50b521f5dce8"
  />
  <img width="908" height="260" alt="image"
  src="https://github.com/user-attachments/assets/e38a726b-77cc-4bd0-9ea8-9f3ad21c5768"
  />
  
  
  ### Reset flow
  <img width="1509" height="312" alt="image"
  src="https://github.com/user-attachments/assets/d987013c-78a5-48a2-ad8d-c61ad267a327"
  />
  <img width="585" height="190" alt="image"
  src="https://github.com/user-attachments/assets/de32be19-79b9-4a3e-8574-6f1c208c98ae"
  />
  <img width="600" height="210" alt="image"
  src="https://github.com/user-attachments/assets/88a165cf-796d-4fdc-a7bc-ea89917573da"
  />
  
  <img width="512" height="193" alt="image"
  src="https://github.com/user-attachments/assets/d2353998-5aa8-442e-a5f8-3a8a5b832753"
  />

  jay · 2026-06-16 17:59:40 +00:00
  f8f5a6e78f
• Add incremental thread history changes

  Add ThreadHistoryBuilder APIs for collecting incremental thread item and turn changes while applying rollout items.
  
  Batch handling coalesces repeated changes so callers can get the latest incremental thread item changes for a set of rollout items without rebuilding full history.

  Tom · 2026-06-16 10:56:29 -07:00
  1e6970542e
• [codex] Warn clearly when code mode output is truncated (#28467)

  ## Summary
  
  - make `formatted_truncate_text` prepend `Warning: truncated output
  (original token count: N)` above the existing `Total output lines`
  header
  - update direct formatter, unified-exec, user-shell, and code-mode
  expectations
  - add core unit coverage that runs in Bazel without requiring the
  skipped V8-backed code-mode integration suite
  
  ## Validation
  
  - `cargo test -p codex-utils-output-truncation -- --nocapture` (17
  passed)
  - `cargo test -p codex-core --lib
  truncated_text_output_starts_with_warning -- --nocapture`
  - `cargo test -p codex-core --test all
  clamps_model_requested_max_output_tokens_to_policy -- --nocapture` (2
  passed)
  - `cargo test -p codex-core --test all
  unified_exec_formats_large_output_summary -- --nocapture`
  - `cargo test -p codex-core --test all
  user_shell_command_output_is_truncated_in_history -- --nocapture`
  - Bazel CI exercises the shared formatter and downstream integration
  expectations

  Ahmed Ibrahim · 2026-06-16 10:37:06 -07:00
  952656356a
• fix(tui): highlight C++ module files (#28554)

  ## Why
  
  Codex syntax-highlights diffs for conventional C++ extensions such as
  `.cpp` and `.cxx`, but C++ module interface files using `.cppm`, `.ixx`,
  or `.cxxm` fall back to plain diff coloring. The bundled syntax set
  already includes C++, but it does not resolve those module extensions by
  itself.
  
  Closes #28223.
  
  ## What changed
  
  - map `.cppm`, `.ixx`, and `.cxxm` to the existing `cpp` syntax in
  `render/highlight.rs`
  - extend alias-resolution coverage for all three module extensions
  - verify `.cpp`, `.cppm`, `.ixx`, and `.cxxm` diffs produce
  syntax-highlighted RGB spans while unknown extensions retain the plain
  fallback
  - snapshot the syntax-colored token segmentation for the supported C++
  module extensions
  
  ## How to Test
  
  1. Ask Codex to create or modify a C++ module interface file using
  `.cppm`, `.ixx`, or `.cxxm`.
  2. Confirm C++ tokens in the rendered diff receive syntax colors instead
  of only the red/green diff treatment.
  3. Modify an equivalent `.cpp` file and confirm its existing
  highlighting remains unchanged.
  4. Modify a file with an unknown extension and confirm it still uses the
  plain diff fallback.
  
  Targeted tests:
  
  - `just test -p codex-tui -E
  'test(find_syntax_resolves_languages_and_aliases) |
  test(cpp_module_extensions_use_cpp_highlighting) |
  test(unknown_extension_falls_back_without_syntax_highlighting)'`

  Felipe Coury · 2026-06-16 17:33:13 +00:00
  3ded846488
• [codex-app-server-test-client & codex-app-server] Plugin Usage Analytics Smoke Test (#27099)

  ## This PR
  
  The original [combined remote plugin analytics PR
  #26281](https://github.com/openai/codex/pull/26281) mixed reusable
  analytics test infrastructure, two manual smoke workflows, a metadata
  refactor, and the final identity behavior. This PR establishes a
  non-mutating end-to-end plugin smoke workflow before any analytics
  identity semantics change.
  
  - Add `plugin-analytics-smoke` to the existing app-server test client.
  - Exercise plugin disable, enable, and use through production app-server
  RPC paths.
  - Isolate config writes in a temporary file and use a loopback Responses
  API server.
  - Capture analytics without sending them to the production analytics
  backend.
  - Validate the current local `plugin_id`, names, capability metadata,
  thread, turn, and model fields.
  
  This is intentionally a baseline smoke workflow. It does not assert
  `remote_plugin_id`; the final PR will update it when that field exists.
  Review this PR as the net diff against #27093.
  
  ## Testing
  
  - The test-client target compiles successfully.
  - The combined reference branch exercised the manual smoke against the
  live remote plugin service.
  - CI is green across the required platform matrix.
  
  ## Split Overview
  
  ```text
  main
  ├── #27093  Debug analytics capture
  │   └── #27099  Non-mutating plugin smoke           ← you are here
  │       └── #27100  Remote install/uninstall smoke
  └── #27102  Plugin telemetry metadata refactor
  
  After #27093, #27099, #27100, and #27102 merge:
  └── Final PR: add remote_plugin_id to plugin analytics
  ```
  
  Review order and dependencies:
  
  1. [#27093 Add debug-only analytics event
  capture](https://github.com/openai/codex/pull/27093) (based on `main`)
  2. [#27099 Add a plugin analytics smoke
  workflow](https://github.com/openai/codex/pull/27099) **(this PR,
  stacked on #27093)**
  3. [#27100 Add a remote plugin analytics mutation smoke
  workflow](https://github.com/openai/codex/pull/27100) (stacked on this
  PR)
  4. [#27102 Centralize plugin telemetry metadata
  construction](https://github.com/openai/codex/pull/27102) (independent,
  based on `main`)
  5. Final remote-ID behavior PR (created after PRs 1-4 merge)
  
  The original [#26281](https://github.com/openai/codex/pull/26281)
  remains open as the green aggregate reference until the final PR is
  published.

  jameswt-oai · 2026-06-16 10:11:41 -07:00
  a376781a3c
• chore: side prompt (#28553)

  Fix side bug with prompt

  jif · 2026-06-16 19:05:03 +02:00
  a544f5a612
• [codex] exec-server: stream files in chunks (#28354)

  ## Why
  
  `fs/readFile` buffers the entire file in one response, which makes large
  remote reads expensive and prevents callers from applying backpressure.
  We need an opt-in streaming path with bounded block sizes while
  preserving the existing single-call API for small and sandboxed reads.
  
  ## What changed
  
  - Add `ExecServerClient::stream`, returning a named `FileReadStream`
  that implements `futures::Stream` and yields immutable 1 MiB byte
  blocks.
  - Add internal `fs/open`, `fs/readBlock`, and `fs/close` RPCs.
  `fs/readBlock` accepts an explicit offset and length.
  - Keep unsandboxed files open between block reads, cap open handles per
  connection, and clean them up on EOF, error, stream drop, explicit
  close, or connection shutdown.
  - Reject platform-sandboxed streaming opens instead of turning the
  one-shot sandbox helper into a persistent server. Existing `fs/readFile`
  behavior is unchanged.
  
  ## Testing
  
  - `just test -p codex-exec-server`
  - Integration coverage for 1 MiB chunking, exact block-boundary EOF,
  sandbox rejection, and continued reads from the opened file after path
  replacement.
  - Handle-manager coverage for non-sequential offsets, variable block
  lengths, the 128-handle limit, and capacity release after close.

  pakrym-oai · 2026-06-16 09:50:55 -07:00
  a4711b88dd
• fix(tui): restore TUI after suspend (#28342)

  ## Why
  
  On Linux, suspending Codex with `Ctrl+Z` and returning with `fg` can
  leave the composer misaligned or inject terminal response bytes such as
  focus reports into the prompt. Shell job-control output moves the cursor
  while Codex is suspended, and terminal input polling can race with the
  responses used to restore the inline viewport.
  
  Fixes #26564.
  
  ## What changed
  
  - preserve and restore keyboard reporting without disturbing the parent
  terminal stack
  - pause terminal event polling while Codex is suspended and flush
  buffered input before resuming it
  - force crossterm's cached raw-mode state back in sync after the shell
  completes its `fg` handoff
  - probe the actual post-`fg` cursor position with the tolerant
  terminal-response parser, then realign the inline viewport before
  redrawing
  
  ## How to Test
  
  1. On Linux, start the development TUI with `just c`.
  2. Type text into the composer without submitting it.
  3. Press `Ctrl+Z`, run any harmless shell command, then run `fg`.
  4. Confirm the composer redraws below the shell output, the draft text
  is preserved, and no raw escape sequences appear.
  5. Repeat the suspend/resume cycle and confirm normal typing still
  works.
  
  Targeted tests:
  
  - `cargo test -p codex-tui --lib parses_cursor_position_as_zero_based -j
  1`
  - `cargo test -p codex-tui --lib tui::event_stream::tests -j 1`

  Felipe Coury · 2026-06-16 09:09:24 -07:00
  76135cbe7e
• path-uri: clarify invalid host path errors (#28473)

  ## Why
  
  Ensure a consistent string format when exposing path conversion errors
  to the model.
  
  ## What
  
  - Render `PathUriParseError::InvalidFileUriPath` as `'$PATH' is invalid
  on '$OS'`.

  Adam Perry @ OpenAI · 2026-06-16 09:03:44 -07:00
  7162030b37
• perf(config): defer remote sandbox hostname lookup (#28542)

  ## Why
  
  [#18763](https://github.com/openai/codex/pull/18763) added canonical
  hostname resolution for `remote_sandbox_config`. Requirements
  composition currently performs that synchronous DNS lookup on every
  fresh process, even when none of the loaded requirements layers contains
  `[[remote_sandbox_config]]`. On hosts with slow local DNS resolution,
  this can add several seconds to Codex startup.
  
  ## What
  
  - defer hostname resolution until a parsed requirements layer actually
  contains `remote_sandbox_config`
  - cache the resolver result once per requirements composition,
  preserving the existing single-lookup behavior across multiple layers
  - keep the existing FQDN resolution and per-layer requirements
  precedence unchanged
  - cover both the ordinary no-lookup path and the multi-layer
  single-lookup path
  
  ## How to Test
  
  On a host where local canonical-name resolution is slow:
  
  1. Start Codex without `[[remote_sandbox_config]]` in any managed
  requirements layer and confirm startup no longer waits for hostname
  resolution.
  2. Add a matching `[[remote_sandbox_config]]` entry and confirm its
  `allowed_sandbox_modes` still overrides the layer's top-level value.
  3. Add remote sandbox entries to multiple requirements layers and
  confirm precedence remains unchanged while the hostname is resolved only
  once.
  
  Targeted tests:
  
  - `just test -p codex-config hostname_resolver`
  - `just test -p codex-config` (181 passed)

  Felipe Coury · 2026-06-16 11:17:41 -04:00
  40e7dda4d2