434 Commits

• [codex] Add plugin list JSON output (#25330)

  ## Summary
  - add `--json` output to `codex plugin list` with `installed` and
  `available` arrays
  - add `--available` for JSON output only; using it without `--json` is
  rejected
  - keep the existing non-JSON table output unchanged
  - add CLI coverage for JSON installed/available output and the
  `--available`/`--json` requirement
  
  ## Validation
  - `just test -p codex-cli plugin_list`
  - `just fix -p codex-cli`
  - `git diff --check`
  
  Note: `just fmt` ran Rust formatting first, then failed in the Python
  ruff step because `openai-codex-cli-bin==0.132.0` has no wheel for this
  Linux platform.

  xl-openai · 2026-06-01 21:27:06 -07:00
  cb63ee7f5d
• Wire managed MITM CA trust into child env (#22668)

  ## Stack
  1. Parent PR: #18240 uses named MITM permissions config.
  2. This PR wires managed MITM CA trust into spawned child processes.
  
  ## Why
  When Codex terminates HTTPS for limited mode or MITM hooks, child HTTPS
  clients need to trust Codex's managed MITM CA. Exporting proxy URLs
  alone is not enough, but blindly replacing user CA settings would be
  wrong: it can break custom enterprise/test roots, leak unreadable CA
  files into generated bundles, or make the child env disagree with its
  sandbox policy.
  
  ## Summary
  1. Build immutable managed CA bundles under `$CODEX_HOME/proxy` that
  include native roots, the managed MITM CA, and only inherited or
  command-scoped CA bundles the child is allowed to read.
  2. Export curated CA env vars alongside managed proxy env vars while
  preserving user CA override semantics, including nested Codex
  `SSL_CERT_FILE` precedence.
  3. Thread generated CA bundle paths into child sandbox readable roots,
  including debug sandbox execution, so the exported env vars work inside
  sandboxed commands.
  4. Remove only Codex-generated MITM CA bundle env when a child
  intentionally drops managed proxying for escalation or no-proxy retry.
  5. Document the managed CA bundle behavior and cover env injection,
  per-child bundle generation, sandbox readable roots, and no-proxy
  cleanup in tests.
  
  ## Validation
  1. Ran `just test -p codex-network-proxy`.
  2. Ran `just test -p codex-protocol`.
  3. Ran `just fix -p codex-network-proxy -p codex-protocol`.
  4. Tried focused `codex-core` validation, but the crate currently fails
  to compile in `core/tests/suite/guardian_review.rs` because an existing
  `Op::UserInput` initializer is missing `additional_context`.
  
  ---------
  
  Co-authored-by: Eva Wong <evawong@openai.com>

  Winston Howes · 2026-06-01 23:23:59 +00:00
  bca18cba40
• Add reasoning-only status surface item (#25504)

  Closes #24886.
  
  ## Why
  Users can configure the TUI status line and terminal title with
  `model-with-reasoning`, but issue #24886 asks for a compact
  reasoning-only item. That lets a setup show just `default`, `low`,
  `medium`, `high`, or `xhigh` without repeating the model name.
  
  ## What changed
  - Added a `reasoning` item for `/statusline` and `/title` setup flows.
  - Rendered the item from the effective reasoning effort, including
  collaboration-mode overrides.
  - Registered `reasoning` with `codex doctor` so Codex-generated
  terminal-title config is not reported as invalid.
  - Updated TUI setup snapshots so the picker previews include the new
  item.

  Eric Traut · 2026-06-01 09:30:20 -07:00
  f1d029cf75
• Use deep links for macOS codex app paths (#25485)

  ## Why
  
  `codex app [PATH]` is the documented CLI entry point for opening Codex
  Desktop on a workspace. Recent desktop builds can focus the app while
  failing to honor paths passed as macOS document-open arguments via `open
  -a Codex.app <workspace>`, which broke `codex app .` for users. See
  #25333; related report: #25166.
  
  The desktop app still supports the explicit
  `codex://threads/new?path=...` route, so the CLI should use that
  app-owned launch surface instead of depending on folder-open event
  delivery.
  
  ## What Changed
  
  - Build a `codex://threads/new?path=<workspace>` URL in the macOS app
  launcher.
  - Pass that URL to `open -a <Codex.app>` instead of passing the
  workspace path as a document argument.
  - Add coverage that workspace paths needing escaping round-trip through
  URL query encoding.
  
  ## Verification
  
  - `just test -p codex-cli codex_new_thread_url_encodes_workspace_path`

  Eric Traut · 2026-06-01 09:17:08 -07:00
  f94c49cf46
• Add thread archive CLI commands (#25021)

  ## Problem
  
  Saved threads can already be archived through app-server RPCs, but the
  command line did not expose direct archive or unarchive commands.
  
  ## Solution
  
  Add `codex archive <thread>` and `codex unarchive <thread>`, resolving
  UUIDs or exact thread names before calling the existing `thread/archive`
  and `thread/unarchive` RPCs. The commands support scoped remote flags so
  callers can target remote app-server endpoints when archiving or
  unarchiving threads.
  
  This also fixes a long-standing bug in `codex resume <thread id>` and
  `codex fork <thread id>` that I found when testing the new commands.
  These operations shouldn't be allowed on archived sessions. They now
  fail with an error that tells the user to run `codex unarchive <thread
  id>` first.
  
  ## Verification
  
  Added app-server coverage for rejecting archived thread resume by id and
  checking that the error includes the matching `codex unarchive <thread
  id>` command.

  Eric Traut · 2026-05-29 23:37:26 -07:00
  3e7baa00e4
• Add Windows sandbox provisioning setup command (#24831)

  ## Why
  
  Some Windows users do not have local admin access, so they cannot
  complete the elevated portion of the Windows sandbox setup when Codex
  first needs it. This adds an alpha provisioning path that an admin or IT
  deployment script can run ahead of time for the Codex user.
  
  The intended managed-deployment shape is:
  
  ```powershell
  codex sandbox setup --elevated --user "$env:COMPUTERNAME\Alice" --codex-home "C:\Users\Alice\.codex"
  ```
  
  `--elevated` is treated as the requested sandbox setup level, not as
  proof that the process is elevated. The Windows sandbox setup
  orchestration still checks that the caller is actually elevated before
  launching the helper without a UAC prompt.
  
  ## What changed
  
  - Added `codex sandbox setup --elevated` with explicit user selection
  via either `--current-user` or `--user ... --codex-home ...`.
  - Moved the CLI implementation into `cli/src/sandbox_setup.rs` instead
  of growing `cli/src/main.rs`.
  - Added a Windows sandbox `ProvisionOnly` helper mode that runs the
  elevation-required provisioning work without requiring a workspace cwd
  or runtime sandbox policy.
  - Reused the existing elevated helper path for creating/updating sandbox
  users, configuring firewall/WFP rules, and applying sandbox directory
  ACLs.
  - Persisted `windows.sandbox = "elevated"` into the target `CODEX_HOME`
  so the desktop app does not show the initial sandbox setup banner after
  pre-provisioning succeeds.
  
  ## Validation
  
  - `cargo fmt -p codex-windows-sandbox -p codex-core -p codex-cli`
  - `cargo test -p codex-cli sandbox_setup --target-dir
  target\sandbox-setup-check`
  - `cargo test -p codex-windows-sandbox
  payload_accepts_provision_only_mode --target-dir
  target\sandbox-setup-check`
  - `git diff --check`
  - Manual Windows alpha flow with a standard local user (`Mandi Lavida`):
  ran the new setup command from an admin shell, verified the target
  `.codex` contents, sandbox marker/secrets, ACLs, firewall rules, and
  desktop startup without the sandbox setup banner once experimental
  network proxy requirements were disabled.
  
  ## Notes
  
  This intentionally does not solve later elevated update coordination for
  IT-managed deployments. The setup command can still apply provisioning
  updates when run again, but a broader coordination/process story is out
  of scope for this alpha.

  iceweasel-oai · 2026-05-29 11:01:44 -07:00
  cb9178e8b3
• windows-sandbox: pass workspace roots to runner (#24108)

  ## Why
  
  #23813 switches the Windows sandbox runner path to `PermissionProfile`,
  but it still left one runtime anchor for resolving symbolic
  `:workspace_roots` entries. That is not enough once a turn has multiple
  effective workspace roots: exact entries and deny globs under
  `:workspace_roots` need to be materialized for every runtime root before
  the command runner chooses token mode or builds ACL plans.
  
  ## What Changed
  
  - Replaces the Windows runner/setup `permission_profile_cwd` plumbing
  with `workspace_roots: Vec<AbsolutePathBuf>`.
  - Resolves Windows-local `PermissionProfile` data with
  `materialize_project_roots_with_workspace_roots(...)` instead of the
  single-cwd helper.
  - Threads `Config::effective_workspace_roots()` through core execution,
  unified exec, TUI setup/read-grant flows, app-server setup, app-server
  `command/exec`, and `debug sandbox` on Windows.
  - Preserves those workspace roots through the zsh-fork escalation
  executor instead of rebuilding them from `sandbox_policy_cwd`.
  - Makes `ExecRequest::new(...)` and the remaining
  `build_exec_request(...)` helper path take
  `windows_sandbox_workspace_roots` explicitly so new call sites cannot
  silently fall back to `vec![cwd]`.
  - Clarifies the `debug sandbox` non-Windows comment: remaining
  cwd-dependent resolution still uses `sandbox_policy_cwd`, while
  `:workspace_roots` entries are already materialized from config roots.
  - Updates elevated runner IPC `SpawnRequest` to send `workspace_roots`
  and bumps the framed IPC protocol version to `3` for the payload shape
  change.
  - Adds Windows-local resolver coverage for expanding exact and glob
  `:workspace_roots` entries across multiple roots, plus core helper
  coverage proving explicit roots are preserved.
  
  ## Verification
  
  - `cargo check -p codex-windows-sandbox -p codex-core -p codex-tui -p
  codex-cli -p codex-app-server`
  - `cargo test -p codex-windows-sandbox`
  - `cargo test -p codex-core windows_sandbox`
  - `cargo test -p codex-core unix_escalation`
  - `cargo test -p codex-app-server windows_sandbox`
  - `cargo test -p codex-tui windows_sandbox`
  - `cargo test -p codex-cli debug_sandbox`
  - `just test -p codex-core unified_exec`
  - `just test -p codex-core
  build_exec_request_preserves_windows_workspace_roots`
  - `env -u CODEX_NETWORK_PROXY_ACTIVE -u
  CODEX_NETWORK_ALLOW_LOCAL_BINDING just test -p codex-app-server --lib
  command_exec`
  - `just test -p codex-windows-sandbox`
  - `just test -p codex-exec sandbox`
  - `just fix -p codex-core -p codex-app-server -p codex-windows-sandbox`
  
  A local macOS cross-check with `cargo check --target
  x86_64-pc-windows-msvc ...` did not reach crate Rust code because native
  dependencies require Windows SDK headers (`windows.h` / `assert.h`) in
  this environment; Windows CI remains the real target validation.
  
  Two local targeted filters compile but do not run assertions on macOS:
  `env -u CODEX_NETWORK_PROXY_ACTIVE -u CODEX_NETWORK_ALLOW_LOCAL_BINDING
  just test -p codex-app-server --lib command_exec_processor` matched zero
  tests, and `just test -p codex-linux-sandbox landlock` matched zero
  tests because the landlock suite is Linux-only.

  Michael Bolin · 2026-05-28 15:26:55 -07:00
  986c60467b
• Add codex app-server --stdio alias (#24940)

  ## Summary
  - Add `--stdio` as a direct alias for `codex app-server --listen
  stdio://`.
  - Keep `--stdio` and `--listen` mutually exclusive.
  - Update the app-server README to document both forms.

  Adam Perry @ OpenAI · 2026-05-28 12:43:30 -07:00
  b90ec46387
• Allow API-key auth for remote exec-server registration (#24666)

  ## Overview
  Allow remote `codex exec-server` registration to use existing API-key
  auth while restricting where those credentials can be sent.
  
  - Accept `CodexAuth::ApiKey` for the normal `--remote` registration
  path.
  - Restrict API-key remote registration to HTTPS `openai.com` and
  `openai.org` hosts and subdomains, with explicit HTTP loopback support
  for local development.
  - Disable registry registration redirects so credentials cannot be
  forwarded to an unvalidated destination.
  - Retain `--use-agent-identity-auth` as the explicit Agent Identity
  path.
  - Document remote registration using `CODEX_API_KEY`.
  
  ## Big picture
  Callers can now provide an API key directly to `exec-server`
  registration without first establishing ChatGPT login state:
  
  ```sh
  CODEX_API_KEY="$OPENAI_API_KEY" \
  codex exec-server \
    --remote "https://<host>.openai.org/api" \
    --environment-id "$ENVIRONMENT_ID"
  ```
  
  ## Validation
  - `cargo fmt --all` (`just fmt` is not installed on this host)
  - `cargo test -p codex-cli -p codex-exec-server`

  Steve Coffey · 2026-05-27 21:17:38 +00:00
  c57dee98b7
• Uprev Rust toolchain pins to 1.95.0 (#24684)

  ## Summary
  - Bump the workspace Rust toolchain from `1.93.0` to `1.95.0` across
  Cargo, Bazel, CI, release workflows, devcontainers, and the Codex
  environment config.
  - Refresh `MODULE.bazel.lock` so the Bazel Rust toolchain artifacts
  match the new version.
  - Leave purpose-specific toolchains unchanged, including the
  `argument-comment-lint` nightly and the upstream `rusty_v8` `1.91.0`
  build pin.
  - Includes fixes for new lints from `just fix` and a few codex-authored
  fixes for lints without a suggestion.

  Adam Perry @ OpenAI · 2026-05-26 20:59:47 -07:00
  cca1e0ba1d
• windows-sandbox: remove SandboxPolicy runner plumbing (#23813)

  ## Why
  
  The Windows sandbox runner still carried the old `SandboxPolicy`
  compatibility path even though core now computes `PermissionProfile`.
  That meant Windows command-runner execution could only see the legacy
  projection, so profile-only filesystem rules such as deny globs were not
  part of the runner input.
  
  ## What Changed
  
  - Removed the Windows-local `SandboxPolicy` parser/export and deleted
  `windows-sandbox-rs/src/policy.rs`.
  - Changed restricted-token capture/session setup, elevated setup,
  world-writable audit, read-root grant, and command-runner session APIs
  to accept `PermissionProfile` plus the profile cwd.
  - Bumped the elevated command-runner IPC protocol to version 2 because
  `SpawnRequest` now carries `permission_profile` /
  `permission_profile_cwd` instead of the legacy `policy_json_or_preset` /
  `sandbox_policy_cwd` fields.
  - Updated core exec, unified exec, debug-sandbox, TUI setup/grant flows,
  and app-server setup to pass the actual effective `PermissionProfile`.
  - Left regression coverage asserting the old IPC policy fields are
  absent and the runner serializes tagged `PermissionProfile` JSON.
  
  ## Verification
  
  - `cargo test -p codex-windows-sandbox`
  - `cargo test -p codex-core windows_sandbox`
  - `cargo test -p codex-app-server
  request_processors::windows_sandbox_processor`
  - `just fix -p codex-windows-sandbox -p codex-core -p codex-app-server
  -p codex-cli -p codex-tui`
  - `just fix -p codex-cli -p codex-tui`
  - `just fix -p codex-windows-sandbox -p codex-tui`
  - `rg "\\bSandboxPolicy\\b" codex-rs/windows-sandbox-rs` returned no
  matches.
  
  Note: `cargo test -p codex-cli` was attempted but did not reach crate
  tests because local disk filled while compiling dependencies (`No space
  left on device`). The targeted clippy pass compiled the affected CLI/TUI
  surfaces afterward.
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23813).
  * #24108
  * __->__ #23813

  Michael Bolin · 2026-05-26 14:56:27 -07:00
  0a6bc4e687
• Move memory state to a dedicated SQLite DB (#24591)

  ## Summary
  
  Generated memory rows and their stage-one/stage-two job state currently
  live in `state_5.sqlite` alongside thread metadata. That makes memory
  cleanup and regeneration share the main state schema even though those
  rows are memory-pipeline data and can be rebuilt independently from the
  durable thread records.
  
  This PR moves the memory-owned tables into a dedicated
  `memories_1.sqlite` runtime database while keeping thread metadata in
  `state_5.sqlite`.
  
  ## Changes
  
  - Adds a separate memories DB runtime, migrator, path helpers, telemetry
  kind, and Bazel compile data for `state/memory_migrations`.
  - Introduces `MemoryStore` behind `StateRuntime::memories()` and moves
  memory table/job operations onto that store.
  - Drops the old memory tables from the state DB and recreates their
  schema in `state/memory_migrations/0001_memories.sql`.
  - Updates memory startup, citation usage tracking, rollout pollution
  handling, `debug clear-memories`, and app-server `memory/reset` to
  operate through the memories DB.
  - Preserves cross-DB behavior by hydrating thread metadata from the
  state DB when selecting visible memory outputs and checking stage-one
  staleness.
  
  ## Verification
  
  - Added/updated `codex-state` tests for deleted-thread memory visibility
  and already-polluted phase-two enqueue behavior.
  - Updated `debug clear-memories`, app-server `memory/reset`, and
  memories startup tests to seed and assert memory rows through
  `memories_1.sqlite`.

  jif-oai · 2026-05-26 20:07:25 +02:00
  aad59a0916
• Add doctor thread inventory audit (#24305)

  ## Why
  
  Users have been reporting missing sessions in the app. The app server
  thread listing is backed by the SQLite state DB, but the durable source
  of truth for a thread still exists on disk as rollout JSONL. When the
  state DB is incomplete, doctor should be able to show the mismatch
  directly instead of leaving users with a generic state health result.
  
  ## What changed
  
  This adds a `threads` doctor check that compares active and archived
  rollout files under `CODEX_HOME` with rows in the SQLite `threads`
  table. The check reports missing rollout rows, stale DB rows, archive
  flag mismatches, duplicate rollout thread IDs, duplicate DB paths,
  source/provider summaries, and bounded samples of affected rollout
  paths.
  
  It also adds a read-only state audit helper in `codex-rs/state` so
  doctor can inspect thread rows without creating, migrating, or repairing
  the database.
  
  ## Sample output
  
  ```text
    ⚠ threads      rollout files are missing from the state DB
        default model provider   openai
        rollout DB active files  3910
        rollout DB archived files 2037
        rollout DB scan errors   0
        rollout DB malformed file names 0
        rollout DB scan cap reached false
        rollout DB rows          5499
        rollout DB active rows   3462
        rollout DB archived rows 2037
        rollout DB missing active rows 448
        rollout DB missing archived rows 0
        rollout DB stale rows    0
        rollout DB archive mismatches 0
        rollout DB duplicate rollout thread ids 0
        rollout DB duplicate DB paths 0
        rollout DB model providers openai=5359, lmstudio=35, mock_provider=33, lite_llm=26, proxy=26, ollama=15, lms=4, local-usage-limit=1
        rollout DB sources       vscode=2587, cli=1494, subagent:thread_spawn=577, subagent:other=502, exec=281, subagent:memory_consolidation=46, subagent:review=9, unknown=3
        rollout DB missing active sample ~/.codex/sessions/2026/0…857e-a923c712e066.jsonl
        rollout DB missing active sample ~/.codex/sessions/2025/0…877a-766dff25c68d.jsonl
        rollout DB missing active sample ~/.codex/sessions/2025/0…a8b1-7bbadc836f6e.jsonl
        rollout DB missing active sample ~/.codex/sessions/2025/0…a218-e6197f3f62f8.jsonl
        rollout DB missing active sample ~/.codex/sessions/2025/0…9011-7e30784f9932.jsonl
  ```

  Eric Traut · 2026-05-25 10:29:06 -07:00
  a7836744cc
• Report app-server version in codex doctor (#24311)

  ## Why
  
  We are seeing cases where users have an old background app-server still
  running. `codex doctor` already reports background server state, but
  without the running app-server version it is harder to diagnose
  behaviors that depend on the daemon build.
  
  ## What changed
  
  - Reused the app-server daemon's passive initialize probe through a
  narrow `probe_app_server_version` helper.
  - Updated the `codex doctor` Background Server section to report
  `app-server version: <version>` when the socket is reachable.
  - Preserved the not-running OK behavior and report `app-server version:
  unavailable (<short error>)` when a socket exists but the passive probe
  fails.

  Eric Traut · 2026-05-25 09:41:12 -07:00
  6491d1207f
• feat(doctor): add environment diagnostics (#24261)

  ## Why
  
  Issue #23031 was hard to diagnose from existing `codex doctor` output
  because support could not see the OS language, resolved Git install, Git
  repo metadata, Windows console mode/code page, or terminal-title inputs
  that affect the TUI startup path. This adds those read-only signals to
  `codex doctor` so Windows, Linux, and macOS reports carry the context
  needed to investigate similar terminal rendering regressions.
  
  Refs #23031
  
  ## What Changed
  
  - Add a `system.environment` check for OS type/version, OS language, and
  locale env vars.
  - Add a `git.environment` check for the selected Git executable, PATH
  Git candidates, version, exec path/build options, repository root,
  branch, `.git` entry, and `core.fsmonitor`.
  - Add Windows console code page and VT-processing mode details to
  terminal diagnostics.
  - Add a `terminal.title` check for configured/default title items and
  resolved project-title source/value.
  - Surface startup warning counts in config diagnostics and teach human
  output to render the new categories.
  
  ## How to Test
  
  1. On Windows, check out this branch and run `cargo run -p codex-cli --
  doctor --summary`.
  2. Confirm the Environment section includes `system`, `git`, `terminal`,
  and `title` rows.
  3. Run `cargo run -p codex-cli -- doctor --json`.
  4. Confirm the JSON contains `system.environment`, `git.environment`,
  and `terminal.title`; on Windows, confirm `terminal.env` details include
  console code pages and `VT processing` for stdout/stderr.
  5. From a non-git directory, run the same `doctor --json` command and
  confirm the Git check reports `repo detected: false` rather than
  warning.
  
  Targeted tests:
  
  - `cargo test -p codex-cli doctor`
  - `cargo test -p codex-cli`

  Felipe Coury · 2026-05-24 15:34:35 +00:00
  9f42c89c01
• Support OAuth options in codex mcp add (#24120)

  ## Summary
  - add `--oauth-client-id` and `--oauth-resource` options for streamable
  HTTP `codex mcp add` registrations
  - persist those options in MCP server config and use them during the
  immediate OAuth login flow
  - cover add-time serialization of both OAuth options in the CLI
  integration tests
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-cli`
  - `just fix -p codex-cli`

  Matthew Zeng · 2026-05-22 13:21:01 -07:00
  6963145cb6
• cli: support --profile for codex sandbox (#24110)

  ## Why
  
  `codex sandbox` now always runs the host sandbox backend, so it should
  accept the same profile selection mechanism as the rest of the runtime
  CLI surface. Without `--profile`, sandbox debugging can exercise only
  the default config stack unless users manually translate profile config
  into ad hoc `-c` overrides.
  
  Supporting `--profile` lets sandbox invocations load
  `$CODEX_HOME/<name>.config.toml`, including permission profile
  configuration, before resolving the sandbox policy for the command being
  run.
  
  ## What Changed
  
  - Added `--profile NAME` / `-p NAME` to the host-specific `codex
  sandbox` argument structs as `config_profile`.
  - Allowed root-level `codex --profile NAME sandbox ...` and made a
  sandbox-local `codex sandbox --profile NAME ...` override the root
  selection.
  - Threaded `LoaderOverrides` through sandbox config loading so selected
  config profile files participate in permission resolution before the
  legacy read-only fallback.
  - Documented the new sandbox flag in `codex-rs/README.md`.
  
  ## Verification
  
  - Added parser coverage for `codex sandbox --profile`.
  - Added sandbox config-loader coverage that verifies selected config
  profile loader overrides select the profile config rather than falling
  back to read-only.
  - Ran `cargo test -p codex-cli`.

  Michael Bolin · 2026-05-22 13:00:53 -07:00
  36a71a88bf
• cli: infer host sandbox backend (#24102)

  ## Why
  
  `codex sandbox` previously required an OS subcommand like `linux`,
  `macos`, or `windows`, even though the command can only run the sandbox
  backend available on the current host. That made the CLI imply a
  cross-OS choice that does not exist.
  
  ## What changed
  
  - Collapse `codex sandbox <os>` into `codex sandbox [COMMAND]...` by
  wiring the `sandbox` parser directly to the host-specific backend args
  with `cfg`.
  - Keep the existing backend runners for Seatbelt, Linux sandbox, and
  Windows restricted token.
  - Rename the public Windows debug sandbox runner to
  `run_command_under_windows_sandbox` for clarity.
  - Update the Rust sandbox docs and related README references to describe
  host OS selection and avoid pointing readers at legacy `sandbox_mode`
  config.
  
  ## Arg0 compatibility
  
  The `codex-linux-sandbox` helper path is still handled before normal CLI
  parsing. `arg0_dispatch()` checks whether the executable basename is
  `codex-linux-sandbox` and directly calls
  `codex_linux_sandbox::run_main()`, so removing the `sandbox linux`
  parser branch does not affect the arg0 helper flow.
  
  ## Verification
  
  - `cargo test -p codex-cli`
  - `cargo test -p codex-arg0`
  - `just fix -p codex-cli`

  Michael Bolin · 2026-05-22 10:23:59 -07:00
  c0b16cfc6b
• config: remove legacy profile v1 resolution (#24051)

  ## Why
  
  [#23883](https://github.com/openai/codex/pull/23883) moved user-facing
  `--profile` selection onto profile v2, and
  [#23886](https://github.com/openai/codex/pull/23886) removed the old CLI
  `config_profile` override path. Core still had a second legacy path:
  `profile = "..."` could select `[profiles.*]` values while runtime
  config was built. Keeping that resolver alive preserves the old
  precedence model and profile-carrying surfaces even though profile
  selection now points at `$CODEX_HOME/<name>.config.toml`.
  
  ## What
  
  - Reject legacy top-level `profile = "..."` config while loading runtime
  config, with an error that points callers at `--profile <name>` and
  `<name>.config.toml` in the [core load
  path](https://github.com/openai/codex/blob/3d923366eca10a29143623124c6c6e538f058269/codex-rs/core/src/config/mod.rs#L2524-L2531).
  - Remove the remaining profile-v1 merge points from runtime config
  resolution, including features, permissions, model/provider selection,
  web search, Windows sandbox settings, TUI settings, role reloads, and
  OSS provider lookup.
  - Drop the leftover profile override surface from
  [`ConfigOverrides`](https://github.com/openai/codex/blob/3d923366eca10a29143623124c6c6e538f058269/codex-rs/core/src/config/mod.rs#L2118-L2148)
  and from the MCP server `codex` tool schema.
  - Prune profile-precedence tests that only exercised the removed
  resolver and replace them with rejection coverage for the legacy
  selector.
  
  ## Testing
  
  - Not run in this metadata pass.
  - Added
  [`legacy_profile_selection_is_rejected`](https://github.com/openai/codex/blob/3d923366eca10a29143623124c6c6e538f058269/codex-rs/core/src/config/config_tests.rs#L7942-L7965)
  coverage for the new runtime guard.

  jif-oai · 2026-05-22 12:13:52 +02:00
  fd72e99384
• mcp: surface profile migration guidance under --profile (#23890)

  ## Why
  
  `codex --profile <name> mcp ...` should reach the same profile-v2
  migration guard as runtime commands. Otherwise legacy
  `[profiles.<name>]` users see the generic command-scope rejection
  instead of the existing guidance to move settings into
  `$CODEX_HOME/<name>.config.toml`.
  
  ## What
  
  - Allow `codex mcp` through the `--profile` subcommand gate.
  - Pass profile loader overrides into the MCP entry point only to
  validate profile-v2 migration when a profile is present.
  - Keep MCP add/remove/list/get/login/logout behavior otherwise
  unchanged; this does not add profile-scoped MCP server management.
  - Cover the legacy profile migration error for `codex --profile work mcp
  list`.
  
  ## Testing
  
  - `cargo test -p codex-cli`

  jif-oai · 2026-05-22 10:40:33 +02:00
  ed80e5f558
• cli: remove legacy profile v1 plumbing (#23886)

  ## Why
  
  [#23883](https://github.com/openai/codex/pull/23883) moved the
  user-facing `--profile` flag onto profile v2. The shared CLI option
  layer still carried the old `config_profile` slot and several CLI
  entrypoints still copied that value into legacy config overrides.
  Leaving that path around makes the CLI surface look like it still
  selects legacy `[profiles.*]` state even though `--profile` now means
  `$CODEX_HOME/<name>.config.toml`.
  
  ## What
  
  - Remove the legacy `config_profile` field and merge/copy path from
  [`SharedCliOptions`](https://github.com/openai/codex/blob/95baaf72920c8db22097df8d15a0bb76c84528b6/codex-rs/utils/cli/src/shared_options.rs#L8-L177).
  - Stop forwarding profile-v1 overrides from CLI, exec, TUI, doctor,
  debug, feature, and exec-server paths; runtime profile selection remains
  on `config_profile_v2` through
  [`loader_overrides_for_profile`](https://github.com/openai/codex/blob/95baaf72920c8db22097df8d15a0bb76c84528b6/codex-rs/cli/src/main.rs#L1606-L1619).
  - Resolve local OSS provider selection from the base config in exec and
  TUI now that the legacy profile argument is gone.
  
  ## Testing
  
  - Not run (cleanup-only follow-up to #23883).

  jif-oai · 2026-05-21 17:21:37 +02:00
  e0e304b123
• Route MCP servers through explicit environments (#23583)

  ## Summary
  - route each configured MCP server through an explicit per-server
  `environment_id` instead of a manager-wide remote toggle
  - default omitted `environment_id` to `local`, resolve named ids through
  `EnvironmentManager`, and fail only the affected MCP server when an
  explicit id is unknown
  - keep local stdio on the existing local launcher path for now, while
  named-environment stdio uses the selected environment backend and
  requires an absolute `cwd`
  - allow local HTTP MCP servers to keep using the ambient HTTP client
  when no local `Environment` is configured; named-environment HTTP MCPs
  use that environment's HTTP client
  
  ## Validation
  - devbox Bazel build: `bazel build --bes_backend= --bes_results_url=
  //codex-rs/cli:codex //codex-rs/rmcp-client:test_stdio_server
  //codex-rs/rmcp-client:test_streamable_http_server`
  - devbox app-server config matrix with real `config.toml` /
  `environments.toml` files covering omitted local, explicit local,
  omitted local under remote default, explicit remote stdio, local HTTP
  without local env, explicit remote HTTP, local stdio without local env,
  unknown explicit env, and remote stdio without `cwd`

  starr-openai · 2026-05-21 17:19:54 +02:00
  298e5cfce1
• cli: rename profile v2 flag to --profile (#23883)

  ## Why
  
  Profile v2 is taking over the user-facing profile selection path, so the
  CLI no longer needs to expose the transitional `--profile-v2` spelling.
  This switches the public args surface to `--profile` before the
  remaining legacy profile plumbing is removed separately.
  
  ## What
  
  - Rebind `--profile` and `-p` to the v2 profile name argument that
  selects `$CODEX_HOME/<name>.config.toml`.
  - Stop parsing the legacy shared CLI profile argument while keeping its
  implementation path in place for follow-up cleanup.
  - Update CLI validation, profile-name parse errors, and the
  legacy-profile collision message/tests to refer to `--profile`.
  
  ## Testing
  
  - `cargo test -p codex-cli -p codex-config -p codex-protocol -p
  codex-utils-cli`

  jif-oai · 2026-05-21 16:45:27 +02:00
  8a511d5881
• [codex] List marketplaces considered by plugin discovery

  Co-authored-by: Codex <noreply@openai.com>

  Casey Chow · 2026-05-20 19:17:46 -04:00
  60b45d92d9
• feat(plugins): tabulate plugin list output (#23727)

  ## Summary
  - render `codex plugin list` as one table per marketplace with the
  marketplace manifest path shown above each table
  - surface the installed plugin version in the CLI output by threading
  `installed_version` through marketplace listing state
  - narrow the system-root exemption so only known bundled/runtime
  marketplaces skip missing-manifest failures, and keep `VERSION` empty
  for cached-but-unconfigured plugins
  
  ## Rationale
  The plugin list UX was hard to scan as a flat list and did not show
  which installed version was active. This change makes the CLI output
  easier to read in the real multi-marketplace case, keeps the plugin path
  visible, fixes the Sapphire regression where bundled/runtime marketplace
  roots were blocking `plugin list`, and addresses the two review findings
  that came out of the follow-up deep review.
  
  ## Key Decisions
  - kept the CLI output grouped per marketplace instead of one global
  table so the marketplace path can live with the rows it owns
  - kept `VERSION` as the installed version, which means it is empty until
  a plugin is actually installed
  - handled the bundled/runtime regression in the CLI snapshot validation
  path rather than widening app-server protocol or changing marketplace
  loading behavior
  - narrowed the exemption to known system marketplace names plus expected
  system paths, so user-configured marketplaces under those directories
  still fail loudly
  - gated `installed_version` on actual installed state so `VERSION`
  cannot show stale cache state for `not installed` rows
  
  ## Validation
  - `just fmt`
  - Sapphire: `cargo test -p codex-cli --test plugin_cli` (`14 passed; 0
  failed`)
  - Sapphire smoke test: bundled/runtime roots still work
    - `cargo run -q -p codex-cli -- plugin add sample@debug`
    - `cargo run -q -p codex-cli -- plugin list`
  - verified the bundled/runtime-root scenario no longer errors and shows
  the expected marketplace table output
  - Sapphire smoke test: custom marketplace under bundled path still
  errors
  - verified `failed to load configured marketplace snapshot(s)` for
  `custom-marketplace`
  - Sapphire smoke test: cached-but-unconfigured plugin hides version
  - verified `sample@debug not installed` renders with an empty `VERSION`
  column
  
  ## Sample Output
  ```text
  /tmp/custom-marketplace/plugin.json
  NAME          VERSION  STATUS         DESCRIPTION
  sample@debug  1.0.0    enabled        Debug sample plugin
  other@local            not installed  Local development plugin
  ```

  Casey Chow · 2026-05-20 18:04:49 -04:00
  3075061bdd
• cli: add strict config to exec-server (#23719)

  ## Why
  
  PR #20559 added opt-in strict config parsing to the config-loading
  command surfaces, but `codex exec-server` was left out. That meant
  `codex exec-server --strict-config` was rejected even though the command
  can load config for remote registration, and local server startup had no
  way to fail fast on misspelled config keys.
  
  ## What Changed
  
  - Added `--strict-config` to `codex exec-server`.
  - Allowed root-level inheritance from `codex --strict-config
  exec-server`.
  - Validated config before local exec-server startup when strict mode is
  requested.
  - Reused the loaded strict-config-aware config for remote exec-server
  registration auth.
  - Added CLI coverage showing `codex exec-server --strict-config` rejects
  unknown config fields.
  
  ## Verification
  
  - `cargo test -p codex-cli`
  - New integration test:
  `strict_config_rejects_unknown_config_fields_for_exec_server`
  
  ## Documentation
  
  Any strict-config command list on developers.openai.com/codex should
  include `codex exec-server` with the other supported config-loading
  entry points.

  Michael Bolin · 2026-05-20 13:12:31 -07:00
  d1e3d54192
• Migrate exec-server remote registration to environments (#23633)

  ## Summary
  - migrate exec-server remote registration naming from executor to
  environment
  - align CLI, public Rust exports, registry error messages, and relay
  test fixtures with the environment registry contract
  - keep the live registration path and response model consistent with
  `/cloud/environment/{environment_id}/register`
  
  ## Verification
  - `cargo test -p codex-exec-server
  remote::tests::register_environment_posts_with_auth_provider_headers
  --manifest-path /Users/richardlee/code/codex/codex-rs/Cargo.toml`
  - `cargo test -p codex-exec-server --test relay
  multiplexed_remote_environment_routes_independent_virtual_streams
  --manifest-path /Users/richardlee/code/codex/codex-rs/Cargo.toml`
  - `cargo check -p codex-cli --manifest-path
  /Users/richardlee/code/codex/codex-rs/Cargo.toml` (still running when PR
  opened; will update after completion if needed)

  richardopenai · 2026-05-20 00:25:04 -07:00
  000bf5ce6d
• runtime: detect Codex package layout (#23596)

  ## Why
  
  The package-builder stack now creates a canonical Codex package
  directory where the entrypoint lives under `bin/`, bundled helper
  resources live under `codex-resources/`, and bundled PATH-style tools
  live under `codex-path/`. That layout is not specific to the standalone
  installer: npm, brew, install scripts, and manually unpacked artifacts
  should all be able to use the same package shape.
  
  The Rust runtime still only knew about the legacy standalone release
  layout, where resources sit next to the executable. A packaged binary
  therefore would not identify its package root or prefer the bundled `rg`
  from `codex-path/`.
  
  ## What changed
  
  - Adds `CodexPackageLayout` to `codex-install-context` and detects it
  from an executable path shaped like `<package>/bin/<entrypoint>` when
  `<package>/codex-package.json` is present.
  - Splits `InstallContext` into an install `method` plus an optional
  package layout so the layout is shared across npm, bun, brew,
  standalone, and other launch contexts.
  - Stores package-layout paths as `AbsolutePathBuf` values.
  - Keeps `codex-resources/` and `codex-path/` optional so Codex can still
  run with degraded behavior if sidecar directories are missing.
  - Updates `InstallContext::rg_command()` to prefer bundled
  `codex-path/rg` or `rg.exe`, then fall back to the legacy standalone
  resources location, then system `rg`.
  - Updates `codex doctor` reporting so package installs show package,
  bin, resources, and path directories, and so bundled search detection
  recognizes `codex-path/` for any install method.
  
  ## Test plan
  
  - `cargo test -p codex-install-context`
  - `cargo test -p codex-cli`
  - `cargo test -p codex-tui
  update_action::tests::maps_install_context_to_update_action`
  - `just bazel-lock-check`

  Michael Bolin · 2026-05-19 23:13:49 -07:00
  cfa16fcc2e
• feat: dedicated goal DB (#23300)

  ## Why
  
  Thread goals are moving toward extension-owned runtime behavior, but
  their persisted state was still stored in the shared state database.
  This makes the goal store harder to isolate and keeps future storage
  splits tied to ad hoc runtime plumbing.
  
  This PR gives goals their own SQLite database while keeping the existing
  `StateRuntime` entry point. The goal is to make this the pattern for
  adding more dedicated runtime databases later.
  
  This also reduce load on existing DB and reduce contention
  
  ## Limitation
  Thread preview from goal is not supported anymore. I'm looking into this
  [EDIT]: solved
  
  ## What changed
  
  - Added a dedicated `goals_1.sqlite` database with its own
  `goals_migrations` directory.
  - Moved `thread_goals` creation into the goals DB migration set.
  - Dropped the old `thread_goals` table from the main state DB with a
  normal state migration. There is intentionally no backfill for existing
  goal rows.
  - Changed `GoalStore` to be backed only by the goals DB pool.
  - Removed the old goal-write side effect that filled empty
  `threads.preview` values from the goal objective.
  - Added shared runtime DB path metadata so startup, telemetry, `codex
  doctor`, and repair handling can include future DBs without bespoke path
  lists.
  - Updated Bazel compile data so the new goals migration directory is
  available to `sqlx::migrate!`.
  
  ## Verification
  
  - `cargo check --tests -p codex-state -p codex-cli -p codex-core -p
  codex-app-server`
  - `just fix -p codex-state`
  - `just fix -p codex-cli`
  - `just fix -p codex-app-server`

  jif-oai · 2026-05-19 11:11:41 +02:00
  ba57aab13a
• Improve codex remote-control CLI UX (#22878)

  ## Description
  
  This PR makes `codex remote-control` behave like a foreground CLI
  command by default. Running it now starts remote control, waits for
  readiness, prints a clear status message with the machine name, and
  stays alive until Ctrl-C.
  
  Users who want daemon behavior can use `codex remote-control start`, and
  `codex remote-control stop` now prints concise human-readable output.
  `--json` remains available for scripts.
  
  Implementation-wise, this now verifies the real app-server state instead
  of just assuming startup worked. The CLI starts or connects to
  app-server, probes its control socket, calls the `remoteControl/enable`
  API, and waits for the remote-control status response/notification
  before printing success.
  
  For daemon mode, `codex remote-control start` also reports which managed
  app-server binary was used, including its path and best-effort `codex
  --version`, so failures are easier to diagnose.
  
  ## Examples
  
  Example output:
  ```
  > codex remote-control
  Starting app-server with remote control enabled...
  This machine is available for remote control as com-97826.
  Press Ctrl-C to stop.
  ```
  
  Error case using daemon (currently expected based on our publicly
  released CLI version):
  ```
  > ./target/debug/codex remote-control start
  Starting app-server daemon with remote control enabled...
  Error: app server did not become ready on /Users/owen/.codex/app-server-control/app-server-control.sock
  
  Daemon used app-server:
    path: /Users/owen/.codex/packages/standalone/current/codex
    version: 0.130.0
  
  Managed app-server stderr (/Users/owen/.codex/app-server-daemon/app-server.stderr.log):
    error: unexpected argument '--remote-control' found
    
    Usage: codex app-server [OPTIONS] [COMMAND]
    
    For more information, try '--help'.
  
  Caused by:
      0: failed to connect to /Users/owen/.codex/app-server-control/app-server-control.sock
      1: No such file or directory (os error 2)
  ```
  
  ## What changed
  
  - `codex remote-control` now runs remote control in the foreground and
  prints a Ctrl-C stop hint.
  - `codex remote-control start` starts the daemon and waits for remote
  control readiness before reporting success.
  - `codex remote-control stop` reports stopped/not-running status in
  plain language.
  - Startup failures now include recent managed app-server stderr to make
  daemon issues easier to diagnose.
  - Added coverage for CLI output, readiness waiting, foreground shutdown,
  and stderr log tailing.

  Owen Lin · 2026-05-18 13:39:02 -07:00
  1752f374a8
• Clarify resume hints for renamed threads (#23234)

  Addresses #23181
  
  ## Why
  Renamed threads can share names, so hints that suggest resuming directly
  by name are ambiguous. Issue #23181 asks for the picker hint to include
  the thread name and thread ID in parens so users can disambiguate
  safely.
  
  ## What
  - Adds a shared resume hint formatter for named threads: run `codex
  resume`, then select `<name> (<thread-id>)`.
  - Uses that hint for /rename confirmations, TUI session summaries, and
  CLI/TUI exit messages.
  - Keeps direct `codex resume <thread-id>` guidance for unnamed threads.
  
  ## Verification
  Manually verified that message after `/rename` and after `/exit` include
  session ID in parens.
  
  ---------
  
  Co-authored-by: Felipe Coury <felipe.coury@openai.com>

  Eric Traut · 2026-05-18 11:32:02 -07:00
  4ac3ea20a2
• Support --output-schema for exec resume (#23123)

  ## Why
  
  `codex exec resume` should have the same structured-output support as
  top-level `codex exec`. Without `--output-schema`, multi-turn automation
  has to choose between resumed session context and schema-validated JSON
  output.
  
  Fixes #22998.
  
  ## What changed
  
  - Marked `--output-schema` as a global `codex exec` flag so it can be
  passed after `resume`.
  - Reused the existing output schema plumbing so resumed turns attach the
  schema to the final response request while preserving session context.

  Eric Traut · 2026-05-18 08:55:22 -07:00
  af6ffb6ebb
• exec-server: support auth-backed remote executor registration (#22769)

  This updates remote `exec-server` registration to use normal Codex auth
  instead of a registry-issued credential. The registry request is built
  from the existing auth-provider path, which preserves the biscuit-only
  registry contract introduced in
  [openai/openai#924101](https://github.com/openai/openai/pull/924101)
  while removing the old remote registry bearer env var and its direct
  transport assumptions.
  
  The default remote flow uses persisted ChatGPT auth from the normal
  Codex config/storage path. This PR also includes the containerized Agent
  Identity path needed by
  [openai/openai#924260](https://github.com/openai/openai/pull/924260):
  remote `exec-server` accepts `--allow-agent-identity-auth`, permits
  Agent Identity auth loaded from `CODEX_ACCESS_TOKEN` only when that flag
  is present, and reuses the existing Agent task registration plus derived
  `AgentAssertion` header generation. API-key auth remains unsupported,
  and Agent Identity stays opt-in.
  
  Validation performed beyond normal presubmit coverage:
  - `cargo fmt --all --check`
  - `cargo check -p codex-cli`
  - `cargo test -p codex-exec-server`
  - `cargo test -p codex-cli exec_server_agent_identity_auth_flag_`
  - `cargo test -p codex-cli remote_exec_server_auth_mode_`
  
  I also attempted `cargo test -p codex-cli`. The new CLI tests passed
  inside that run, but the suite ended on an unrelated local
  marketplace-state failure in
  `plugin_list_excludes_unconfigured_repo_local_marketplaces`.

  Michael Zeng · 2026-05-16 12:48:28 -07:00
  b200dd1b6f
• Fix Windows doctor npm root probe (#22967)

  ## Why
  On Windows npm-managed installs expose the working shim as `npm.cmd`.
  `codex doctor` probed bare `npm`, which could incorrectly report that
  npm global-root inspection was unavailable even when the install was
  healthy.
  
  Fixes #22964.
  
  ## What changed
  - Use `npm.cmd` for the doctor npm-root probe on Windows.
  - Keep the existing `npm` probe on non-Windows platforms.

  Eric Traut · 2026-05-16 00:39:27 -07:00
  de9c5c0226
• Preserve image detail in app-server inputs (#20693)

  ## Summary
  
  - Add optional image detail to user image inputs across core, app-server
  v2, thread history/event mapping, and the generated app-server
  schemas/types.
  - Preserve requested detail when serializing Responses image inputs:
  omitted detail stays on the existing `high` default, while explicit
  `original` keeps local images on the original-resolution path.
  - Support `high`/`original` consistently for tool image outputs,
  including MCP `codex/imageDetail`, code-mode image helpers, and
  `view_image`.

  Curtis 'Fjord' Hawthorne · 2026-05-15 15:04:04 -07:00
  8543e39885
• tui: recover local state db startup failures (#22734)

  ## Why
  
  #22580 made app-server startup fail when the local SQLite state database
  cannot be initialized. Embedded/local TUI startup still continued on the
  permissive path, which left the CLI inconsistent and could hide a real
  startup problem behind unrelated UI. This brings local TUI startup onto
  the same fail-closed behavior while keeping recovery humane for the two
  failure modes we are seeing in practice: damaged database files and
  startup stalls caused by another process holding the database write
  lock.
  
  ## What changed
  
  - Embedded TUI startup now uses `state_db::try_init(...)` and returns a
  typed `LocalStateDbStartupError` that preserves the affected database
  path plus the underlying failure detail.
  - CLI startup handles that failure before entering the interactive TUI:
  - lock-contention failures tell users to quit other Codex processes and
  try again
  - failures consistent with a broken local database offer a safe repair
  that backs up Codex-owned SQLite files, rebuilds local database files,
  and retries startup once
  - declined or unsuccessful repairs print concise guidance plus technical
  details
  - Shared startup error plumbing lives in `tui/src/startup_error.rs`,
  while CLI recovery policy and focused recovery tests live in
  `cli/src/state_db_recovery.rs`.
  
  ## Verification
  
  - `cargo test -p codex-tui
  embedded_state_db_failure_is_typed_for_cli_recovery`
  - `cargo test -p codex-cli state_db_recovery`
  - Manually held an exclusive SQLite lock on `state_5.sqlite` and
  confirmed the CLI shows lock-specific guidance without offering repair.
  - Manually exercised the repair path with a deliberately invalid
  `sqlite_home` and confirmed it backs up the blocking path and resumes
  startup.

  Eric Traut · 2026-05-14 18:51:36 -07:00
  3a23e87e20
• permissions: resolve profile identity with constraints (#22683)

  ## Why
  
  This PR is the invariant-cleanup layer that follows the workspace-roots
  base merged in [#22610](https://github.com/openai/codex/pull/22610).
  
  #22610 adds `[permissions.<id>.workspace_roots]` and keeps runtime
  workspace roots separate from the raw permission profile, but its
  in-memory representation is intentionally transitional: `Permissions`
  still carries the selected profile identity next to a constrained
  `PermissionProfile`. That makes APIs such as
  `set_constrained_permission_profile_with_active_profile()` fragile
  because the id and value only mean the right thing when every caller
  keeps them in sync.
  
  This PR introduces a single resolved profile state so profile identity,
  `extends`, the profile value, and profile-declared workspace roots
  travel together. The next PR,
  [#22611](https://github.com/openai/codex/pull/22611), builds on this by
  changing the app-server turn API to select permission profiles by id
  plus runtime workspace roots.
  
  ## Stack Context
  
  - #22610, now merged: adds profile-declared `workspace_roots`, runtime
  workspace roots, and `:workspace_roots` materialization.
  - This PR: replaces the parallel active-profile/profile-value fields
  with `PermissionProfileState`.
  - #22611: switches app-server turn updates toward profile ids plus
  runtime workspace roots.
  - #22612: updates TUI/exec summaries to show the effective workspace
  roots.
  
  Keeping this separate from #22611 is deliberate: reviewers can validate
  the internal state invariant before reviewing the app-server protocol
  migration.
  
  ## What Changed
  
  - Added `ResolvedPermissionProfile::{Legacy, BuiltIn, Named}` and
  `PermissionProfileState`.
  - Typed built-in profile ids with `BuiltInPermissionProfileId`.
  - Moved selected profile identity and profile-declared workspace roots
  into the resolved state.
  - Replaced `Permissions` parallel profile fields with one
  `permission_profile_state`.
  - Removed `set_constrained_permission_profile_with_active_profile()`
  from session sync paths.
  - Kept trusted session replay/`SessionConfigured` compatibility through
  explicit session snapshot helpers.
  - Updated session configuration, MCP initialization, app-server, exec,
  TUI, and guardian call sites to consume `&PermissionProfile` directly.
  
  ## Review Guide
  
  Start with `codex-rs/core/src/config/resolved_permission_profile.rs`; it
  is the new invariant boundary. Then review
  `codex-rs/core/src/config/mod.rs` to see how config loading records
  active profile identity and profile workspace roots. The remaining
  call-site changes are mostly mechanical fallout from
  `Permissions::permission_profile()` returning `&PermissionProfile`
  instead of `&Constrained<PermissionProfile>`.
  
  ## Verification
  
  The existing config/session coverage now constructs and asserts through
  `PermissionProfileState`. The workspace-root config test also asserts
  that profile-declared roots are preserved in the resolved state, which
  is the behavior #22611 relies on when runtime roots become mutable
  through the app-server API.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22683).
  * #22612
  * #22611
  * __->__ #22683

  Michael Bolin · 2026-05-14 18:47:44 -07:00
  3c6d727810
• permissions: support workspace roots in profiles (#22610)

  ## Why
  
  This is the configuration/model half of the alternative permissions
  migration we discussed as a comparison point for
  [#22401](https://github.com/openai/codex/pull/22401) and
  [#22402](https://github.com/openai/codex/pull/22402).
  
  The old `workspace-write` model mixes three concerns that we want to
  keep separate:
  - reusable profile rules that should stay immutable once selected
  - user/runtime workspace roots from `cwd`, `--add-dir`, and legacy
  workspace-write config
  - internal Codex writable roots such as memories, which should not be
  shown as user workspace roots
  
  This PR gives permission profiles first-class `workspace_roots` so users
  can opt multiple repositories into the same `:workspace_roots` rules
  without using broad absolute-path write grants. It also starts
  separating the raw selected profile from the effective runtime profile
  by making `Permissions` expose explicit accessors instead of public
  mutable fields.
  
  A representative `config.toml` looks like this:
  
  ```toml
  default_permissions = "dev"
  
  [permissions.dev.workspace_roots]
  "~/code/openai" = true
  "~/code/developers-website" = true
  
  [permissions.dev.filesystem.":workspace_roots"]
  "." = "write"
  ".codex" = "read"
  ".git" = "read"
  ".vscode" = "read"
  ```
  
  If Codex starts in `~/code/codex` with that profile selected, the
  effective workspace-root set becomes:
  - `~/code/codex` from the runtime `cwd`
  - `~/code/openai` from the profile
  - `~/code/developers-website` from the profile
  
  The `:workspace_roots` rules are materialized across each root, so
  `.git`, `.codex`, and `.vscode` stay scoped the same way everywhere.
  Runtime additions such as `--add-dir` can still layer on later stack
  entries without mutating the selected profile.
  
  ## Stack Shape
  
  This PR intentionally stops before the profile-identity cleanup in
  [#22683](https://github.com/openai/codex/pull/22683) so the base review
  stays focused on config loading, workspace-root materialization, and
  compatibility with legacy `workspace-write`.
  
  The representation in this PR is therefore transitional: `Permissions`
  carries enough state to distinguish the raw constrained profile from the
  effective runtime profile, and there are still call sites that must keep
  the active profile identity and constrained profile value in sync. The
  follow-up PR replaces that with a single resolved profile state
  (`ResolvedPermissionProfile` / `PermissionProfileState`) that keeps the
  profile id, immutable `PermissionProfile`, and profile-declared
  workspace roots together. That follow-up removes APIs such as
  `set_constrained_permission_profile_with_active_profile()` where
  separate arguments could drift out of sync.
  
  Downstream PRs then build on this base to switch app-server turn updates
  to profile ids plus runtime workspace roots and to finish the
  user-visible summary behavior. Reviewers should judge this PR as the
  workspace-roots foundation, not as the final in-memory shape of selected
  permission profiles.
  
  ## Review Guide
  
  Suggested review order:
  
  1. Start with `codex-rs/core/src/config/mod.rs`.
  This is the main shape change in the base slice. `Permissions` now
  stores a private raw `Constrained<PermissionProfile>` plus runtime
  `workspace_roots`. Callers use `permission_profile()` when they need the
  raw constrained value and `effective_permission_profile()` when they
  need a materialized runtime profile. As noted above,
  [#22683](https://github.com/openai/codex/pull/22683) replaces this
  transitional shape with a resolved profile state that keeps identity and
  profile data together.
  
  2. Review `codex-rs/config/src/permissions_toml.rs` and
  `codex-rs/core/src/config/permissions.rs`.
  These add `[permissions.<id>.workspace_roots]`, resolve enabled entries
  relative to the policy cwd, and keep `:workspace_roots` deny-read glob
  patterns symbolic until the actual roots are known.
  
  3. Review `codex-rs/protocol/src/permissions.rs` and
  `codex-rs/protocol/src/models.rs`.
  These add the policy/profile materialization helpers that expand exact
  `:workspace_roots` entries and scoped deny-read globs over every
  workspace root. This is also where `ActivePermissionProfileModification`
  is removed from the core model.
  
  4. Review the legacy bridge in
  `Config::load_from_base_config_with_overrides` and
  `Config::set_legacy_sandbox_policy`.
  This is where legacy `workspace-write` roots become runtime workspace
  roots, while Codex internal writable roots stay internal and do not
  appear as user-facing workspace roots.
  
  5. Then skim downstream call sites.
  The interesting pattern is raw-vs-effective access: state/proxy/bwrap
  paths keep the raw constrained profile, while execution, summaries, and
  user-visible status use the effective profile and workspace-root list.
  
  ## What Changed
  
  - added `[permissions.<id>.workspace_roots]` to the config model and
  schema
  - added runtime `workspace_roots` state to `Config`/`Permissions` and
  `ConfigOverrides`
  - made `Permissions` profile fields private and replaced direct mutation
  with accessors/setters
  - added `PermissionProfile` and `FileSystemSandboxPolicy` helpers for
  materializing `:workspace_roots` exact paths and deny-read globs across
  all roots
  - moved legacy additional writable roots into runtime workspace-root
  state instead of active profile modifications
  - removed `ActivePermissionProfileModification` and its app-server
  protocol/schema export
  - updated sandbox/status summary paths so internal writable roots are
  not reported as user workspace roots
  
  ## Verification Strategy
  
  The targeted tests cover the behavior at the layers where regressions
  are most likely:
  - `codex-rs/core/src/config/config_tests.rs` verifies config loading,
  legacy workspace-root seeding, effective profile materialization, and
  memory-root handling.
  - `codex-rs/core/src/config/permissions_tests.rs` verifies profile
  `workspace_roots` parsing and `:workspace_roots` scoped/glob
  compilation.
  - `codex-rs/protocol/src/permissions.rs` unit tests verify exact and
  glob materialization over multiple workspace roots.
  - `codex-rs/tui/src/status/tests.rs` and
  `codex-rs/utils/sandbox-summary/src/sandbox_summary.rs` verify the
  user-facing summaries show effective workspace roots and hide internal
  writes.
  
  I also ran `cargo check --tests` locally after the latest stack refresh
  to catch cross-crate API breakage from the private-field/accessor
  changes.
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22610).
  * #22612
  * #22611
  * #22683
  * __->__ #22610

  Michael Bolin · 2026-05-14 18:25:23 -07:00
  c25d905f61
• Trim TUI legacy core helper usage (#22695)

  ## Why
  
  The TUI still had a few low-risk dependencies flowing through the
  transitional `legacy_core` namespace after the app-server migration.
  These helpers either already have clearer non-core owners or are
  presentation logic that does not belong in `codex-core`, so moving them
  out reduces the compatibility surface without changing product behavior.
  
  ## What changed
  
  This is a low-risk change, almost completely mechanical in nature.
  
  - Route TUI Codex-home lookup through `codex-utils-home-dir`, use
  `Config::log_dir` directly, and call
  `codex-sandboxing::system_bwrap_warning` without going through
  `legacy_core`.
  - Move shared `codex resume` hint formatting from `codex-core` into
  `codex-utils-cli`.
  - Update CLI and TUI call sites to use the shared CLI utility, and keep
  the resume-command behavior covered by tests in its new home.
  
  ## Verification
  
  - `cargo test -p codex-utils-cli`
  - `cargo test -p codex-utils-cli resume_command`

  Eric Traut · 2026-05-14 16:54:59 -07:00
  3dc278b68e
• [codex] Support multiple forced ChatGPT workspaces (#18161)

  ## Summary
  
  This change lets `forced_chatgpt_workspace_id` accept multiple workspace
  IDs instead of a single value.
  
  It keeps the existing config key name, adds backward-compatible parsing
  for a single string in `config.toml`, and normalizes the setting into an
  allowed workspace list across login enforcement, app-server config
  surfaces, and local ChatGPT auth helpers.
  
  ## Why
  
  Workspace-restricted deployments may need to allow more than one ChatGPT
  workspace without dropping the guardrail entirely.
  
  ## Server-side impact
  
  Codex's local server and app-server protocol needed changes because they
  previously assumed a single workspace ID. The local login flow now
  matches the auth backend interface by sending the allowed workspace list
  as a single comma-separated `allowed_workspace_id` query parameter.
  
  ## Validation
  
  This was tested with:
  
  - A single workspace config
  - With multi-workspace configs
  - With multiple workspaces in the config
  - The user only being a part of a subset of them
  
  All were successful.
  
  Automated coverage:
  
  - `cargo test -p codex-login`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-tui local_chatgpt_auth`
  - `cargo test --locked -p codex-app-server
  login_account_chatgpt_includes_forced_workspace_allowlist_query_param`

  rreichel3-oai · 2026-05-14 17:11:36 -04:00
  02a7205250
• Support explicit MCP OAuth client IDs (#22575)

  ## Why
  Some MCP OAuth providers require a pre-registered public client ID and
  cannot rely on dynamic client registration. Codex already supports MCP
  OAuth, but it had no way to supply that client ID from config into the
  PKCE flow.
  
  ## What changed
  - add `oauth.client_id` under `[mcp_servers.<server>]` config, including
  config editing and schema generation
  - thread the configured client ID through CLI, app-server, plugin login,
  and MCP skill dependency OAuth entrypoints
  - configure RMCP authorization with the explicit client when present,
  while preserving the existing dynamic-registration path when it is
  absent
  - add focused coverage for config parsing/serialization and OAuth URL
  generation
  
  ## Verification
  - `cargo test -p codex-config -p codex-rmcp-client -p codex-mcp -p
  codex-core-plugins`
  - `cargo test -p codex-core blocking_replace_mcp_servers_round_trips
  --lib`
  - `cargo test -p codex-core
  replace_mcp_servers_streamable_http_serializes_oauth_resource --lib`
  - `cargo test -p codex-core config_schema_matches_fixture --lib`
  
  ## Notes
  Broader local package runs still hit unrelated pre-existing stack
  overflows in:
  - `codex-app-server::in_process_start_clamps_zero_channel_capacity`
  -
  `codex-core::resume_agent_from_rollout_uses_edge_data_when_descendant_metadata_source_is_stale`

  Matthew Zeng · 2026-05-14 11:52:43 -07:00
  d8ddeb6869
• [codex] fix plugin CLI active user layer compile (#22666)

  ## Why
  
  PR #21396 merged after #17141 removed the old
  `ConfigLayerStack::get_user_layer()` API. The new plugin CLI call sites
  still used that stale API, which caused `main` to fail compilation.
  
  ## What Changed
  
  - update `codex plugin marketplace list` to read configured marketplaces
  through `get_active_user_layer()`
  - update the plugin snapshot validation helper to use
  `get_active_user_layer()`
  
  This preserves the intended active writable user-layer behavior from the
  profile-aware config API while fixing the stale call sites.
  
  ## Validation
  
  - `cargo check -p codex-cli`
  - `cargo test -p codex-cli --test plugin_cli`
  - `git diff --check`

  Casey Chow · 2026-05-14 18:41:04 +00:00
  4a1f1df8ce
• [codex] add plugin marketplace CLI commands (#21396)

  ## Why
  
  Plugin CLI installs should behave more like `apt-get install`:
  configured marketplaces are the only install sources, the local
  marketplace snapshot is the package index used at install time, and
  `plugins/cache` is only a cache of already-downloaded plugin bytes.
  
  That distinction matters once marketplaces and plugins have auth or
  availability state. A repo-local marketplace manifest or leftover cached
  plugin artifact should not silently become an install source unless the
  marketplace was explicitly configured and its readable snapshot still
  authorizes the plugin.
  
  ## What Changed
  
  - add CLI commands to list configured marketplaces and add, list, or
  remove marketplace plugins
  - accept stable `plugin@marketplace` ids for add/remove while preserving
  the explicit `--marketplace` form
  - restrict `codex plugin add` and `codex plugin list` to configured
  marketplaces instead of also discovering current-working-directory
  marketplace roots
  - fail `codex plugin add` and `codex plugin list` when a configured
  marketplace snapshot is missing or malformed instead of treating it as
  an empty source or a generic plugin miss
  - preserve marketplace snapshot semantics: a configured local/Git
  marketplace snapshot can authorize installs without consulting the
  original upstream source
  - allow `plugins/cache` reuse only after configured marketplace
  resolution succeeds
  - keep removal resilient after marketplace deletion or drift and ignore
  malformed marketplace config entries in listing
  
  ## Commands Added
  
  - `codex plugin add <plugin>@<marketplace>`
  - `codex plugin add <plugin> --marketplace <marketplace>`
  - `codex plugin list`
  - `codex plugin list --marketplace <marketplace>`
  - `codex plugin remove <plugin>@<marketplace>`
  - `codex plugin remove <plugin> --marketplace <marketplace>`
  - `codex plugin marketplace add <source>`
  - `codex plugin marketplace add <source> --ref <ref>`
  - `codex plugin marketplace add <source> --sparse <path>`
  - `codex plugin marketplace list`
  - `codex plugin marketplace upgrade`
  - `codex plugin marketplace upgrade <marketplace>`
  - `codex plugin marketplace remove <marketplace>`
  
  ## CLI Help Output
  
  <details>
  <summary><code>codex plugin --help</code></summary>
  
  ```text
  Manage Codex plugins
  
  Usage: codex plugin [OPTIONS] <COMMAND>
  
  Commands:
    add          Install a plugin from a configured marketplace snapshot
    list         List plugins available from configured marketplace snapshots
    marketplace  Add, list, upgrade, or remove configured plugin marketplaces
    remove       Remove an installed plugin from local config and cache
    help         Print this message or the help of the given subcommand(s)
  ```
  
  </details>
  
  <details>
  <summary><code>codex plugin add --help</code></summary>
  
  ```text
  Install a plugin from a configured marketplace snapshot.
  
  Pass either `PLUGIN@MARKETPLACE` or pass `PLUGIN` with `--marketplace MARKETPLACE`.
  
  Usage: codex plugin add [OPTIONS] <PLUGIN[@MARKETPLACE]>
  
  Arguments:
    <PLUGIN[@MARKETPLACE]>
            Plugin selector to install: either PLUGIN@MARKETPLACE or PLUGIN with --marketplace
  
  Options:
    -m, --marketplace <MARKETPLACE>
            Configured marketplace name to use when PLUGIN does not include @MARKETPLACE
  
  Examples:
    codex plugin add sample@debug
    codex plugin add sample --marketplace debug
  ```
  
  </details>
  
  <details>
  <summary><code>codex plugin list --help</code></summary>
  
  ```text
  List plugins available from configured marketplace snapshots
  
  Usage: codex plugin list [OPTIONS]
  
  Options:
    -m, --marketplace <MARKETPLACE>
            Only list plugins from this configured marketplace name
  
  Examples:
    codex plugin list
    codex plugin list --marketplace debug
  ```
  
  </details>
  
  <details>
  <summary><code>codex plugin remove --help</code></summary>
  
  ```text
  Remove an installed plugin from local config and cache.
  
  Pass either `PLUGIN@MARKETPLACE` or pass `PLUGIN` with `--marketplace MARKETPLACE`.
  
  Usage: codex plugin remove [OPTIONS] <PLUGIN[@MARKETPLACE]>
  
  Arguments:
    <PLUGIN[@MARKETPLACE]>
            Plugin selector to remove: either PLUGIN@MARKETPLACE or PLUGIN with --marketplace
  
  Options:
    -m, --marketplace <MARKETPLACE>
            Marketplace name to use when PLUGIN does not include @MARKETPLACE
  
  Examples:
    codex plugin remove sample@debug
    codex plugin remove sample --marketplace debug
  ```
  
  </details>
  
  <details>
  <summary><code>codex plugin marketplace --help</code></summary>
  
  ```text
  Add, list, upgrade, or remove configured plugin marketplaces
  
  Usage: codex plugin marketplace [OPTIONS] <COMMAND>
  
  Commands:
    add      Add a local or Git marketplace to the configured marketplace sources
    list     List configured marketplace names and their local snapshot roots
    upgrade  Refresh configured Git marketplace snapshots
    remove   Remove a configured marketplace source by name
  ```
  
  </details>
  
  <details>
  <summary><code>codex plugin marketplace add --help</code></summary>
  
  ```text
  Add a local or Git marketplace to the configured marketplace sources
  
  Usage: codex plugin marketplace add [OPTIONS] <SOURCE>
  
  Arguments:
    <SOURCE>
            Marketplace source: a local path, owner/repo[@ref], HTTPS Git URL, or SSH Git URL
  
  Options:
        --ref <REF>
            Git ref to fetch for Git marketplace sources
  
        --sparse <PATH>
            Sparse checkout path for Git marketplace sources. Can be repeated
  
  Examples:
    codex plugin marketplace add ./path/to/marketplace
    codex plugin marketplace add owner/repo --ref main
    codex plugin marketplace add https://github.com/owner/repo --sparse plugins/foo
  ```
  
  </details>
  
  <details>
  <summary><code>codex plugin marketplace list --help</code></summary>
  
  ```text
  List configured marketplace names and their local snapshot roots
  
  Usage: codex plugin marketplace list [OPTIONS]
  ```
  
  </details>
  
  <details>
  <summary><code>codex plugin marketplace upgrade --help</code></summary>
  
  ```text
  Refresh configured Git marketplace snapshots.
  
  Omit MARKETPLACE_NAME to upgrade all configured Git marketplaces.
  
  Usage: codex plugin marketplace upgrade [OPTIONS] [MARKETPLACE_NAME]
  
  Arguments:
    [MARKETPLACE_NAME]
            Optional configured marketplace name to upgrade. Omit to upgrade all Git marketplaces
  
  Examples:
    codex plugin marketplace upgrade
    codex plugin marketplace upgrade debug
  ```
  
  </details>
  
  <details>
  <summary><code>codex plugin marketplace remove --help</code></summary>
  
  ```text
  Remove a configured marketplace source by name
  
  Usage: codex plugin marketplace remove [OPTIONS] <MARKETPLACE_NAME>
  
  Arguments:
    <MARKETPLACE_NAME>
            Configured marketplace name to remove
  
  Example:
    codex plugin marketplace remove debug
  ```
  
  </details>
  
  ## Public Semantics
  
  - `codex plugin add <plugin>@<marketplace>` succeeds only when
  `<marketplace>` is configured and its local marketplace snapshot
  contains `<plugin>`
  - repo-local marketplaces are not install sources until the user runs
  `codex plugin marketplace add ...`
  - configured marketplace snapshots must be readable; missing or
  malformed snapshots fail the CLI operation rather than silently falling
  through to cache or empty results
  - cached plugin artifacts can satisfy reinstall only when the configured
  marketplace snapshot still authorizes that plugin
  - cached plugin artifacts alone never make a plugin installable
  
  ## Tests
  
  - `cargo test -p codex-cli --test plugin_cli`
  - `cargo clippy -p codex-cli --tests -- -D warnings`
  - `cargo test -p codex-cli`
  - `git diff --check`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  Casey Chow · 2026-05-14 09:33:38 -07:00
  74a1b46a00
• feat: add layered --profile-v2 config files (#17141)

  ## Why
  
  `--profile-v2 <name>` gives launchers and runtime entry points a named
  profile config without making each profile duplicate the base user
  config. The base `$CODEX_HOME/config.toml` still loads first, then
  `$CODEX_HOME/<name>.config.toml` layers above it and becomes the active
  writable user config for that session.
  
  That keeps shared defaults, plugin/MCP setup, and managed/user
  constraints in one place while letting a named profile override only the
  pieces that need to differ.
  
  ## What Changed
  
  - Added the shared `--profile-v2 <name>` runtime option with validated
  plain names, now represented by `ProfileV2Name`.
  - Extended config layer state so the base user config and selected
  profile config are both `User` layers; APIs expose the active user layer
  and merged effective user config.
  - Threaded profile selection through runtime entry points: `codex`,
  `codex exec`, `codex review`, `codex resume`, `codex fork`, and `codex
  debug prompt-input`.
  - Made user-facing config writes go to the selected profile file when
  active, including TUI/settings persistence, app-server config writes,
  and MCP/app tool approval persistence.
  - Made plugin, marketplace, MCP, hooks, and config reload paths read
  from the merged user config so base and profile layers both participate.
  - Updated app-server config layer schemas to mark profile-backed user
  layers.
  
  ## Limits
  
  `--profile-v2` is still rejected for config-management subcommands such
  as feature, MCP, and marketplace edits. Those paths remain tied to the
  base `config.toml` until they have explicit profile-selection semantics.
  
  Some adjacent background writes may still update base or global state
  rather than the selected profile:
  
  - marketplace auto-upgrade metadata
  - automatic MCP dependency installs from skills
  - remote plugin sync or uninstall config edits
  - personality migration marker/default writes
  
  ## Verification
  
  Added targeted coverage for profile name validation, layer
  ordering/merging, selected-profile writes, app-server config writes,
  session hot reload, plugin config merging, hooks/config fixture updates,
  and MCP/app approval persistence.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-14 15:16:15 +02:00
  deedf3b2c4
• enable/disable remote control at runtime, not via features (#22578)

  ## Why
  reapplies https://github.com/openai/codex/pull/22386 which was
  previously reverted
  
  Also, introduce `remoteControl/enable` and `remoteControl/disable`
  app-server APIs to toggle on/off remote control at runtime for a given
  running app-server instance.
  
  ## What Changed
  
  - Adds experimental v2 RPCs:
    - `remoteControl/enable`
    - `remoteControl/disable`
  - Adds `RemoteControlRequestProcessor` and routes the new RPCs through
  it instead of `ConfigRequestProcessor`.
  - Adds named `RemoteControlHandle::enable`, `disable`, and `status`
  methods.
  - Makes `remoteControl/enable` return an error when sqlite state DB is
  unavailable, while keeping enrollment/websocket failures as async status
  updates.
  - Adds `AppServerRuntimeOptions.remote_control_enabled` and hidden
  `--remote-control` flags for `codex app-server` and `codex-app-server`.
  - Updates managed daemon startup to use `codex app-server
  --remote-control --listen unix://`.
  - Marks `Feature::RemoteControl` as removed and ignores
  `[features].remote_control`.
  - Updates app-server README entries for the new remote-control methods.

  Owen Lin · 2026-05-14 01:07:46 +00:00
  4e368aa2e9
• Improve remote-control daemon UX (#22562)

  ## Why
  
  `codex remote-control` manages the app-server daemon with
  `remote_control` enabled, but it previously only exposed an implicit
  start path. Once started, there was no obvious top-level
  `remote-control` command for stopping the daemon; users had to know
  about the lower-level `codex app-server daemon stop` command.
  
  The startup failure for missing managed installs was also ambiguous.
  `codex remote-control` and daemon bootstrap require the standalone Codex
  install under `CODEX_HOME/packages/standalone/current/codex`, but the
  old error only said to install Codex first, which is unclear when
  another `codex` binary is already on PATH. Now we add an explicit
  instruction for how to get the standalone Codex install.
  
  ## What changed
  
  - Converts `codex remote-control` into a command group while preserving
  bare `codex remote-control` as the existing start behavior.
  - Adds `codex remote-control start` as the explicit start path.
  - Adds `codex remote-control stop`, which maps to app-server daemon
  stop.
  - Updates the shared daemon managed-install error to name the missing
  standalone path, explain why that install is required, provide the
  installer command, and tell users to rerun the command they just tried.
  
  ## Verification
  
  - `cargo test -p codex-app-server-daemon`
  - `cargo test -p codex-cli`
  - `./target/debug/codex remote-control --help`

  Owen Lin · 2026-05-13 18:04:08 -07:00
  512f8f8012
• feat(cli): add codex doctor diagnostics (#22336)

  ## Why
  
  Users and support need a single command that captures the local Codex
  runtime, configuration, auth, terminal, network, and state shape without
  asking the user to know which diagnostic depth to choose first. `codex
  doctor` now runs the useful checks by default and makes the detailed
  human output the default because the command is usually run when someone
  already needs context.
  
  The command also targets concrete support failure modes we have seen
  while iterating on the design:
  
  - update-target mismatches like #21956, where the installed package
  manager target can differ from the running executable
  - terminal and multiplexer issues that depend on `TERM`, tmux/zellij
  state, color handling, and TTY metadata
  - provider-specific HTTP/WebSocket connectivity, including ChatGPT
  WebSocket handshakes and API-key/provider endpoint reachability
  - local state/log SQLite integrity problems and large rollout
  directories
  - feedback reports that need an attached, redacted diagnostic snapshot
  without asking the user to run a second command
  
  ## What Changed
  
  - Adds `codex doctor` as a grouped CLI diagnostic report with default
  detailed output and `--summary` for the compact view.
  - Adds stable report sections for Environment, Configuration, Updates,
  Connectivity, and Background Server, plus a top Notes block that
  promotes anomalies such as available updates, large rollout directories,
  optional MCP issues, and mixed auth signals.
  - Adds runtime provenance, install consistency, bundled/system search
  readiness, terminal/multiplexer metadata, `config.toml` parse status,
  auth mode details, sandbox details, feature flag summaries, update
  cache/latest-version state, app-server daemon state, SQLite integrity
  checks, rollout statistics, and provider-aware network diagnostics.
  - Adds ChatGPT WebSocket diagnostics that report the negotiated HTTP
  upgrade as `HTTP 101 Switching Protocols` and include timeout, DNS,
  auth, and provider context in detailed output.
  - Makes reachability provider-aware: API-key OpenAI setups check the API
  endpoint, ChatGPT auth checks the ChatGPT path, and custom/AWS/local
  providers check configured HTTP endpoints when available.
  - Adds structured, redacted JSON output where `checks` is keyed by check
  id and `details` is a key/value object for support tooling.
  - Integrates doctor with feedback uploads by attaching a best-effort
  `codex-doctor-report.json` report and adding derived Sentry tags for
  overall status and failing/warning checks.
  - Updates the TUI feedback consent copy so users can see that the doctor
  report is included when logs/diagnostics are uploaded.
  - Updates the CLI bug issue template to ask reporters for `codex doctor
  --json` and render pasted reports as JSON.
  
  ## Example Output
  
  The examples below are sanitized from local smoke runs with `--no-color`
  so the structure is reviewable in plain text.
  
  ### `codex doctor`
  
  ```text
  Codex Doctor v0.0.0 · macos-aarch64
  
  Notes
     ↑ updates      0.130.0 available (current 0.0.0, dismissed 0.128.0)
     ⚠ rollouts     1,526 active files · 2.53 GB on disk
     ⚠ mcp          MCP configuration has optional issues
     ⚠ auth         mixed auth signals: ChatGPT login plus API key env var; HTTP reachability uses API-key mode
  ─────────────────────────────────────────────────────────────
  
  Environment
    ✓ runtime      local debug build
        version                  0.0.0
        install method           other
        commit                   unknown
        executable               ~/code/codex.fcoury-doct…x-rs/target/debug/codex
    ✓ install      consistent
        context                  other
        managed by               npm: no · bun: no · package root —
        PATH entries (2)         ~/.local/share/mise/installs/node/24/bin/codex
                                 ~/.local/share/mise/shims/codex
    ✓ search       ripgrep 15.1.0 (system, `rg`)
    ✓ terminal     Ghostty 1.3.2-main-+b0f827665 · tmux 3.6a · TERM=xterm-256color
        terminal                 Ghostty
        TERM_PROGRAM             ghostty
        terminal version         1.3.2-main-+b0f827665
        TERM                     xterm-256color
        multiplexer              tmux 3.6a
        tmux extended-keys       on
        tmux allow-passthrough   on
        tmux set-clipboard       on
    ✓ state        databases healthy
        CODEX_HOME               ~/.codex (dir)
        state DB                 ~/.codex/state_5.sqlite (file) · integrity ok
        log DB                   ~/.codex/logs_2.sqlite (file) · integrity ok
        active rollouts          1,526 files · 2.53 GB (avg 1.70 MB)
        archived rollouts        8 files · 3.84 MB (avg 491.11 KB)
  
  Configuration
    ✓ config       loaded
        model                    gpt-5.5 · openai
        cwd                      ~/code/codex.fcoury-doctor/codex-rs
        config.toml              ~/.codex/config.toml
        config.toml parse        ok
        MCP servers              1
        feature flags            36 enabled · 7 overridden (full list with --all)
        overrides                code_mode, code_mode_only, memories, chronicle, goals, remote_control, prevent_idle_sleep
    ✓ auth         auth is configured
        auth storage mode        File
        auth file                ~/.codex/auth.json
        auth env vars present    OPENAI_API_KEY
        stored auth mode         chatgpt
        stored API key           false
        stored ChatGPT tokens    true
        stored agent identity    false
    ⚠ mcp          MCP configuration has optional issues — Set the missing MCP env vars or disable the affected server.
        configured servers       1
        disabled servers         0
        streamable_http servers  1
        optional reachability    openaiDeveloperDocs: https://developers.openai.com/mcp (HEAD connect failed; GET connect failed)
    ✓ sandbox      restricted fs + restricted network · approval OnRequest
        approval policy          OnRequest
        filesystem sandbox       restricted
        network sandbox          restricted
  
  Connectivity
    ✓ network      network-related environment looks readable
    ✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
        model provider           openai
        provider name            OpenAI
        wire API                 responses
        supports websockets      true
        connect timeout          15000 ms
        auth mode                chatgpt
        endpoint                 wss://chatgpt.com/backend-api/<redacted>
        DNS                      2 IPv4, 2 IPv6, first IPv6
        handshake result         HTTP 101 Switching Protocols
    ✗ reachability one or more required provider endpoints are unreachable over HTTP — Check proxy, VPN, firewall, DNS, and custom CA configuration.
        reachability mode        API key auth
        openai API               https://api.openai.com/v1 connect failed (required)
  
  Background Server
    ○ app-server   not running (ephemeral mode)
  
  ─────────────────────────────────────────────────────────────
  11 ok · 1 idle · 4 notes · 1 warn · 1 fail failed
  
  --summary compact output           --all expand truncated lists
  --json redacted report
  ```
  
  ### `codex doctor --summary`
  
  ```text
  Codex Doctor v0.0.0 · macos-aarch64
  
  Notes
     ↑ updates      0.130.0 available (current 0.0.0, dismissed 0.128.0)
     ⚠ rollouts     1,526 active files · 2.53 GB on disk
     ⚠ mcp          MCP configuration has optional issues
     ⚠ auth         mixed auth signals: ChatGPT login plus API key env var; HTTP reachability uses API-key mode
  ─────────────────────────────────────────────────────────────
  
  Environment
    ✓ runtime      local debug build
    ✓ install      consistent
    ✓ search       ripgrep 15.1.0 (system, `rg`)
    ✓ terminal     Ghostty 1.3.2-main-+b0f827665 · tmux 3.6a · TERM=xterm-256color
    ✓ state        databases healthy
  
  Configuration
    ✓ config       loaded
    ✓ auth         auth is configured
    ⚠ mcp          MCP configuration has optional issues — Set the missing MCP env vars or disable the affected server.
    ✓ sandbox      restricted fs + restricted network · approval OnRequest
  
  Updates
    ✓ updates      update configuration is locally consistent
  
  Connectivity
    ✓ network      network-related environment looks readable
    ✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
    ✗ reachability one or more required provider endpoints are unreachable over HTTP — Check proxy, VPN, firewall, DNS, and custom CA configuration.
  
  Background Server
    ○ app-server   not running (ephemeral mode)
  
  ─────────────────────────────────────────────────────────────
  11 ok · 1 idle · 4 notes · 1 warn · 1 fail failed
  
  Run codex doctor without --summary for detailed diagnostics.
  --all expand truncated lists       --json redacted report
  ```
  
  ### `codex doctor --json` shape
  
  ```json
  {
    "schema_version": 1,
    "overall_status": "fail",
    "checks": {
      "runtime.provenance": {
        "id": "runtime.provenance",
        "category": "Environment",
        "status": "ok",
        "summary": "local debug build",
        "details": {
          "version": "0.0.0",
          "install method": "other",
          "commit": "unknown"
        }
      },
      "sandbox.helpers": {
        "id": "sandbox.helpers",
        "category": "Configuration",
        "status": "ok",
        "summary": "restricted fs + restricted network · approval OnRequest",
        "details": {
          "approval policy": "OnRequest",
          "filesystem sandbox": "restricted",
          "network sandbox": "restricted"
        }
      }
    }
  }
  ```
  
  ### `/feedback` new sentry attachment
  
  <img width="938" height="798" alt="CleanShot 2026-05-13 at 15 36 14"
  src="https://github.com/user-attachments/assets/715e62e0-d7b4-4fea-a35a-fd5d5d33c4c0"
  />
  
  ### New section in CLI issue template
  
  <img width="1164" height="435" alt="CleanShot 2026-05-13 at 15 47 24"
  src="https://github.com/user-attachments/assets/9081dc25-a28c-4afa-8ba1-e299c2b4031d"
  />
  
  ## How to Test
  
  1. Run `cargo run --bin codex -- doctor --no-color`.
  2. Confirm the detailed report is the default and includes promoted
  Notes, grouped sections, terminal details, state DB integrity, rollout
  stats, provider reachability, WebSocket diagnostics, and app-server
  status.
  3. Run `cargo run --bin codex -- doctor --summary --no-color`.
  4. Confirm the compact view keeps the same sections and summary counts
  but omits detailed key/value rows.
  5. Run `cargo run --bin codex -- doctor --json`.
  6. Confirm the output is redacted JSON, `checks` is an object keyed by
  check id, and each check's `details` is a key/value object.
  7. Preview the CLI bug issue template and confirm the `Codex doctor
  report` field appears after the terminal field, asks for `codex doctor
  --json`, and renders pasted output as JSON.
  8. Start a feedback flow that includes logs.
  9. Confirm the upload consent copy lists `codex-doctor-report.json`
  alongside the log attachments.
  
  Targeted tests:
  
  - `cargo test -p codex-cli doctor`
  - `cargo test -p codex-app-server
  doctor_report_tags_summarize_status_counts`
  - `cargo test -p codex-feedback`
  - `cargo test -p codex-tui feedback_view`
  - `just argument-comment-lint`
  - `git diff --check`

  Felipe Coury · 2026-05-13 21:23:19 +00:00
  9798eb377a
• revert: mark Feature::RemoteControl as removed (#22520)

  reverts: https://github.com/openai/codex/pull/22386

  Owen Lin · 2026-05-13 17:32:15 +00:00
  2b3b220605
• config: add strict config parsing (#20559)

  ## Why
  
  Codex intentionally ignores unknown `config.toml` fields by default so
  older and newer config files keep working across versions. That leniency
  also makes typo detection hard because misspelled or misplaced keys
  disappear silently.
  
  This change adds an opt-in strict config mode so users and tooling can
  fail fast on unrecognized config fields without changing the default
  permissive behavior.
  
  This feature is possible because `serde_ignored` exposes the exact
  signal Codex needs: it lets Codex run ordinary Serde deserialization
  while recording fields Serde would otherwise ignore. That avoids
  requiring `#[serde(deny_unknown_fields)]` across every config type and
  keeps strict validation opt-in around the existing config model.
  
  ## What Changed
  
  ### Added strict config validation
  
  - Added `serde_ignored`-based validation for `ConfigToml` in
  `codex-rs/config/src/strict_config.rs`.
  - Combined `serde_ignored` with `serde_path_to_error` so strict mode
  preserves typed config error paths while also collecting fields Serde
  would otherwise ignore.
  - Added strict-mode validation for unknown `[features]` keys, including
  keys that would otherwise be accepted by `FeaturesToml`'s flattened
  boolean map.
  - Kept typed config errors ahead of ignored-field reporting, so
  malformed known fields are reported before unknown-field diagnostics.
  - Added source-range diagnostics for top-level and nested unknown config
  fields, including non-file managed preference source names.
  
  ### Kept parsing single-pass per source
  
  - Reworked file and managed-config loading so strict validation reuses
  the already parsed `TomlValue` for that source.
  - For actual config files and managed config strings, the loader now
  reads once, parses once, and validates that same parsed value instead of
  deserializing multiple times.
  - Validated `-c` / `--config` override layers with the same
  base-directory context used for normal relative-path resolution, so
  unknown override keys are still reported when another override contains
  a relative path.
  
  ### Scoped `--strict-config` to config-heavy entry points
  
  - Added support for `--strict-config` on the main config-loading entry
  points where it is most useful:
    - `codex`
    - `codex resume`
    - `codex fork`
    - `codex exec`
    - `codex review`
    - `codex mcp-server`
    - `codex app-server` when running the server itself
    - the standalone `codex-app-server` binary
    - the standalone `codex-exec` binary
  - Commands outside that set now reject `--strict-config` early with
  targeted errors instead of accepting it everywhere through shared CLI
  plumbing.
  - `codex app-server` subcommands such as `proxy`, `daemon`, and
  `generate-*` are intentionally excluded from the first rollout.
  - When app-server strict mode sees invalid config, app-server exits with
  the config error instead of logging a warning and continuing with
  defaults.
  - Introduced a dedicated `ReviewCommand` wrapper in `codex-rs/cli`
  instead of extending shared `ReviewArgs`, so `--strict-config` stays on
  the outer config-loading command surface and does not become part of the
  reusable review payload used by `codex exec review`.
  
  ### Coverage
  
  - Added tests for top-level and nested unknown config fields, unknown
  `[features]` keys, typed-error precedence, source-location reporting,
  and non-file managed preference source names.
  - Added CLI coverage showing invalid `--enable`, invalid `--disable`,
  and unknown `-c` overrides still error when `--strict-config` is
  present, including compound-looking feature names such as
  `multi_agent_v2.subagent_usage_hint_text`.
  - Added integration coverage showing both `codex app-server
  --strict-config` and standalone `codex-app-server --strict-config` exit
  with an error for unknown config fields instead of starting with
  fallback defaults.
  - Added coverage showing unsupported command surfaces reject
  `--strict-config` with explicit errors.
  
  ## Example Usage
  
  Run Codex with strict config validation enabled:
  
  ```shell
  codex --strict-config
  ```
  
  Strict config mode is also available on the supported config-heavy
  subcommands:
  
  ```shell
  codex --strict-config exec "explain this repository"
  codex review --strict-config --uncommitted
  codex mcp-server --strict-config
  codex app-server --strict-config --listen off
  codex-app-server --strict-config --listen off
  ```
  
  For example, if `~/.codex/config.toml` contains a typo in a key name:
  
  ```toml
  model = "gpt-5"
  approval_polic = "on-request"
  ```
  
  then `codex --strict-config` reports the misspelled key instead of
  silently ignoring it. The path is shortened to `~` here for readability:
  
  ```text
  $ codex --strict-config
  Error loading config.toml:
  ~/.codex/config.toml:2:1: unknown configuration field `approval_polic`
    |
  2 | approval_polic = "on-request"
    | ^^^^^^^^^^^^^^
  ```
  
  Without `--strict-config`, Codex keeps the existing permissive behavior
  and ignores the unknown key.
  
  Strict config mode also validates ad-hoc `-c` / `--config` overrides:
  
  ```text
  $ codex --strict-config -c foo=bar
  Error: unknown configuration field `foo` in -c/--config override
  
  $ codex --strict-config -c features.foo=true
  Error: unknown configuration field `features.foo` in -c/--config override
  ```
  
  Invalid feature toggles are rejected too, including values that look
  like nested config paths:
  
  ```text
  $ codex --strict-config --enable does_not_exist
  Error: Unknown feature flag: does_not_exist
  
  $ codex --strict-config --disable does_not_exist
  Error: Unknown feature flag: does_not_exist
  
  $ codex --strict-config --enable multi_agent_v2.subagent_usage_hint_text
  Error: Unknown feature flag: multi_agent_v2.subagent_usage_hint_text
  ```
  
  Unsupported commands reject the flag explicitly:
  
  ```text
  $ codex --strict-config cloud list
  Error: `--strict-config` is not supported for `codex cloud`
  ```
  
  ## Verification
  
  The `codex-cli` `strict_config` tests cover invalid `--enable`, invalid
  `--disable`, the compound `multi_agent_v2.subagent_usage_hint_text`
  case, unknown `-c` overrides, app-server strict startup failure through
  `codex app-server`, and rejection for unsupported commands such as
  `codex cloud`, `codex mcp`, `codex remote-control`, and `codex
  app-server proxy`.
  
  The config and config-loader tests cover unknown top-level fields,
  unknown nested fields, unknown `[features]` keys, source-location
  reporting, non-file managed config sources, and `-c` validation for keys
  such as `features.foo`.
  
  The app-server test suite covers standalone `codex-app-server
  --strict-config` startup failure for an unknown config field.
  
  ## Documentation
  
  The Codex CLI docs on developers.openai.com/codex should mention
  `--strict-config` as an opt-in validation mode for supported
  config-heavy entry points once this ships.

  Michael Bolin · 2026-05-13 16:08:05 +00:00
  889ee018e7
• add --dangerously-bypass-hook-trust CLI flag (#21768)

  # Why
  
  Hook trust happens through the TUI in `/hooks` so it can block
  non-interactive use cases. This flag will allow users that are using
  codex headlessly to bypass hooks when they want to.
  
  # What
  
  This adds one invocation-scoped escape hatch.
  
  - the CLI flag sets a runtime-only `bypass_hook_trust` override; there
  is no durable `config.toml` setting
  - hook discovery still respects normal enablement, so explicitly
  disabled hooks remain disabled
  - we show a `--dangerously-bypass-hook-trust is enabled. Enabled hooks
  may run without review for this invocation.` message on startup so
  accidental use is visible in both interactive and exec flows
  
  This keeps “enabled” and “trusted” as separate concepts in the normal
  path, while giving CI/E2E callers a stable way to opt into the
  exceptional path when they already control the hook set.

  Abhinav · 2026-05-13 07:13:57 +00:00
  392e94e9ea