602 Commits

• codex-tools: extract code mode tool spec adapters (#16132)

  ## Why
  
  The longer-term `codex-tools` migration is to move pure tool-definition
  and tool-spec plumbing out of `codex-core` while leaving session- and
  runtime-coupled orchestration behind.
  
  The remaining code-mode adapter layer in
  `core/src/tools/code_mode_description.rs` was a good next extraction
  seam because it only transformed `ToolSpec` values for code mode and
  already delegated the low-level description rendering to
  `codex-code-mode`.
  
  ## What Changed
  
  - added `codex-rs/tools/src/code_mode.rs` with
  `augment_tool_spec_for_code_mode()` and
  `tool_spec_to_code_mode_tool_definition()`
  - added focused unit coverage in `codex-rs/tools/src/code_mode_tests.rs`
  - rewired `core/src/tools/spec.rs` and `core/src/tools/code_mode/mod.rs`
  to use the extracted adapters from `codex-tools`
  - removed the old `core/src/tools/code_mode_description.rs` shim and its
  test file from `codex-core`
  - added the `codex-code-mode` dependency to `codex-tools`, updated
  `Cargo.lock`, and refreshed the `codex-tools` README to reflect the
  expanded boundary
  
  ## Test Plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-code-mode-adapters cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-code-mode-adapters cargo test -p
  codex-core --lib tools::code_mode::`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129

  Michael Bolin · 2026-03-28 15:32:35 -07:00
  2238c16a91
• 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
• codex-tools: extract dynamic tool adapters (#15944)

  ## Why
  
  `codex-tools` already owned the shared JSON schema parser and the MCP
  tool schema adapter, but `core/src/tools/spec.rs` still parsed dynamic
  tools directly.
  
  That left the tool-schema boundary split in two different ways:
  
  - MCP tools flowed through `codex-tools`, while dynamic tools were still
  parsed in `codex-core`
  - the extracted dynamic-tool path initially introduced a
  dynamic-specific parsed shape even though `codex-tools` already had very
  similar MCP adapter output
  
  This change finishes that extraction boundary in one step. `codex-core`
  still owns `ResponsesApiTool` assembly, but both MCP tools and dynamic
  tools now enter that layer through `codex-tools` using the same parsed
  tool-definition shape.
  
  ## What changed
  
  - added `tools/src/dynamic_tool.rs` and sibling
  `tools/src/dynamic_tool_tests.rs`
  - introduced `parse_dynamic_tool()` in `codex-tools` and switched
  `core/src/tools/spec.rs` to use it for dynamic tools
  - added `tools/src/parsed_tool_definition.rs` so both MCP and dynamic
  adapters return the same `ParsedToolDefinition`
  - updated `core/src/tools/spec.rs` to build `ResponsesApiTool` through a
  shared local adapter helper instead of separate MCP and dynamic assembly
  paths
  - expanded `core/src/tools/spec_tests.rs` so the dynamic-tool adapter
  test asserts the full converted `ResponsesApiTool`, including
  `defer_loading`
  - updated `codex-rs/tools/README.md` to reflect the shared parsed
  tool-definition boundary
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/15944).
  * #15953
  * __->__ #15944

  Michael Bolin · 2026-03-27 09:12:36 -07:00
  617475e54b
• Use codex-utils-template for sandbox mode prompts (#15998)
  jif-oai · 2026-03-27 14:50:36 +01:00
  2c85ca6842
• Use codex-utils-template for login error page (#16000)
  jif-oai · 2026-03-27 14:49:45 +01:00
  270b7655cd
• chore: drop useless stuff (#15876)
  jif-oai · 2026-03-27 09:41:47 +01:00
  2e849703cd
• codex-tools: extract MCP schema adapters (#15928)

  ## Why
  
  `codex-tools` already owns the shared tool input schema model and parser
  from the first extraction step, but `core/src/tools/spec.rs` still owned
  the MCP-specific adapter that normalizes `rmcp::model::Tool` schemas and
  wraps `structuredContent` into the call result output schema.
  
  Keeping that adapter in `codex-core` means the reusable MCP schema path
  is still split across crates, and the unit tests for that logic stay
  anchored in `codex-core` even though the runtime orchestration does not
  need to move yet.
  
  This change takes the next small step by moving the reusable MCP schema
  adapter into `codex-tools` while leaving `ResponsesApiTool` assembly in
  `codex-core`.
  
  ## What changed
  
  - added `tools/src/mcp_tool.rs` and sibling
  `tools/src/mcp_tool_tests.rs`
  - introduced `ParsedMcpTool`, `parse_mcp_tool()`, and
  `mcp_call_tool_result_output_schema()` in `codex-tools`
  - updated `core/src/tools/spec.rs` to consume parsed MCP tool parts from
  `codex-tools`
  - removed the now-redundant MCP schema unit tests from
  `core/src/tools/spec_tests.rs`
  - expanded `codex-rs/tools/README.md` to describe this second migration
  step
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`

  Michael Bolin · 2026-03-26 19:57:26 -07:00
  be5afc65d3
• 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: move bwrap config helpers into dedicated module (#15898)

  ## Summary
  - move the bwrap PATH lookup and warning helpers out of config/mod.rs
  - move the related tests into a dedicated bwrap_tests.rs file
  
  ## Validation
  - git diff --check
  - skipped heavier local tests per request
  
  Follow-up to #15791.

  viyatb-oai · 2026-03-26 15:15:59 -07:00
  b52abff279
• [codex] import token_data from codex-login directly (#15903)

  ## Why
  `token_data` is owned by `codex-login`, but `codex-core` was still
  re-exporting it. That let callers pull auth token types through
  `codex-core`, which keeps otherwise unrelated crates coupled to
  `codex-core` and makes `codex-core` more of a build-graph bottleneck.
  
  ## What changed
  - remove the `codex-core` re-export of `codex_login::token_data`
  - update the remaining `codex-core` internals that used
  `crate::token_data` to import `codex_login::token_data` directly
  - update downstream callers in `codex-rs/chatgpt`,
  `codex-rs/tui_app_server`, `codex-rs/app-server/tests/common`, and
  `codex-rs/core/tests` to import `codex_login::token_data` directly
  - add explicit `codex-login` workspace dependencies and refresh lock
  metadata for crates that now depend on it directly
  
  ## Validation
  - `cargo test -p codex-chatgpt --locked`
  - `just argument-comment-lint`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ## Notes
  - attempted `cargo test -p codex-core --locked` and `cargo test -p
  codex-core auth_refresh --locked`, but both ran out of disk while
  linking `codex-core` test binaries in the local environment

  Michael Bolin · 2026-03-26 13:34:02 -07:00
  b23789b770
• fix: box apply_patch test harness futures (#15835)

  ## Why
  
  `#[large_stack_test]` made the `apply_patch_cli` tests pass by giving
  them more stack, but it did not address why those tests needed the extra
  stack in the first place.
  
  The real problem is the async state built by the `apply_patch_cli`
  harness path. Those tests await three helper boundaries directly:
  harness construction, turn submission, and apply-patch output
  collection. If those helpers inline their full child futures, the test
  future grows to include the whole harness startup and request/response
  path.
  
  This change replaces the workaround from #12768 with the same basic
  approach used in #13429, but keeps the fix narrower: only the helper
  boundaries awaited directly by `apply_patch_cli` stay boxed.
  
  ## What Changed
  
  - removed `#[large_stack_test]` from
  `core/tests/suite/apply_patch_cli.rs`
  - restored ordinary `#[tokio::test(flavor = "multi_thread",
  worker_threads = 2)]` annotations in that suite
  - deleted the now-unused `codex-test-macros` crate and removed its
  workspace wiring
  - boxed only the three helper boundaries that the suite awaits directly:
    - `apply_patch_harness_with(...)`
    - `TestCodexHarness::submit(...)`
    - `TestCodexHarness::apply_patch_output(...)`
  - added comments at those boxed boundaries explaining why they remain
  boxed
  
  ## Testing
  
  - `cargo test -p codex-core --test all suite::apply_patch_cli --
  --nocapture`
  
  ## References
  
  - #12768
  - #13429

  Michael Bolin · 2026-03-26 17:32:04 +00:00
  e36ebaa3da
• chore: drop artifacts lib (#15864)
  jif-oai · 2026-03-26 15:28:59 +01:00
  6dcac41d53
• feat: exec-server prep for unified exec (#15691)

  This PR partially rebase `unified_exec` on the `exec-server` and adapt
  the `exec-server` accordingly.
  
  ## What changed in `exec-server`
  
  1. Replaced the old "broadcast-driven; process-global" event model with
  process-scoped session events. The goal is to be able to have dedicated
  handler for each process.
  2. Add to protocol contract to support explicit lifecycle status and
  stream ordering:
  - `WriteResponse` now returns `WriteStatus` (Accepted, UnknownProcess,
  StdinClosed, Starting) instead of a bool.
    - Added seq fields to output/exited notifications.
    - Added terminal process/closed notification.
  3. Demultiplexed remote notifications into per-process channels. Same as
  for the event sys
  4. Local and remote backends now both implement ExecBackend.
  5. Local backend wraps internal process ID/operations into per-process
  ExecProcess objects.
  6. Remote backend registers a session channel before launch and
  unregisters on failed launch.
  
  ## What changed in `unified_exec`
  
  1. Added unified process-state model and backend-neutral process
  wrapper. This will probably disappear in the future, but it makes it
  easier to keep the work flowing on both side.
  - `UnifiedExecProcess` now handles both local PTY sessions and remote
  exec-server processes through a shared `ProcessHandle`.
  - Added `ProcessState` to track has_exited, exit_code, and terminal
  failure message consistently across backends.
  2. Routed write and lifecycle handling through process-level methods.
  
  ## Some rationals
  
  1. The change centralizes execution transport in exec-server while
  preserving policy and orchestration ownership in core, avoiding
  duplicated launch approval logic. This comes from internal discussion.
  2. Session-scoped events remove coupling/cross-talk between processes
  and make stream ordering and terminal state explicit (seq, closed,
  failed).
  3. The failure-path surfacing (remote launch failures, write failures,
  transport disconnects) makes command tool output and cleanup behavior
  deterministic
  
  ## Follow-ups:
  * Unify the concept of thread ID behind an obfuscated struct
  * FD handling
  * Full zsh-fork compatibility
  * Full network sandboxing compatibility
  * Handle ws disconnection

  jif-oai · 2026-03-26 15:22:34 +01:00
  7dac332c93
• feat: drop artifact tool and feature (#15851)
  jif-oai · 2026-03-26 13:21:24 +01:00
  b00a05c785
• feat: replace askama by custom lib (#15784)

  Finalise the drop of `askama` to use our internal lib instead

  jif-oai · 2026-03-26 10:33:25 +01:00
  7ef3cfe63e
• 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
• 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
• Extract codex-core-skills crate (#15749)

  ## Summary
  - move skill loading and management into codex-core-skills
  - leave codex-core with the thin integration layer and shared wiring
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 12:57:42 -07:00
  9dbe098349
• feat: add websocket auth for app-server (#14847)

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

  viyatb-oai · 2026-03-25 12:35:57 -07:00
  6124564297
• Extract codex-analytics crate (#15748)

  ## Summary
  - move the analytics events client into codex-analytics
  - update codex-core and app-server callsites to use the new crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 11:08:05 -07:00
  d273efc0f3
• Extract codex-plugin crate (#15747)

  ## Summary
  - extract plugin identifiers and load-outcome types into codex-plugin
  - update codex-core to consume the new plugin crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 11:07:31 -07:00
  2bb1027e37
• Extract codex-utils-plugins crate (#15746)

  ## Summary
  - extract shared plugin path and manifest helpers into
  codex-utils-plugins
  - update codex-core to consume the utility crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 11:05:35 -07:00
  ad74543a6f
• Extract codex-instructions crate (#15744)

  ## Summary
  - extract instruction fragment and user-instruction types into
  codex-instructions
  - update codex-core to consume the new crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 10:43:49 -07:00
  fba3c79885
• feat: rendering library v1 (#15778)

  The goal will be to replace askama

  jif-oai · 2026-03-25 16:07:04 +00:00
  f190a95a4f
• Extract rollout into its own crate (#15548)
  Ahmed Ibrahim · 2026-03-24 18:10:53 -07:00
  2e03d8b4d2
• Move string truncation helpers into codex-utils-string (#15572)

  - move the shared byte-based middle truncation logic from `core` into
  `codex-utils-string`
  - keep token-specific truncation in `codex-core` so rollout can reuse
  the shared helper in the next stacked PR
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-24 15:45:40 -07:00
  062fa7a2bb
• Move git utilities into a dedicated crate (#15564)

  - create `codex-git-utils` and move the shared git helpers into it with
  file moves preserved for diff readability
  - move the `GitInfo` helpers out of `core` so stacked rollout work can
  depend on the shared crate without carrying its own git info module
  
  ---------
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-24 13:26:23 -07:00
  0f957a93cd
• Finish moving codex exec to app-server (#15424)

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

  Eric Traut · 2026-03-24 08:51:32 -06:00
  45f68843b8
• Move sandbox policy transforms into codex-sandboxing (#15599)

  ## Summary
  - move the pure sandbox policy transform helpers from `codex-core` into
  `codex-sandboxing`
  - move the corresponding unit tests with the extracted implementation
  - update `core` and `app-server` callers to import the moved APIs
  directly, without re-exports or proxy methods
  
  ## Testing
  - cargo test -p codex-sandboxing
  - cargo test -p codex-core sandboxing
  - cargo test -p codex-app-server --lib
  - just fix -p codex-sandboxing
  - just fix -p codex-core
  - just fix -p codex-app-server
  - just fmt
  - just argument-comment-lint

  pakrym-oai · 2026-03-23 22:22:44 -07:00
  9deb8ce3fc
• Move macOS sandbox builders into codex-sandboxing (#15593)

  ## Summary
  - move macOS permission merging/intersection logic and tests from
  `codex-core` into `codex-sandboxing`
  - move seatbelt policy builders, permissions logic, SBPL assets, and
  their tests into `codex-sandboxing`
  - keep `codex-core` owning only the seatbelt spawn wrapper and switch
  call sites to import the moved APIs directly
  
  ## Notes
  - no re-exports added
  - moved the seatbelt tests with the implementation so internal helpers
  could stay private
  - local verification is still finishing while this PR is open

  pakrym-oai · 2026-03-23 21:26:35 -07:00
  431af0807c
• Extract landlock helpers into codex-sandboxing (#15592)

  ## Summary
  - add a new `codex-sandboxing` crate for sandboxing extraction work
  - move the pure Linux sandbox argv builders and their unit tests out of
  `codex-core`
  - keep `core::landlock` as the spawn wrapper and update direct callers
  to use `codex_sandboxing::landlock`
  
  ## Testing
  - `cargo test -p codex-sandboxing`
  - `cargo test -p codex-core landlock`
  - `cargo test -p codex-cli debug_sandbox`
  - `just argument-comment-lint`
  
  ## Notes
  - this is step 1 of the move plan aimed at minimizing per-PR diffs
  - no re-exports or no-op proxy methods were added

  pakrym-oai · 2026-03-23 20:56:15 -07:00
  2227248cd6
• fix: cargo deny (#15520)
  jif-oai · 2026-03-23 16:48:54 +00:00
  2887f16cb9
• Code mode on v8 (#15276)

  Moves Code Mode to a new crate with no dependencies on codex. This
  create encodes the code mode semantics that we want for lifetime,
  mounting, tool calling.
  
  The model-facing surface is mostly unchanged. `exec` still runs raw
  JavaScript, `wait` still resumes or terminates a `cell_id`, nested tools
  are still available through `tools.*`, and helpers like `text`, `image`,
  `store`, `load`, `notify`, `yield_control`, and `exit` still exist.
  
  The major change is underneath that surface:
  
  - Old code mode was an external Node runtime.
  - New code mode is an in-process V8 runtime embedded directly in Rust.
  - Old code mode managed cells inside a long-lived Node runner process.
  - New code mode manages cells in Rust, with one V8 runtime thread per
  active `exec`.
  - Old code mode used JSON protocol messages over child stdin/stdout plus
  Node worker-thread messages.
  - New code mode uses Rust channels and direct V8 callbacks/events.
  
  This PR also fixes the two migration regressions that fell out of that
  substrate change:
  
  - `wait { terminate: true }` now waits for the V8 runtime to actually
  stop before reporting termination.
  - synchronous top-level `exit()` now succeeds again instead of surfacing
  as a script error.
  
  ---
  
  - `core/src/tools/code_mode/*` is now mostly an adapter layer for the
  public `exec` / `wait` tools.
  - `code-mode/src/service.rs` owns cell sessions and async control flow
  in Rust.
  - `code-mode/src/runtime/*.rs` owns the embedded V8 isolate and
  JavaScript execution.
  - each `exec` spawns a dedicated runtime thread plus a Rust
  session-control task.
  - helper globals are installed directly into the V8 context instead of
  being injected through a source prelude.
  - helper modules like `tools.js` and `@openai/code_mode` are synthesized
  through V8 module resolution callbacks in Rust.
  
  ---
  
  Also added a benchmark for showing the speed of init and use of a code
  mode env:
  ```
  $ cargo bench -p codex-code-mode --bench exec_overhead -- --samples 30 --warm-iterations 25 --tool-counts 0,32,128
  Finished [`bench` profile [optimized]](https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles) target(s) in 0.18s
       Running benches/exec_overhead.rs (target/release/deps/exec_overhead-008c440d800545ae)
  exec_overhead: samples=30, warm_iterations=25, tool_counts=[0, 32, 128]
  scenario       tools samples    warmups      iters      mean/exec       p95/exec       rssΔ p50       rssΔ max
  cold_exec          0      30          0          1         1.13ms         1.20ms        8.05MiB        8.06MiB
  warm_exec          0      30          1         25       473.43us       512.49us      912.00KiB        1.33MiB
  cold_exec         32      30          0          1         1.03ms         1.15ms        8.08MiB        8.11MiB
  warm_exec         32      30          1         25       509.73us       545.76us      960.00KiB        1.30MiB
  cold_exec        128      30          0          1         1.14ms         1.19ms        8.30MiB        8.34MiB
  warm_exec        128      30          1         25       575.08us       591.03us      736.00KiB      864.00KiB
  memory uses a fresh-process max RSS delta for each scenario
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Channing Conger · 2026-03-20 23:36:58 -07:00
  e4eedd6170
• Add realtime transcript notification in v2 (#15344)

  - emit a typed `thread/realtime/transcriptUpdated` notification from
  live realtime transcript deltas
  - expose that notification as flat `threadId`, `role`, and `text` fields
  instead of a nested transcript array
  - continue forwarding raw `handoff_request` items on
  `thread/realtime/itemAdded`, including the accumulated
  `active_transcript`
  - update app-server docs, tests, and generated protocol schema artifacts
  to match the delta-based payloads
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-20 15:30:48 -07:00
  3431f01776
• Add v8-poc consumer of our new built v8 (#15203)

  This adds a dummy v8-poc project that in Cargo links against our
  prebuilt binaries and the ones provided by rusty_v8 for non musl
  platforms. This demonstrates that we can successfully link and use v8 on
  all platforms that we want to target.
  
  In bazel things are slightly more complicated. Since the libraries as
  published have libc++ linked in already we end up with a lot of double
  linked symbols if we try to use them in bazel land. Instead we fall back
  to building rusty_v8 and v8 from source (cached of course) on the
  platforms we ship to.
  
  There is likely some compatibility drift in the windows bazel builder
  that we'll need to reconcile before we can re-enable them. I'm happy to
  be on the hook to unwind that.

  Channing Conger · 2026-03-20 12:08:25 -07:00
  1350477150
• Bump aws-lc-rs (#15337)

  Bump our dep.
  
  RUSTSEC-2026-0048
  Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048

  Channing Conger · 2026-03-20 18:59:13 +00:00
  a941d8439d
• Add remote env CI matrix and integration test (#14869)

  `CODEX_TEST_REMOTE_ENV` will make `test_codex` start the executor
  "remotely" (inside a docker container) turning any integration test into
  remote test.

  pakrym-oai · 2026-03-20 08:02:50 -07:00
  ba85a58039
• Initial plugins TUI menu - list and read only. tui + tui_app_server (#15215)

  ### Preliminary /plugins TUI menu
  - Adds a preliminary /plugins menu flow in both tui and tui_app_server.
  - Fetches plugin list data asynchronously and shows loading/error/cached
  states.
    - Limits this first pass to the curated ChatGPT marketplace.
    - Shows available plugins with installed/status metadata.
  - Supports in-menu search over plugin display name, plugin id, plugin
  name, and marketplace label.
  - Opens a plugin detail view on selection, including summaries for
  Skills, Apps, and MCP Servers, with back navigation.
  
  ### Testing
    - Launch codex-cli with plugins enabled (`--enable plugins`).
    - Run /plugins and verify:
        - loading state appears first
        - plugin list is shown
        - search filters results
  - selecting a plugin opens detail view, with a list of
  skills/connectors/MCP servers for the plugin
        - back action returns to the list.
  - Verify disabled behavior by running /plugins without plugins enabled
  (shows “Plugins are disabled” message).
  - Launch with `--enable tui_app_server` (and plugins enabled) and repeat
  the same /plugins flow; behavior should match.

  canvrno-oai · 2026-03-19 21:28:33 -07:00
  f7201e5a9f
• Split features into codex-features crate (#15253)

  - Split the feature system into a new `codex-features` crate.
  - Cut `codex-core` and workspace consumers over to the new config and
  warning APIs.
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-19 20:12:07 -07:00
  2e22885e79
• Move auth code into login crate (#15150)

  - Move the auth implementation and token data into codex-login.
  - Keep codex-core re-exporting that surface from codex-login for
  existing callers.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-19 18:58:17 -07:00
  2aa4873802
• Refactor ExecServer filesystem split between local and remote (#15232)

  For each feature we have:
  1. Trait exposed on environment
  2. **Local Implementation** of the trait
  3. Remote implementation that uses the client to proxy via network
  4. Handler implementation that handles PRC requests and calls into
  **Local Implementation**

  pakrym-oai · 2026-03-19 17:08:04 -07:00
  403b397e4e
• Move terminal module to terminal-detection crate (#15216)

  - Move core/src/terminal.rs and its tests into a standalone
  terminal-detection workspace crate.
  - Update direct consumers to depend on codex-terminal-detection and
  import terminal APIs directly.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-19 14:08:04 -07:00
  7eb19e5319
• Add exec-server exec RPC implementation (#15090)

  Stacked PR 2/3, based on the stub PR.
  
  Adds the exec RPC implementation and process/event flow in exec-server
  only.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-03-19 19:00:36 +00:00
  1d210f639e
• [hooks] use a user message > developer message for prompt continuation (#14867)

  ## Summary
  
  Persist Stop-hook continuation prompts as `user` messages instead of
  hidden `developer` messages + some requested integration tests
  
  This is a followup to @pakrym 's comment in
  https://github.com/openai/codex/pull/14532 to make sure stop-block
  continuation prompts match training for turn loops
  
  - Stop continuation now writes `<hook_prompt hook_run_id="...">stop
  hook's user prompt<hook_prompt>`
  - Introduces quick-xml dependency, though we already indirectly depended
  on it anyway via syntect
  - This PR only has about 500 lines of actual logic changes, the rest is
  tests/schema
  
  ## Testing
  
  Example run (with a sessionstart hook and 3 stop hooks) - this shows
  context added by session start, then two stop hooks sending their own
  additional prompts in a new turn. The model responds with a single
  message addressing both. Then when that turn ends, the hooks detect that
  they just ran using `stop_hook_active` and decide not to infinite loop
  
  test files for this (unzip, move codex -> .codex):
  [codex.zip](https://github.com/user-attachments/files/26075806/codex.zip)
  
  ```
  › cats
  
  
  • Running SessionStart hook: lighting the observatory
  
  SessionStart hook (completed)
    warning: Hi, I'm a session start hook for wizard-tower (startup).
    hook context: A wimboltine stonpet is an exotic cuisine from hyperspace
  
  • Cats are tiny zen wizards, my friend: equal parts nap, mystery, and chaos. If you want, we can talk
    cat facts, cat breeds, cat names, or build something cat-themed in this repo.
  
  • Running Stop hook: checking the tower wards
  
  • Running Stop hook: sacking the guards
  
  • Running Stop hook: hiring the guards
  
  Stop hook (completed)
    warning: Wizard Tower Stop hook reviewed the completed reply (177 chars).
  
  Stop hook (blocked)
    warning: Wizard Tower Stop hook continuing conversation
    feedback: cook the stonpet
  
  Stop hook (blocked)
    warning: Wizard Tower Stop hook continuing conversation
    feedback: eat the cooked stonpet
  
  • Stonpet’s cooked, aloha style: flash-seared over a blue quasiflame, glazed with nebula salt, and
    rested until the hyperspace juices settle.
  
    Now we eat with gratitude, my friend. One mindful bite in, and the flavor is pure cosmic surf:
    smoky, bright, and totally out of this dimension.
  
  • Running Stop hook: checking the tower wards
  
  • Running Stop hook: sacking the guards
  
  • Running Stop hook: hiring the guards
  
  Stop hook (completed)
    warning: Wizard Tower Stop hook reviewed the completed reply (285 chars).
  
  Stop hook (completed)
    warning: Wizard Tower Stop hook saw a second pass and stayed calm to avoid a loop.
  
  Stop hook (completed)
    warning: Wizard Tower Stop hook saw a second pass and stayed calm to avoid a loop.
  ```

  Andrei Eternal · 2026-03-19 10:53:08 -07:00
  267499bed8
• Move environment abstraction into exec server (#15125)

  The idea is that codex-exec exposes an Environment struct with services
  on it. Each of those is a trait.
  
  Depending on construction parameters passed to Environment they are
  either backed by local or remote server but core doesn't see these
  differences.

  pakrym-oai · 2026-03-19 08:31:14 -07:00
  dee03da508
• feat: add graph representation of agent network (#15056)

  Add a representation of the agent graph. This is now used for:
  * Cascade close agents (when I close a parent, it close the kids)
  * Cascade resume (oposite)
  
  Later, this will also be used for post-compaction stuffing of the
  context
  
  Direct fix for: https://github.com/openai/codex/issues/14458

  jif-oai · 2026-03-19 10:21:25 +00:00
  70cdb17703
• feat(core, tracing): create turn spans over websockets (#14632)

  ## Description
  
  Dependent on:
  - [responsesapi] https://github.com/openai/openai/pull/760991 
  - [codex-backend] https://github.com/openai/openai/pull/760985
  
  `codex app-server -> codex-backend -> responsesapi` now reuses a
  persistent websocket connection across many turns. This PR updates
  tracing when using websockets so that each `response.create` websocket
  request propagates the current tracing context, so we can get a holistic
  end-to-end trace for each turn.
  
  Tracing is propagated via special keys (`ws_request_header_traceparent`,
  `ws_request_header_tracestate`) set in the `client_metadata` param in
  Responses API.
  
  Currently tracing on websockets is a bit broken because we only set
  tracing context on ws connection time, so it's detached from a
  `turn/start` request.

  Owen Lin · 2026-03-19 03:41:06 +00:00
  20f2a216df
• Remove stdio transport from exec server (#15119)

  Summary
  - delete the deprecated stdio transport plumbing from the exec server
  stack
  - add a basic `exec_server()` harness plus test utilities to start a
  server, send requests, and await events
  - refresh exec-server dependencies, configs, and documentation to
  reflect the new flow
  
  Testing
  - Not run (not requested)
  
  ---------
  
  Co-authored-by: starr-openai <starr@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  pakrym-oai · 2026-03-19 01:00:35 +00:00
  903660edba