507 Commits

• [codex] reduce module visibility (#16978)

  ## Summary
  - reduce public module visibility across Rust crates, preferring private
  or crate-private modules with explicit crate-root public exports
  - update external call sites and tests to use the intended public crate
  APIs instead of reaching through module trees
  - add the module visibility guideline to AGENTS.md
  
  ## Validation
  - `cargo check --workspace --all-targets --message-format=short` passed
  before the final fix/format pass
  - `just fix` completed successfully
  - `just fmt` completed successfully
  - `git diff --check` passed

  pakrym-oai · 2026-04-07 08:03:35 -07:00
  413c1e1fdf
• feat: /feedback cascade (#16442)

  Example here:
  https://openai.sentry.io/issues/7380240430/?project=4510195390611458&query=019d498f-bec4-7ba2-96d2-612b1e4507df&referrer=issue-stream

  jif-oai · 2026-04-07 12:47:37 +01:00
  89f1a44afa
• Honor null thread instructions (#16964)

  - Treat explicit null thread instructions as a blank-slate override
  while preserving omitted-field fallback behavior.
  - Preserve null through rollout resume/fork and keep explicit empty
  strings distinct.
  - Add app-server v2 start/fork coverage for the tri-state instruction
  params.

  Ahmed Ibrahim · 2026-04-07 04:10:19 +00:00
  24c598e8a9
• [codex] Add danger-full-access denylist-only network mode (#16946)

  ## Summary
  
  This adds `experimental_network.danger_full_access_denylist_only` for
  orgs that want yolo / danger-full-access sessions to keep full network
  access while still enforcing centrally managed deny rules.
  
  When the flag is true and the session sandbox is `danger-full-access`,
  the network proxy starts with:
  
  - domain allowlist set to `*`
  - managed domain `deny` entries enforced
  - upstream proxy use allowed
  - all Unix sockets allowed
  - local/private binding allowed
  
  Caveat: the denylist is best effort only. In yolo / danger-full-access
  mode, Codex or the model can use an allowed socket or other
  local/private network path to bypass the proxy denylist, so this should
  not be treated as a hard security boundary.
  
  The flag is intentionally scoped to `SandboxPolicy::DangerFullAccess`.
  Read-only and workspace-write modes keep the existing managed/user
  allowlist, denylist, Unix socket, and local-binding behavior. This does
  not enable the non-loopback proxy listener setting; that still requires
  its own explicit config.
  
  This also threads the new field through config requirements parsing,
  app-server protocol/schema output, config API mapping, and the TUI debug
  config output.
  
  ## How to use
  
  Add the flag under `[experimental_network]` in the network policy config
  that is delivered to Codex. The setting is not under `[permissions]`.
  
  ```toml
  [experimental_network]
  enabled = true
  danger_full_access_denylist_only = true
  
  [experimental_network.domains]
  "blocked.example.com" = "deny"
  "*.blocked.example.com" = "deny"
  ```
  
  With that configuration, yolo / danger-full-access sessions get broad
  network access except for the managed denied domains above. The denylist
  remains a best-effort proxy policy because the session may still use
  allowed sockets to bypass it. Other sandbox modes do not get the
  wildcard domain allowlist or the socket/local-binding relaxations from
  this flag.
  
  ## Verification
  
  - `cargo test -p codex-config network_requirements`
  - `cargo test -p codex-core network_proxy_spec`
  - `cargo test -p codex-app-server map_requirements_toml_to_api`
  - `cargo test -p codex-tui debug_config_output`
  - `cargo test -p codex-app-server-protocol`
  - `just write-app-server-schema`
  - `just fmt`
  - `just fix -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-app-server -p codex-tui`
  - `just fix -p codex-core -p codex-config`
  - `git diff --check`
  - `cargo clean`

  viyatb-oai · 2026-04-06 19:38:51 -07:00
  9d13d29acd
• [mcp] Support MCP Apps part 1. (#16082)

  - [x] Add `mcpResource/read` method to read mcp resource.

  Matthew Zeng · 2026-04-06 19:17:14 -07:00
  5fe9ef06ce
• app-server: Unify config changes handling a bit (#16961)
  Ruslan Nigmatullin · 2026-04-06 18:04:00 -07:00
  b34a3a6e92
• Refactor config types into a separate crate (#16962)

  Move config types into a separate crate because their macros expand into
  a lot of new code.

  pakrym-oai · 2026-04-07 00:32:41 +00:00
  1f2411629f
• Speed up /mcp inventory listing (#16831)

  Addresses #16244
  
  This was a performance regression introduced when we moved the TUI on
  top of the app server API.
  
  Problem: `/mcp` rebuilt a full MCP inventory through
  `mcpServerStatus/list`, including resources and resource templates that
  made the TUI wait on slow inventory probes.
  
  Solution: add a lightweight `detail` mode to `mcpServerStatus/list`,
  have `/mcp` request tools-and-auth only, and cover the fast path with
  app-server and TUI tests.
  
  Testing: Confirmed slow (multi-second) response prior to change and
  immediate response after change.
  
  I considered two options:
  1. Change the existing `mcpServerStatus/list` API to accept an optional
  "details" parameter so callers can request only a subset of the
  information.
  2. Add a separate `mcpServer/list` API that returns only the servers,
  tools, and auth but omits the resources.
  
  I chose option 1, but option 2 is also a reasonable approach.

  Eric Traut · 2026-04-06 16:27:02 -07:00
  9f737c28dd
• [codex-analytics] add protocol-native turn timestamps (#16638)

  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16638).
  * #16870
  * #16706
  * #16659
  * #16641
  * #16640
  * __->__ #16638

  rhan-oai · 2026-04-06 16:22:59 -07:00
  756c45ec61
• feat: refresh non-curated cache from plugin list. (#16191)

  1. Use versions for non-curated plugin (defined in plugin.json) for
  cache refresh
  2. Trigger refresh from plugin/list roots

  xl-openai · 2026-04-06 15:40:00 -07:00
  e62d645e67
• app-server: Add transport for remote control (#15951)
  Ruslan Nigmatullin · 2026-04-06 14:55:59 -07:00
  73dab2046f
• Revert "[codex-backend] Make thread metadata updates tolerate pending backfill" (#16923)

  Reverts openai/codex#16877

  joeytrasatti-openai · 2026-04-06 21:25:05 +00:00
  03c07956cf
• Fix clippy warning (#16939)

  - [x] Fix clippy warning

  Matthew Zeng · 2026-04-06 14:08:55 -07:00
  756ba8baae
• app-server: centralize AuthManager initialization (#16764)

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

  Ruslan Nigmatullin · 2026-04-06 12:46:55 -07:00
  1525bbdb9a
• fix(guardian): fix ordering of guardian events (#16462)

  Guardian events were emitted a bit out of order for CommandExecution
  items. This would make it hard for the frontend to render a guardian
  auto-review, which has this payload:
  ```
  pub struct ItemGuardianApprovalReviewStartedNotification {
      pub thread_id: String,
      pub turn_id: String,
      pub target_item_id: String,
      pub review: GuardianApprovalReview,
      // FYI this is no longer a json blob
      pub action: Option<JsonValue>,
  }
  ```
  
  There is a `target_item_id` the auto-approval review is referring to,
  but the actual item had not been emitted yet.
  
  Before this PR:
  - `item/autoApprovalReview/started`
  - `item/autoApprovalReview/completed`, and if approved...
  - `item/started`
  - `item/completed`
  
  After this PR:
  - `item/started`
  - `item/autoApprovalReview/started`
  - `item/autoApprovalReview/completed`
  - `item/completed`
  
  This lines up much better with existing patterns (i.e. human review in
  `Default mode`, where app-server would send a server request to prompt
  for user approval after `item/started`), and makes it easier for clients
  to render what guardian is actually reviewing.
  
  We do this following a similar pattern as `FileChange` (aka apply patch)
  items, where we create a FileChange item and emit `item/started` if we
  see the apply patch approval request, before the actual apply patch call
  runs.

  Owen Lin · 2026-04-06 19:14:27 +00:00
  bd30bad96f
• feat(requirements): support allowed_approval_reviewers (#16701)

  ## Description
  
  Add requirements.toml support for `allowed_approvals_reviewers =
  ["user", "guardian_subagent"]`, so admins can now restrict the use of
  guardian mode.
  
  Note: If a user sets a reviewer that isn’t allowed by requirements.toml,
  config loading falls back to the first allowed reviewer and emits a
  startup warning.
  
  The table below describes the possible admin controls.
  | Admin intent | `requirements.toml` | User `config.toml` | End result |
  |---|---|---|---|
  | Leave Guardian optional | omit `allowed_approvals_reviewers` or set
  `["user", "guardian_subagent"]` | user chooses `approvals_reviewer =
  "user"` or `"guardian_subagent"` | Guardian off for `user`, on for
  `guardian_subagent` + `approval_policy = "on-request"` |
  | Force Guardian off | `allowed_approvals_reviewers = ["user"]` | any
  user value | Effective reviewer is `user`; Guardian off |
  | Force Guardian on | `allowed_approvals_reviewers =
  ["guardian_subagent"]` and usually `allowed_approval_policies =
  ["on-request"]` | any user reviewer value; user should also have
  `approval_policy = "on-request"` unless policy is forced | Effective
  reviewer is `guardian_subagent`; Guardian on when effective approval
  policy is `on-request` |
  | Allow both, but default to manual if user does nothing |
  `allowed_approvals_reviewers = ["user", "guardian_subagent"]` | omit
  `approvals_reviewer` | Effective reviewer is `user`; Guardian off |
  | Allow both, and user explicitly opts into Guardian |
  `allowed_approvals_reviewers = ["user", "guardian_subagent"]` |
  `approvals_reviewer = "guardian_subagent"` and `approval_policy =
  "on-request"` | Guardian on |
  | Invalid admin config | `allowed_approvals_reviewers = []` | anything |
  Config load error |

  Owen Lin · 2026-04-06 11:11:44 -07:00
  ded559680d
• [codex-backend] Make thread metadata updates tolerate pending backfill (#16877)

  ### Summary
  Fix `thread/metadata/update` so it can still patch stored thread
  metadata when the list/backfill-gated `get_state_db(...)` path is
  unavailable.
  
  What was happening:
  - The app logs showed `thread/metadata/update` failing with `sqlite
  state db unavailable for thread ...`.
  - This was not isolated to one bad thread. Once the failure started for
  a user, branch metadata updates failed 100% of the time for that user.
  - Reports were staggered across users, which points at local app-server
  / local SQLite state rather than one global server-side failure.
  - Turns could still start immediately after the metadata update failed,
  which suggests the thread itself was valid and the failure was in the
  metadata endpoint DB-handle path.
  
  The fix:
  - Keep using the loaded thread state DB and the normal
  `get_state_db(...)` fallback first.
  - If that still returns `None`, open `StateRuntime::init(...)` directly
  for this targeted metadata update path.
  - Log the direct state runtime init error if that final fallback also
  fails, so future reports have the real DB-open cause instead of only the
  generic unavailable error.
  - Add a regression test where the DB exists but backfill is not
  complete, and verify `thread/metadata/update` can still repair the
  stored rollout thread and patch `gitInfo`.
  
  Relevant context / suspect PRs:
  - #16434 changed state DB startup to run auto-vacuum / incremental
  vacuum. This is the most suspicious timing match for per-user, staggered
  local SQLite availability failures.
  - #16433 dropped the old log table from the state DB, also near the
  timing window.
  - #13280 introduced this endpoint and made it rely on SQLite for git
  metadata without resuming the thread.
  - #14859 and #14888 added/consumed persisted model + reasoning effort
  metadata. I checked these because of the new thread metadata fields, but
  this failure happens before the endpoint reaches thread-row update/load
  logic, so they seem less likely as the direct cause.
  
  ### Testing
  - `cargo fmt -- --config imports_granularity=Item` completed; local
  stable rustfmt emitted warnings that `imports_granularity` is unstable
  - `cargo test -p codex-app-server thread_metadata_update`
  - `git diff --check`

  joeytrasatti-openai · 2026-04-06 13:07:19 -04:00
  4ce97cef02
• [codex-analytics] subagent analytics (#15915)

  - creates custom event that emits subagent thread analytics from core
  - wires client metadata (`product_client_id, client_name,
  client_version`), through from app-server
  - creates `created_at `timestamp in core
  - subagent analytics are behind `FeatureFlag::GeneralAnalytics`
  
  PR stack
  - [[telemetry] thread events
  #15690](https://github.com/openai/codex/pull/15690)
  - --> [[telemetry] subagent events
  #15915](https://github.com/openai/codex/pull/15915)
  - [[telemetry] turn events
  #15591](https://github.com/openai/codex/pull/15591)
  - [[telemetry] steer events
  #15697](https://github.com/openai/codex/pull/15697)
  - [[telemetry] queued prompt data
  #15804](https://github.com/openai/codex/pull/15804)
  
  Notes:
  - core does not spawn a subagent thread for compact, but represented in
  mapping for consistency
  
  `INFO | 2026-04-01 13:08:12 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:399 | Tracked
  codex_thread_initialized event params={'thread_id':
  '019d4aa9-233b-70f2-a958-c3dbae1e30fa', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': None}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'model': 'gpt-5.3-codex', 'ephemeral':
  False, 'initialization_mode': 'new', 'created_at': 1775074091,
  'thread_source': 'subagent', 'subagent_source': 'thread_spawn',
  'parent_thread_id': '019d4aa8-51ec-77e3-bafb-2c1b8e29e385'} | `
  
  `INFO | 2026-04-01 13:08:41 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:399 | Tracked
  codex_thread_initialized event params={'thread_id':
  '019d4aa9-94e3-75f1-8864-ff8ad0e55e1e', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': None}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'model': 'gpt-5.3-codex', 'ephemeral':
  False, 'initialization_mode': 'new', 'created_at': 1775074120,
  'thread_source': 'subagent', 'subagent_source': 'review',
  'parent_thread_id': None} | `
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  rhan-oai · 2026-04-04 11:06:43 -07:00
  4fd5c35c4f
• Fix Windows Bazel app-server trust tests (#16711)

  ## Why
  
  Extracted from [#16528](https://github.com/openai/codex/pull/16528) so
  the Windows Bazel app-server test failures can be reviewed independently
  from the rest of that PR.
  
  This PR targets:
  
  -
  `suite::v2::thread_shell_command::thread_shell_command_runs_as_standalone_turn_and_persists_history`
  -
  `suite::v2::thread_start::thread_start_with_elevated_sandbox_trusts_project_and_followup_loads_project_config`
  -
  `suite::v2::thread_start::thread_start_with_nested_git_cwd_trusts_repo_root`
  
  There were two Windows-specific assumptions baked into those tests and
  the underlying trust lookup:
  
  - project trust keys were persisted and looked up using raw path
  strings, but Bazel's Windows test environment can surface canonicalized
  paths with `\\?\` / UNC prefixes or normalized symlink/junction targets,
  so follow-up `thread/start` requests no longer matched the project entry
  that had just been written
  - `item/commandExecution/outputDelta` assertions compared exact trailing
  line endings even though shell output chunk boundaries and CRLF handling
  can differ on Windows, and Bazel made that timing-sensitive mismatch
  visible
  
  There was also one behavior bug separate from the assertion cleanup:
  `thread/start` decided whether to persist trust from the final resolved
  sandbox policy, but on Windows an explicit `workspace-write` request may
  be downgraded to `read-only`. That incorrectly skipped writing trust
  even though the request had asked to elevate the project, so the new
  logic also keys off the requested sandbox mode.
  
  ## What
  
  - Canonicalize project trust keys when persisting/loading `[projects]`
  entries, while still accepting legacy raw keys for existing configs.
  - Persist project trust when `thread/start` explicitly requests
  `workspace-write` or `danger-full-access`, even if the resolved policy
  is later downgraded on Windows.
  - Make the Windows app-server tests compare persisted trust paths and
  command output deltas in a path/newline-normalized way.
  
  ## Verification
  
  - Existing app-server v2 tests cover the three failing Windows Bazel
  cases above.

  Michael Bolin · 2026-04-03 21:41:25 +00:00
  a70aee1a1e
• Add remote --cd forwarding for app-server sessions (#16700)

  Addresses #16124
  
  Problem: `codex --remote --cd <path>` canonicalized the path locally and
  then omitted it from remote thread lifecycle requests, so remote-only
  working directories failed or were ignored.
  
  Solution: Keep remote startup on the local cwd, forward explicit `--cd`
  values verbatim to `thread/start`, `thread/resume`, and `thread/fork`,
  and cover the behavior with `codex-tui` tests.
  
  Testing: I manually tested `--remote --cd` with both absolute and
  relative paths and validated correct behavior.
  
  
  ---
  
  Update based on code review feedback:
  
  Problem: Remote `--cd` was forwarded to `thread/resume` and
  `thread/fork`, but not to `thread/list` lookups, so `--resume --last`
  and picker flows could select a session from the wrong cwd; relative cwd
  filters also failed against stored absolute paths.
  
  Solution: Apply explicit remote `--cd` to `thread/list` lookups for
  `--last` and picker flows, normalize relative cwd filters on the
  app-server before exact matching, and document/test the behavior.

  Eric Traut · 2026-04-03 11:26:45 -07:00
  0ab8eda375
• Suppress bwrap warning when sandboxing is bypassed (#16667)

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

  Eric Traut · 2026-04-03 10:54:30 -07:00
  0f7394883e
• Fix MCP tool listing for hyphenated server names (#16674)

  Addresses #16671 and #14927
  
  Problem: `mcpServerStatus/list` rebuilt MCP tool groups from sanitized
  tool prefixes but looked them up by unsanitized server names, so
  hyphenated servers rendered as having no tools in `/mcp`. This was
  reported as a regression when the TUI switched to use the app server.
  
  Solution: Build each server's tool map using the original server name's
  sanitized prefix, include effective runtime MCP servers in the status
  response, and add a regression test for hyphenated server names.

  Eric Traut · 2026-04-03 09:05:50 -07:00
  a3b3e7a6cc
• remove temporary ownership re-exports (#16626)

  Stacked on #16508.
  
  This removes the temporary `codex-core` / `codex-login` re-export shims
  from the ownership split and rewrites callsites to import directly from
  `codex-model-provider-info`, `codex-models-manager`, `codex-api`,
  `codex-protocol`, `codex-feedback`, and `codex-response-debug-context`.
  
  No behavior change intended; this is the mechanical import cleanup layer
  split out from the ownership move.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-03 00:33:34 -07:00
  af8a9d2d2b
• extract models manager and related ownership from core (#16508)

  ## Summary
  - split `models-manager` out of `core` and add `ModelsManagerConfig`
  plus `Config::to_models_manager_config()` so model metadata paths stop
  depending on `core::Config`
  - move login-owned/auth-owned code out of `core` into `codex-login`,
  move model provider config into `codex-model-provider-info`, move API
  bridge mapping into `codex-api`, move protocol-owned types/impls into
  `codex-protocol`, and move response debug helpers into a dedicated
  `response-debug-context` crate
  - move feedback tag emission into `codex-feedback`, relocate tests to
  the crates that now own the code, and keep broad temporary re-exports so
  this PR avoids a giant import-only rewrite
  
  ## Major moves and decisions
  - created `codex-models-manager` as the owner for model
  cache/catalog/config/model info logic, including the new
  `ModelsManagerConfig` struct
  - created `codex-model-provider-info` as the owner for provider config
  parsing/defaults and kept temporary `codex-login`/`codex-core`
  re-exports for old import paths
  - moved `api_bridge` error mapping + `CoreAuthProvider` into
  `codex-api`, while `codex-login::api_bridge` temporarily re-exports
  those symbols and keeps the `auth_provider_from_auth` wrapper
  - moved `auth_env_telemetry` and `provider_auth` ownership to
  `codex-login`
  - moved `CodexErr` ownership to `codex-protocol::error`, plus
  `StreamOutput`, `bytes_to_string_smart`, and network policy helpers to
  protocol-owned modules
  - created `codex-response-debug-context` for
  `extract_response_debug_context`, `telemetry_transport_error_message`,
  and related response-debug plumbing instead of leaving that behavior in
  `core`
  - moved `FeedbackRequestTags`, `emit_feedback_request_tags`, and
  `emit_feedback_request_tags_with_auth_env` to `codex-feedback`
  - deferred removal of temporary re-exports and the mechanical import
  rewrites to a stacked follow-up PR so this PR stays reviewable
  
  ## Test moves
  - moved auth refresh coverage from `core/tests/suite/auth_refresh.rs` to
  `login/tests/suite/auth_refresh.rs`
  - moved text encoding coverage from
  `core/tests/suite/text_encoding_fix.rs` to
  `protocol/src/exec_output_tests.rs`
  - moved model info override coverage from
  `core/tests/suite/model_info_overrides.rs` to
  `models-manager/src/model_info_overrides_tests.rs`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-02 23:00:02 -07:00
  6fff9955f1
• Auto-trust cwd on thread start (#16492)

  - Persist trusted cwd state during thread/start when the resolved
  sandbox is elevated.
  - Add app-server coverage for trusted root resolution and confirm
  turn/start does not mutate trust.

  Ahmed Ibrahim · 2026-04-03 00:02:56 +00:00
  95e809c135
• Fix fork source display in /status (expose forked_from_id in app server) (#16596)

  Addresses #16560
  
  Problem: `/status` stopped showing the source thread id in forked TUI
  sessions after the app-server migration.
  
  Solution: Carry fork source ids through app-server v2 thread data and
  the TUI session adapter, and update TUI fixtures so `/status` matches
  the old TUI behavior.

  Eric Traut · 2026-04-02 14:05:29 -07:00
  9bb7f0a694
• [codex] Remove codex-core config type shim (#16529)

  ## Why
  
  This finishes the config-type move out of `codex-core` by removing the
  temporary compatibility shim in `codex_core::config::types`. Callers now
  depend on `codex-config` directly, which keeps these config model types
  owned by the config crate instead of re-expanding `codex-core` as a
  transitive API surface.
  
  ## What Changed
  
  - Removed the `codex-rs/core/src/config/types.rs` re-export shim and the
  `core::config::ApprovalsReviewer` re-export.
  - Updated `codex-core`, `codex-cli`, `codex-tui`, `codex-app-server`,
  `codex-mcp-server`, and `codex-linux-sandbox` call sites to import
  `codex_config::types` directly.
  - Added explicit `codex-config` dependencies to downstream crates that
  previously relied on the `codex-core` re-export.
  - Regenerated `codex-rs/core/config.schema.json` after updating the
  config docs path reference.

  Michael Bolin · 2026-04-02 01:19:44 -07:00
  c1d18ceb6f
• core: remove cross-crate re-exports from lib.rs (#16512)

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

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• core: use codex-mcp APIs directly (#16510)

  ## Why
  
  `codex-mcp` already owns the shared MCP API surface, including `auth`,
  `McpConfig`, `CODEX_APPS_MCP_SERVER_NAME`, and tool-name helpers in
  [`codex-rs/codex-mcp/src/mcp/mod.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/codex-mcp/src/mcp/mod.rs#L1-L35).
  Re-exporting that surface from `codex_core::mcp` gives downstream crates
  two import paths for the same API and hides the real crate dependency.
  
  This PR keeps `codex_core::mcp` focused on the local `McpManager`
  wrapper in
  [`codex-rs/core/src/mcp.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/core/src/mcp.rs#L13-L40)
  and makes consumers import shared MCP APIs from `codex_mcp` directly.
  
  ## What
  
  - Remove the `codex_mcp::mcp` re-export surface from `core/src/mcp.rs`.
  - Update `codex-core` internals plus `codex-app-server`, `codex-cli`,
  and `codex-tui` test code to import MCP APIs from `codex_mcp::mcp`
  directly.
  - Add explicit `codex-mcp` dependencies where those crates now use that
  API surface, and refresh `Cargo.lock`.
  
  ## Verification
  
  - `just bazel-lock-check`
  - `cargo test -p codex-core -p codex-cli -p codex-tui`
    - `codex-cli` passed.
  - `codex-core` still fails five unrelated config tests in
  `core/src/config/config_tests.rs` (`approvals_reviewer_*` and
  `smart_approvals_alias_*`).
  - A broader `cargo test -p codex-core -p codex-app-server -p codex-cli
  -p codex-tui` run previously hung in `codex-app-server` test
  `in_process_start_uses_requested_session_source_for_thread_start`.

  Michael Bolin · 2026-04-01 21:55:22 -07:00
  cc97982bbb
• fix: remove unused import (#16495)

  This lint violation slipped through because our Bazel CI setup currently
  doesn't cover `--tests` when doing `cargo clippy`. I am working on
  fixing this via:
  
  - https://github.com/openai/codex/pull/16450
  - https://github.com/openai/codex/pull/16460

  Michael Bolin · 2026-04-01 19:27:26 -07:00
  d7e5bc6a3a
• Extract MCP into codex-mcp crate (#15919)

  - Split MCP runtime/server code out of `codex-core` into the new
  `codex-mcp` crate. New/moved public structs/types include `McpConfig`,
  `McpConnectionManager`, `ToolInfo`, `ToolPluginProvenance`,
  `CodexAppsToolsCacheKey`, and the `McpManager` API
  (`codex_mcp::mcp::McpManager` plus the `codex_core::mcp::McpManager`
  wrapper/shim). New/moved functions include `with_codex_apps_mcp`,
  `configured_mcp_servers`, `effective_mcp_servers`,
  `collect_mcp_snapshot`, `collect_mcp_snapshot_from_manager`,
  `qualified_mcp_tool_name_prefix`, and the MCP auth/skill-dependency
  helpers. Why: this creates a focused MCP crate boundary and shrinks
  `codex-core` without forcing every consumer to migrate in the same PR.
  
  - Move MCP server config schema and persistence into `codex-config`.
  New/moved structs/enums include `AppToolApproval`,
  `McpServerToolConfig`, `McpServerConfig`, `RawMcpServerConfig`,
  `McpServerTransportConfig`, `McpServerDisabledReason`, and
  `codex_config::ConfigEditsBuilder`. New/moved functions include
  `load_global_mcp_servers` and
  `ConfigEditsBuilder::replace_mcp_servers`/`apply`. Why: MCP TOML
  parsing/editing is config ownership, and this keeps config
  validation/round-tripping (including per-tool approval overrides and
  inline bearer-token rejection) in the config crate instead of
  `codex-core`.
  
  - Rewire `codex-core`, app-server, and plugin call sites onto the new
  crates. Updated `Config::to_mcp_config(&self, plugins_manager)`,
  `codex-rs/core/src/mcp.rs`, `codex-rs/core/src/connectors.rs`,
  `codex-rs/core/src/codex.rs`,
  `CodexMessageProcessor::list_mcp_server_status_task`, and
  `utils/plugins/src/mcp_connector.rs` to build/pass the new MCP
  config/runtime types. Why: plugin-provided MCP servers still merge with
  user-configured servers, and runtime auth (`CodexAuth`) is threaded into
  `with_codex_apps_mcp` / `collect_mcp_snapshot` explicitly so `McpConfig`
  stays config-only.

  Ahmed Ibrahim · 2026-04-01 19:03:26 -07:00
  59b68f5519
• fix(guardian): make GuardianAssessmentEvent.action strongly typed (#16448)

  ## Description
  
  Previously the `action` field on `EventMsg::GuardianAssessment`, which
  describes what Guardian is reviewing, was typed as an arbitrary JSON
  blob. This PR cleans it up and defines a sum type representing all the
  various actions that Guardian can review.
  
  This is a breaking change (on purpose), which is fine because:
  - the Codex app / VSCE does not actually use `action` at the moment
  - the TUI code that consumes `action` is updated in this PR as well
  - rollout files that serialized old `EventMsg::GuardianAssessment` will
  just silently drop these guardian events
  - the contract is defined as unstable, so other clients have a fair
  warning :)
  
  This will make things much easier for followup Guardian work.
  
  ## Why
  
  The old guardian review payloads worked, but they pushed too much shape
  knowledge into downstream consumers. The TUI had custom JSON parsing
  logic for commands, patches, network requests, and MCP calls, and the
  app-server protocol was effectively just passing through an opaque blob.
  
  Typing this at the protocol boundary makes the contract clearer.

  Owen Lin · 2026-04-01 15:42:18 -07:00
  30f6786d62
• Refactor external auth to use a single trait (#16356)

  ## Summary
  - Replace the separate external auth enum and refresher trait with a
  single `ExternalAuth` trait in login auth flow
  - Move bearer token auth behind `BearerTokenRefresher` and update
  `AuthManager` and app-server wiring to use the generic external auth API

  Eric Traut · 2026-03-31 14:54:18 -06:00
  103acdfb06
• [codex-analytics] thread events (#15690)

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

  rhan-oai · 2026-03-31 12:16:44 -07:00
  e8de4ea953
• auth: let AuthManager own external bearer auth (#16287)

  ## Summary
  
  `AuthManager` and `UnauthorizedRecovery` already own token resolution
  and staged `401` recovery. The missing piece for provider auth was a
  bearer-only mode that still fit that design, instead of pushing a second
  auth abstraction into `codex-core`.
  
  This PR keeps the design centered on `AuthManager`: it teaches
  `codex-login` how to own external bearer auth directly so later provider
  work can keep calling `AuthManager.auth()` and `UnauthorizedRecovery`.
  
  ## Motivation
  
  This is the middle layer for #15189.
  
  The intended design is still:
  
  - `AuthManager` encapsulates token storage and refresh
  - `UnauthorizedRecovery` powers staged `401` recovery
  - all request tokens go through `AuthManager.auth()`
  
  This PR makes that possible for provider-backed bearer tokens by adding
  a bearer-only auth mode inside `AuthManager` instead of building
  parallel request-auth plumbing in `core`.
  
  ## What Changed
  
  - move `ModelProviderAuthInfo` into `codex-protocol` so `core` and
  `login` share one config shape
  - add `login/src/auth/external_bearer.rs`, which runs the configured
  command, caches the bearer token in memory, and refreshes it after `401`
  - add `AuthManager::external_bearer_only(...)` for provider-scoped
  request paths that should use command-backed bearer auth without
  mutating the shared OpenAI auth manager
  - add `AuthManager::shared_with_external_chatgpt_auth_refresher(...)`
  and rename the other `AuthManager` helpers that only apply to external
  ChatGPT auth so the ChatGPT-only path is explicit at the call site
  - keep external ChatGPT refresh behavior unchanged while ensuring
  bearer-only external auth never persists to `auth.json`
  
  ## Testing
  
  - `cargo test -p codex-login`
  - `cargo test -p codex-protocol`
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16287).
  * #16288
  * __->__ #16287

  Michael Bolin · 2026-03-31 01:26:17 -07:00
  0071968829
• auth: generalize external auth tokens for bearer-only sources (#16286)

  ## Summary
  
  `ExternalAuthRefresher` was still shaped around external ChatGPT auth:
  `ExternalAuthTokens` always implied ChatGPT account metadata even when a
  caller only needed a bearer token.
  
  This PR generalizes that contract so bearer-only sources are
  first-class, while keeping the existing ChatGPT paths strict anywhere we
  persist or rebuild ChatGPT auth state.
  
  ## Motivation
  
  This is the first step toward #15189.
  
  The follow-on provider-auth work needs one shared external-auth contract
  that can do both of these things:
  
  - resolve the current bearer token before a request is sent
  - return a refreshed bearer token after a `401`
  
  That should not require a second token result type just because there is
  no ChatGPT account metadata attached.
  
  ## What Changed
  
  - change `ExternalAuthTokens` to carry `access_token` plus optional
  `ExternalAuthChatgptMetadata`
  - add helper constructors for bearer-only tokens and ChatGPT-backed
  tokens
  - add `ExternalAuthRefresher::resolve()` with a default no-op
  implementation so refreshers can optionally provide the current token
  before a request is sent
  - keep ChatGPT-only persistence strict by continuing to require ChatGPT
  metadata anywhere the login layer seeds or reloads ChatGPT auth state
  - update the app-server bridge to construct the new token shape for
  external ChatGPT auth refreshes
  
  ## Testing
  
  - `cargo test -p codex-login`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16286).
  * #16288
  * #16287
  * __->__ #16286

  Michael Bolin · 2026-03-31 01:02:46 -07:00
  ea650a91b3
• Remove the codex-tui app-server originator workaround (#16116)

  ## Summary
  - remove the temporary `codex-tui` special-case when setting the default
  originator during app-server initialization

  Eric Traut · 2026-03-28 13:53:33 -06:00
  178d2b00b1
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

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

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• Remove the legacy TUI split (#15922)

  This is the part 1 of 2 PRs that will delete the `tui` /
  `tui_app_server` split. This part simply deletes the existing `tui`
  directory and marks the `tui_app_server` feature flag as removed. I left
  the `tui_app_server` feature flag in place for now so its presence
  doesn't result in an error. It is simply ignored.
  
  Part 2 will rename the `tui_app_server` directory `tui`. I did this as
  two parts to reduce visible code churn.

  Eric Traut · 2026-03-27 22:56:44 +00:00
  d65deec617
• Add ChatGPT device-code login to app server (#15525)

  ## Problem
  
  App-server clients could only initiate ChatGPT login through the browser
  callback flow, even though the shared login crate already supports
  device-code auth. That left VS Code, Codex App, and other app-server
  clients without a first-class way to use the existing device-code
  backend when browser redirects are brittle or when the client UX wants
  to own the login ceremony.
  
  ## Mental model
  
  This change adds a second ChatGPT login start path to app-server:
  clients can now call `account/login/start` with `type:
  "chatgptDeviceCode"`. App-server immediately returns a `loginId` plus
  the device-code UX payload (`verificationUrl` and `userCode`), then
  completes the login asynchronously in the background using the existing
  `codex_login` polling flow. Successful device-code login still resolves
  to ordinary `chatgpt` auth, and completion continues to flow through the
  existing `account/login/completed` and `account/updated` notifications.
  
  ## Non-goals
  
  This does not introduce a new auth mode, a new account shape, or a
  device-code eligibility discovery API. It also does not add automatic
  fallback to browser login in core; clients remain responsible for
  choosing when to request device code and whether to retry with a
  different UX if the backend/admin policy rejects it.
  
  ## Tradeoffs
  
  We intentionally keep `login_chatgpt_common` as a local validation
  helper instead of turning it into a capability probe. Device-code
  eligibility is checked by actually calling `request_device_code`, which
  means policy-disabled cases surface as an immediate request error rather
  than an async completion event. We also keep the active-login state
  machine minimal: browser and device-code logins share the same public
  cancel contract, but device-code cancellation is implemented with a
  local cancel token rather than a larger cross-crate refactor.
  
  ## Architecture
  
  The protocol grows a new `chatgptDeviceCode` request/response variant in
  app-server v2. On the server side, the new handler reuses the existing
  ChatGPT login precondition checks, calls `request_device_code`, returns
  the device-code payload, and then spawns a background task that waits on
  either cancellation or `complete_device_code_login`. On success, it
  reuses the existing auth reload and cloud-requirements refresh path
  before emitting `account/login/completed` success and `account/updated`.
  On failure or cancellation, it emits only `account/login/completed`
  failure. The existing `account/login/cancel { loginId }` contract
  remains unchanged and now works for both browser and device-code
  attempts.
  
  
  ## Tests
  
  Added protocol serialization coverage for the new request/response
  variant, plus app-server tests for device-code success, failure, cancel,
  and start-time rejection behavior. Existing browser ChatGPT login
  coverage remains in place to show that the callback-based flow is
  unchanged.

  daniel-oai · 2026-03-27 00:27:15 -07:00
  47a9e2e084
• chore: refactor network permissions to use explicit domain and unix socket rule maps (#15120)

  ## Summary
  
  This PR replaces the legacy network allow/deny list model with explicit
  rule maps for domains and unix sockets across managed requirements,
  permissions profiles, the network proxy config, and the app server
  protocol.
  
  Concretely, it:
  
  - introduces typed domain (`allow` / `deny`) and unix socket permission
  (`allow` / `none`) entries instead of separate `allowed_domains`,
  `denied_domains`, and `allow_unix_sockets` lists
  - updates config loading, managed requirements merging, and exec-policy
  overlays to read and upsert rule entries consistently
  - exposes the new shape through protocol/schema outputs, debug surfaces,
  and app-server config APIs
  - rejects the legacy list-based keys and updates docs/tests to reflect
  the new config format
  
  ## Why
  
  The previous representation split related network policy across multiple
  parallel lists, which made merging and overriding rules harder to reason
  about. Moving to explicit keyed permission maps gives us a single source
  of truth per host/socket entry, makes allow/deny precedence clearer, and
  gives protocol consumers access to the full rule state instead of
  derived projections only.
  
  ## Backward Compatibility
  
  ### Backward compatible
  
  - Managed requirements still accept the legacy
  `experimental_network.allowed_domains`,
  `experimental_network.denied_domains`, and
  `experimental_network.allow_unix_sockets` fields. They are normalized
  into the new canonical `domains` and `unix_sockets` maps internally.
  - App-server v2 still deserializes legacy `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` payloads, so older clients can
  continue reading managed network requirements.
  - App-server v2 responses still populate `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` as legacy compatibility views
  derived from the canonical maps.
  - `managed_allowed_domains_only` keeps the same behavior after
  normalization. Legacy managed allowlists still participate in the same
  enforcement path as canonical `domains` entries.
  
  ### Not backward compatible
  
  - Permissions profiles under `[permissions.<profile>.network]` no longer
  accept the legacy list-based keys. Those configs must use the canonical
  `[domains]` and `[unix_sockets]` tables instead of `allowed_domains`,
  `denied_domains`, or `allow_unix_sockets`.
  - Managed `experimental_network` config cannot mix canonical and legacy
  forms in the same block. For example, `domains` cannot be combined with
  `allowed_domains` or `denied_domains`, and `unix_sockets` cannot be
  combined with `allow_unix_sockets`.
  - The canonical format can express explicit `"none"` entries for unix
  sockets, but those entries do not round-trip through the legacy
  compatibility fields because the legacy fields only represent allow/deny
  lists.
  ## Testing
  `/target/debug/codex sandbox macos --log-denials /bin/zsh -c 'curl
  https://www.example.com' ` gives 200 with config
  ```
  [permissions.workspace.network.domains]
  "www.example.com" = "allow"
  ```
  and fails when set to deny: `curl: (56) CONNECT tunnel failed, response
  403`.
  
  Also tested backward compatibility path by verifying that adding the
  following to `/etc/codex/requirements.toml` works:
  ```
  [experimental_network]
  allowed_domains = ["www.example.com"]
  ```

  Celia Chen · 2026-03-27 06:17:59 +00:00
  dd30c8eedd
• permissions: remove macOS seatbelt extension profiles (#15918)

  ## Why
  
  `PermissionProfile` should only describe the per-command permissions we
  still want to grant dynamically. Keeping
  `MacOsSeatbeltProfileExtensions` in that surface forced extra macOS-only
  approval, protocol, schema, and TUI branches for a capability we no
  longer want to expose.
  
  ## What changed
  
  - Removed the macOS-specific permission-profile types from
  `codex-protocol`, the app-server v2 API, and the generated
  schema/TypeScript artifacts.
  - Deleted the core and sandboxing plumbing that threaded
  `MacOsSeatbeltProfileExtensions` through execution requests and seatbelt
  construction.
  - Simplified macOS seatbelt generation so it always includes the fixed
  read-only preferences allowlist instead of carrying a configurable
  profile extension.
  - Removed the macOS additional-permissions UI/docs/test coverage and
  deleted the obsolete macOS permission modules.
  - Tightened `request_permissions` intersection handling so explicitly
  empty requested read lists are preserved only when that field was
  actually granted, avoiding zero-grant responses being stored as active
  permissions.

  Michael Bolin · 2026-03-26 17:12:45 -07:00
  e6e2999209
• codex-tools: extract shared tool schema parsing (#15923)

  ## Why
  
  `parse_tool_input_schema` and the supporting `JsonSchema` model were
  living in `core/src/tools/spec.rs`, but they already serve callers
  outside `codex-core`.
  
  Keeping that shared schema parsing logic inside `codex-core` makes the
  crate boundary harder to reason about and works against the guidance in
  `AGENTS.md` to avoid growing `codex-core` when reusable code can live
  elsewhere.
  
  This change takes the first extraction step by moving the schema parsing
  primitive into its own crate while keeping the rest of the tool-spec
  assembly in `codex-core`.
  
  ## What changed
  
  - added a new `codex-tools` crate under `codex-rs/tools`
  - moved the shared tool input schema model and sanitizer/parser into
  `tools/src/json_schema.rs`
  - kept `tools/src/lib.rs` exports-only, with the module-level unit tests
  split into `json_schema_tests.rs`
  - updated `codex-core` to use `codex-tools::JsonSchema` and re-export
  `parse_tool_input_schema`
  - updated `codex-app-server` dynamic tool validation to depend on
  `codex-tools` directly instead of reaching through `codex-core`
  - wired the new crate into the Cargo workspace and Bazel build graph

  Michael Bolin · 2026-03-27 00:03:35 +00:00
  44d28f500f
• chore: remove skill metadata from command approval payloads (#15906)

  ## Why
  
  This is effectively a follow-up to
  [#15812](https://github.com/openai/codex/pull/15812). That change
  removed the special skill-script exec path, but `skill_metadata` was
  still being threaded through command-approval payloads even though the
  approval flow no longer uses it to render prompts or resolve decisions.
  
  Keeping it around added extra protocol, schema, and client surface area
  without changing behavior.
  
  Removing it keeps the command-approval contract smaller and avoids
  carrying a dead field through app-server, TUI, and MCP boundaries.
  
  ## What changed
  
  - removed `ExecApprovalRequestSkillMetadata` and the corresponding
  `skillMetadata` field from core approval events and the v2 app-server
  protocol
  - removed the generated JSON and TypeScript schema output for that field
  - updated app-server, MCP server, TUI, and TUI app-server approval
  plumbing to stop forwarding the field
  - cleaned up tests that previously constructed or asserted
  `skillMetadata`
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-test-client`
  - `cargo test -p codex-mcp-server`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-26 15:32:03 -07:00
  5906c6a658
• app-server: Split transport module (#15811)

  `transport.rs` is getting pretty big, split individual transport
  implementations into separate files.

  Ruslan Nigmatullin · 2026-03-26 13:01:35 -07:00
  9736fa5e3d
• fix: fix old system bubblewrap compatibility without falling back to vendored bwrap (#15693)

  Fixes #15283.
  
  ## Summary
  Older system bubblewrap builds reject `--argv0`, which makes our Linux
  sandbox fail before the helper can re-exec. This PR keeps using system
  `/usr/bin/bwrap` whenever it exists and only falls back to vendored
  bwrap when the system binary is missing. That matters on stricter
  AppArmor hosts, where the distro bwrap package also provides the policy
  setup needed for user namespaces.
  
  For old system bwrap, we avoid `--argv0` instead of switching binaries:
  - pass the sandbox helper a full-path `argv0`,
  - keep the existing `current_exe() + --argv0` path when the selected
  launcher supports it,
  - otherwise omit `--argv0` and re-exec through the helper's own
  `argv[0]` path, whose basename still dispatches as
  `codex-linux-sandbox`.
  
  Also updates the launcher/warning tests and docs so they match the new
  behavior: present-but-old system bwrap uses the compatibility path, and
  only absent system bwrap falls back to vendored.
  
  ### Validation
  
  1. Install Ubuntu 20.04 in a VM
  2. Compile codex and run without bubblewrap installed - see a warning
  about falling back to the vendored bwrap
  3. Install bwrap and verify version is 0.4.0 without `argv0` support
  4. run codex and use apply_patch tool without errors
  
  <img width="802" height="631" alt="Screenshot 2026-03-25 at 11 48 36 PM"
  src="https://github.com/user-attachments/assets/77248a29-aa38-4d7c-9833-496ec6a458b8"
  />
  <img width="807" height="634" alt="Screenshot 2026-03-25 at 11 47 32 PM"
  src="https://github.com/user-attachments/assets/5af8b850-a466-489b-95a6-455b76b5050f"
  />
  <img width="812" height="635" alt="Screenshot 2026-03-25 at 11 45 45 PM"
  src="https://github.com/user-attachments/assets/438074f0-8435-4274-a667-332efdd5cb57"
  />
  <img width="801" height="623" alt="Screenshot 2026-03-25 at 11 43 56 PM"
  src="https://github.com/user-attachments/assets/0dc8d3f5-e8cf-4218-b4b4-a4f7d9bf02e3"
  />
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  viyatb-oai · 2026-03-25 23:51:39 -07:00
  937cb5081d
• [mcp] Improve custom MCP elicitation (#15800)

  - [x] Support don't ask again for custom MCP tool calls.
  - [x] Don't run arc in yolo mode.
  - [x] Run arc for custom MCP tools in always allow mode.

  Matthew Zeng · 2026-03-26 01:02:37 +00:00
  78799c1bcf
• app-server: Organize app-server to allow more transports (#15810)

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

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

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

  pakrym-oai · 2026-03-25 16:14:36 -07:00
  8fa88fa8ca
• Avoid duplicate auth refreshes in getAuthStatus (#15798)

  I've seen several intermittent failures of
  `get_auth_status_returns_token_after_proactive_refresh_recovery` today.
  I investigated, and I found a couple of issues.
  
  First, `getAuthStatus(refreshToken=true)` could refresh twice in one
  request: once via `refresh_token_if_requested()` and again via the
  proactive refresh path inside `auth_manager.auth()`. In the
  permanent-failure case this produced an extra `/oauth/token` call and
  made the app-server auth tests flaky. Use `auth_cached()` after an
  explicit refresh request so the handler reuses the post-refresh auth
  state instead of immediately re-entering proactive refresh logic. Keep
  the existing proactive path for `refreshToken=false`.
  
  Second, serialize auth refresh attempts in `AuthManager` have a
  startup/request race. One proactive refresh could already be in flight
  while a `getAuthStatus(refreshToken=false)` request entered
  `auth().await`, causing a second `/oauth/token` call before the first
  failure or refresh result had been recorded. Guarding the refresh flow
  with a single async lock makes concurrent callers share one refresh
  result, which prevents duplicate refreshes and stabilizes the
  proactive-refresh auth tests.

  Eric Traut · 2026-03-25 16:03:53 -06:00
  2c67a27a71