162 Commits

• feat: wire fork to codex cli (#8994)

  ## Summary
  - add `codex fork` subcommand and `/fork` slash command mirroring resume
  - extend session picker to support fork/resume actions with dynamic
  labels in tui/tui2
  - wire fork selection flow through tui bootstraps and add fork-related
  tests

  Anton Panasenko · 2026-01-12 10:09:11 -08:00
  4223948cf5
• Add static mcp callback uri support (#8971)

  Currently the callback URI for MCP authentication is dynamically
  generated. More specifically, the callback URI is dynamic because the
  port part of it is randomly chosen by the OS. This is not ideal as
  callback URIs are recommended to be static and many authorization
  servers do not support dynamic callback URIs.
  
  This PR fixes that issue by exposing a new config option named
  `mcp_oauth_callback_port`. When it is set, the callback URI is
  constructed using this port rather than a random one chosen by the OS,
  thereby making callback URI static.
  
  Related issue: https://github.com/openai/codex/issues/8827

  WhammyLeaf · 2026-01-12 16:57:04 +00:00
  d5562983d9
• feat: add support for building with Bazel (#8875)

  This PR configures Codex CLI so it can be built with
  [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
  includes configuration so that remote builds can be done using
  [BuildBuddy](https://www.buildbuddy.io).
  
  If you are familiar with Bazel, things should work as you expect, e.g.,
  run `bazel test //... --keep-going` to run all the tests in the repo,
  but we have also added some new aliases in the `justfile` for
  convenience:
  
  - `just bazel-test` to run tests locally
  - `just bazel-remote-test` to run tests remotely (currently, the remote
  build is for x86_64 Linux regardless of your host platform). Note we are
  currently seeing the following test failures in the remote build, so we
  still need to figure out what is happening here:
  
  ```
  failures:
      suite::compact::manual_compact_twice_preserves_latest_user_messages
      suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
      suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
  ```
  
  - `just build-for-release` to build release binaries for all
  platforms/architectures remotely
  
  To setup remote execution:
  - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
  employees should also request org access at
  https://openai.buildbuddy.io/join/ with their `@openai.com` email
  address.)
  - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
  `~/.bazelrc` (add the line `build
  --remote_header=x-buildbuddy-api-key=YOUR_KEY`)
  - Use `--config=remote` in your `bazel` invocations (or add `common
  --config=remote` to your `~/.bazelrc`, or use the `just` commands)
  
  ## CI
  
  In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
  uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
  (we are working on supporting Windows, but that is not ready yet). Note
  that the failures we are seeing in `just bazel-remote-test` do not occur
  on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
  is green right now.
  
  The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
  that macOS CI jobs build _remotely_ on Linux hosts (using the
  `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
  root `BUILD.bazel`) using cross-compilation to build the macOS
  artifacts. Then these artifacts are downloaded locally to GitHub's macOS
  runner so the tests can be executed natively. This is the relevant
  config that enables this:
  
  ```
  common:macos --config=remote
  common:macos --strategy=remote
  common:macos --strategy=TestRunner=darwin-sandbox,local
  ```
  
  Because of the remote caching benefits we get from BuildBuddy, these new
  CI jobs can be extremely fast! For example, consider these two jobs that
  ran all the tests on Linux x86_64:
  
  - Bazel 1m37s
  https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
  - Cargo 9m20s
  https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
  
  For now, we will continue to run both the Bazel and Cargo jobs for PRs,
  but once we add support for Windows and running Clippy, we should be
  able to cutover to using Bazel exclusively for PRs, which should still
  speed things up considerably. We will probably continue to run the Cargo
  jobs post-merge for commits that land on `main` as a sanity check.
  
  Release builds will also continue to be done by Cargo for now.
  
  Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
  Earlier attempt to add support for Buck2, now abandoned:
  https://github.com/openai/codex/pull/8504
  
  ---------
  
  Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9
• [device-auth] When headless environment is detected, show device login flow instead. (#8756)

  When headless environment is detected, show device login flow instead.

  Matthew Zeng · 2026-01-08 21:48:30 -08:00
  24d6e0114f
• fix: remove existing process hardening from Codex CLI (#8951)

  As explained in https://github.com/openai/codex/issues/8945 and
  https://github.com/openai/codex/issues/8472, there are legitimate cases
  where users expect processes spawned by Codex to inherit environment
  variables such as `LD_LIBRARY_PATH` and `DYLD_LIBRARY_PATH`, where
  failing to do so can cause significant performance issues.
  
  This PR removes the use of
  `codex_process_hardening::pre_main_hardening()` in Codex CLI (which was
  added not in response to a known security issue, but because it seemed
  like a prudent thing to do from a security perspective:
  https://github.com/openai/codex/pull/4521), but we will continue to use
  it in `codex-responses-api-proxy`. At some point, we probably want to
  introduce a slightly different version of
  `codex_process_hardening::pre_main_hardening()` in Codex CLI that
  excludes said environment variables from the Codex process itself, but
  continues to propagate them to subprocesses.

  Michael Bolin · 2026-01-08 21:19:34 -08:00
  d3ff668f68
• Immutable CodexAuth (#8857)

  Historically we started with a CodexAuth that knew how to refresh it's
  own tokens and then added AuthManager that did a different kind of
  refresh (re-reading from disk).
  
  I don't think it makes sense for both `CodexAuth` and `AuthManager` to
  be mutable and contain behaviors.
  
  Move all refresh logic into `AuthManager` and keep `CodexAuth` as a data
  object.

  pakrym-oai · 2026-01-08 11:43:56 -08:00
  634764ece9
• chore: unify conversation with thread name (#8830)

  Done and verified by Codex + refactor feature of RustRover

  jif-oai · 2026-01-07 17:04:53 +00:00
  116059c3a0
• fix: stop honoring CODEX_MANAGED_CONFIG_PATH environment variable in production (#8762)
  Michael Bolin · 2026-01-06 07:10:27 -08:00
  7ecd0dc9b3
• feat: add justification arg to prefix_rule() in *.rules (#8751)

  Adds an optional `justification` parameter to the `prefix_rule()`
  execpolicy DSL so policy authors can attach human-readable rationale to
  a rule. That justification is propagated through parsing/matching and
  can be surfaced to the model (or approval UI) when a command is blocked
  or requires approval.
  
  When a command is rejected (or gated behind approval) due to policy, a
  generic message makes it hard for the model/user to understand what went
  wrong and what to do instead. Allowing policy authors to supply a short
  justification improves debuggability and helps guide the model toward
  compliant alternatives.
  
  Example:
  
  ```python
  prefix_rule(
      pattern = ["git", "push"],
      decision = "forbidden",
      justification = "pushing is blocked in this repo",
  )
  ```
  
  If Codex tried to run `git push origin main`, now the failure would
  include:
  
  ```
  `git push origin main` rejected: pushing is blocked in this repo
  ```
  
  whereas previously, all it was told was:
  
  ```
  execpolicy forbids this command
  ```

  Michael Bolin · 2026-01-05 21:24:48 +00:00
  cafb07fe6e
• feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496)

  This PR introduces a `codex-utils-cargo-bin` utility crate that
  wraps/replaces our use of `assert_cmd::Command` and
  `escargot::CargoBuild`.
  
  As you can infer from the introduction of `buck_project_root()` in this
  PR, I am attempting to make it possible to build Codex under
  [Buck2](https://buck2.build) as well as `cargo`. With Buck2, I hope to
  achieve faster incremental local builds (largely due to Buck2's
  [dice](https://buck2.build/docs/insights_and_knowledge/modern_dice/)
  build strategy, as well as benefits from its local build daemon) as well
  as faster CI builds if we invest in remote execution and caching.
  
  See
  https://buck2.build/docs/getting_started/what_is_buck2/#why-use-buck2-key-advantages
  for more details about the performance advantages of Buck2.
  
  Buck2 enforces stronger requirements in terms of build and test
  isolation. It discourages assumptions about absolute paths (which is key
  to enabling remote execution). Because the `CARGO_BIN_EXE_*` environment
  variables that Cargo provides are absolute paths (which
  `assert_cmd::Command` reads), this is a problem for Buck2, which is why
  we need this `codex-utils-cargo-bin` utility.
  
  My WIP-Buck2 setup sets the `CARGO_BIN_EXE_*` environment variables
  passed to a `rust_test()` build rule as relative paths.
  `codex-utils-cargo-bin` will resolve these values to absolute paths,
  when necessary.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8496).
  * #8498
  * __->__ #8496

  Michael Bolin · 2025-12-23 19:29:32 -08:00
  e61bae12e3
• Chore: remove rmcp feature and exp flag usages (#8087)

  ### Summary
  With codesigning on Mac, Windows and Linux, we should be able to safely
  remove `features.rmcp_client` and `use_experimental_use_rmcp_client`
  check from the codebase now.

  Shijie Rao · 2025-12-20 14:18:00 -08:00
  987dd7fde3
• chore: enusre the logic that creates ConfigLayerStack has access to cwd (#8353)

  `load_config_layers_state()` should load config from a
  `.codex/config.toml` in any folder between the `cwd` for a thread and
  the project root. Though in order to do that,
  `load_config_layers_state()` needs to know what the `cwd` is, so this PR
  does the work to thread the `cwd` through for existing callsites.
  
  A notable exception is the `/config` endpoint in app server for which a
  `cwd` is not guaranteed to be associated with the query, so the `cwd`
  param is `Option<AbsolutePathBuf>` to account for this case.
  
  The logic to make use of the `cwd` will be done in a follow-up PR.

  Michael Bolin · 2025-12-19 20:11:27 -08:00
  a6974087e5
• feat: support allowed_sandbox_modes in requirements.toml (#8298)

  This adds support for `allowed_sandbox_modes` in `requirements.toml` and
  provides legacy support for constraining sandbox modes in
  `managed_config.toml`. This is converted to `Constrained<SandboxPolicy>`
  in `ConfigRequirements` and applied to `Config` such that constraints
  are enforced throughout the harness.
  
  Note that, because `managed_config.toml` is deprecated, we do not add
  support for the new `external-sandbox` variant recently introduced in
  https://github.com/openai/codex/pull/8290. As noted, that variant is not
  supported in `config.toml` today, but can be configured programmatically
  via app server.

  Michael Bolin · 2025-12-19 21:09:20 +00:00
  dc61fc5f50
• chore: cleanup Config instantiation codepaths (#8226)

  This PR does various types of cleanup before I can proceed with more
  ambitious changes to config loading.
  
  First, I noticed duplicated code across these two methods:
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L314-L324
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L334-L344
  
  This has now been consolidated in
  `load_config_as_toml_with_cli_overrides()`.
  
  Further, I noticed that `Config::load_with_cli_overrides()` took two
  similar arguments:
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L308-L311
  
  The difference between `cli_overrides` and `overrides` was not
  immediately obvious to me. At first glance, it appears that one should
  be able to be expressed in terms of the other, but it turns out that
  some fields of `ConfigOverrides` (such as `cwd` and
  `codex_linux_sandbox_exe`) are, by design, not configurable via a
  `.toml` file or a command-line `--config` flag.
  
  That said, I discovered that many callers of
  `Config::load_with_cli_overrides()` were passing
  `ConfigOverrides::default()` for `overrides`, so I created two separate
  methods:
  
  - `Config::load_with_cli_overrides(cli_overrides: Vec<(String,
  TomlValue)>)`
  - `Config::load_with_cli_overrides_and_harness_overrides(cli_overrides:
  Vec<(String, TomlValue)>, harness_overrides: ConfigOverrides)`
  
  The latter has a long name, as it is _not_ what should be used in the
  common case, so the extra typing is designed to draw attention to this
  fact. I tried to update the existing callsites to use the shorter name,
  where possible.
  
  Further, in the cases where `ConfigOverrides` is used, usually only a
  limited subset of fields are actually set, so I updated the declarations
  to leverage `..Default::default()` where possible.

  Michael Bolin · 2025-12-17 18:01:17 -08:00
  a8797019a1
• feat: experimental menu (#8071)

  This will automatically render any `Stage::Beta` features.
  
  The change only gets applied to the *next session*. This started as a
  bug but actually this is a good thing to prevent out of distribution
  push
  
  <img width="986" height="288" alt="Screenshot 2025-12-15 at 15 38 35"
  src="https://github.com/user-attachments/assets/78b7a71d-0e43-4828-a118-91c5237909c7"
  />
  
  
  <img width="509" height="109" alt="Screenshot 2025-12-15 at 17 35 44"
  src="https://github.com/user-attachments/assets/6933de52-9b66-4abf-b58b-a5f26d5747e2"
  />

  jif-oai · 2025-12-17 17:08:03 +00:00
  ac6ba286aa
• Elevated Sandbox 4 (#7889)
  iceweasel-oai · 2025-12-12 12:30:38 -08:00
  677732ff65
• Fix toasts on Windows under WSL 2 (#7137)

  Before this: no notifications or toasts when using Codex CLI in WSL 2.
  
  After this: I get toasts from Codex

  dank-openai · 2025-12-11 15:09:00 -08:00
  36610d975a
• fix: policy/*.codexpolicy -> rules/*.rules (#7888)

  We decided that `*.rules` is a more fitting (and concise) file extension
  than `*.codexpolicy`, so we are changing the file extension for the
  "execpolicy" effort. We are also changing the subfolder of `$CODEX_HOME`
  from `policy` to `rules` to match.
  
  This PR updates the in-repo docs and we will update the public docs once
  the next CLI release goes out.
  
  Locally, I created `~/.codex/rules/default.rules` with the following
  contents:
  
  ```
  prefix_rule(pattern=["gh", "pr", "view"])
  ```
  
  And then I asked Codex to run:
  
  ```
  gh pr view 7888 --json title,body,comments
  ```
  
  and it was able to!

  Michael Bolin · 2025-12-11 14:46:00 -08:00
  e0d7ac51d3
• Update RMCP client config guidance (#7895)

  ## Summary
  - update CLI OAuth guidance to reference `features.rmcp_client` instead
  of the deprecated experimental flag
  - keep login/logout help text consistent with the new feature flag
  
  ## Testing
  - `cargo test -p codex-cli`
  
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_693b3e0bf27c832cb66d585847a552ab)

  Jeremy Rose · 2025-12-11 14:43:55 -08:00
  bacbe871c8
• feat(tui2): copy tui crate and normalize snapshots (#7833)

  Introduce a full codex-tui source snapshot under the new codex-tui2
  crate so viewport work can be replayed in isolation.
  
  This change copies the entire codex-rs/tui/src tree into
  codex-rs/tui2/src in one atomic step, rather than piecemeal, to keep
  future diffs vs the original viewport bookmark easy to reason about.
  
  The goal is for codex-tui2 to render identically to the existing TUI
  behind the `features.tui2` flag while we gradually port the
  viewport/history commits from the joshka/viewport bookmark onto this
  forked tree.
  
  While on this baseline change, we also ran the codex-tui2 snapshot test
  suite and accepted all insta snapshots for the new crate, so the
  snapshot files now use the codex-tui2 naming scheme and encode the
  unmodified legacy TUI behavior. This keeps later viewport commits
  focused on intentional behavior changes (and their snapshots) rather
  than on mechanical snapshot renames.

  Josh McKinney · 2025-12-10 22:53:46 +00:00
  90f262e9a4
• feat(tui2): add feature-flagged tui2 frontend (#7793)

  Introduce a new codex-tui2 crate that re-exports the existing
  interactive TUI surface and delegates run_main directly to codex-tui.
  This keeps behavior identical while giving tui2 its own crate for future
  viewport work.
  
  Wire the codex CLI to select the frontend via the tui2 feature flag.
  When the merged CLI overrides include features.tui2=true (e.g. via
  --enable tui2), interactive runs are routed through
  codex_tui2::run_main; otherwise they continue to use the original
  codex_tui::run_main.
  
  Register Feature::Tui2 in the core feature registry and add the tui2
  crate and dependency entries so the new frontend builds alongside the
  existing TUI.
  
  This is a stub that only wires up the feature flag for this.
  
  <img width="619" height="364" alt="image"
  src="https://github.com/user-attachments/assets/4893f030-932f-471e-a443-63fe6b5d8ed9"
  />

  Josh McKinney · 2025-12-09 16:23:53 -08:00
  0c8828c5e2
• Refactor execpolicy fallback evaluation (#7544)

  ## Refactor of the `execpolicy` crate
  
  To illustrate why we need this refactor, consider an agent attempting to
  run `apple | rm -rf ./`. Suppose `apple` is allowed by `execpolicy`.
  Before this PR, `execpolicy` would consider `apple` and `pear` and only
  render one rule match: `Allow`. We would skip any heuristics checks on
  `rm -rf ./` and immediately approve `apple | rm -rf ./` to run.
  
  To fix this, we now thread a `fallback` evaluation function into
  `execpolicy` that runs when no `execpolicy` rules match a given command.
  In our example, we would run `fallback` on `rm -rf ./` and prevent
  `apple | rm -rf ./` from being run without approval.

  zhao-oai · 2025-12-03 23:39:48 -08:00
  3d35cb4619
• chore: review everywhere (#7444)
  jif-oai · 2025-12-02 11:26:27 +00:00
  4b78e2ab09
• chore: add cargo-deny configuration (#7119)

  - add GitHub workflow running cargo-deny on push/PR
  - document cargo-deny allowlist with workspace-dep notes and advisory
  ignores
  - align workspace crates to inherit version/edition/license for
  consistent checks

  Josh McKinney · 2025-11-24 12:22:18 -08:00
  ec49b56874
• execpolicycheck command in codex cli (#7012)

  adding execpolicycheck tool onto codex cli
  
  this is useful for validating policies (can be multiple) against
  commands.
  
  it will also surface errors in policy syntax:
  <img width="1150" height="281" alt="Screenshot 2025-11-19 at 12 46
  21 PM"
  src="https://github.com/user-attachments/assets/8f99b403-564c-4172-acc9-6574a8d13dc3"
  />
  
  this PR also changes output format when there's no match in the CLI.
  instead of returning the raw string `noMatch`, we return
  `{"noMatch":{}}`
  
  this PR is a rewrite of: https://github.com/openai/codex/pull/6932 (due
  to the numerous merge conflicts present in the original PR)
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zhao-oai · 2025-11-20 16:44:31 -05:00
  fe7a3f0c2b
• fix(cli): correct mcp add usage order (#6827)

  ## Summary
  - add an explicit `override_usage` string to `AddArgs` so clap prints
  `<NAME>` before the command/url choice, matching the actual parser and
  docs
  
  ### Before
  
  Usage: codex mcp add [OPTIONS] <COMMAND|--url <URL>> <NAME>
  
  
  ### After
  
  Usage: codex mcp add [OPTIONS] <NAME> [--url <URL> | -- <COMMAND>...]
  
  ---------
  
  Signed-off-by: kyuheon-kr <kyuheon.kr@gmail.com>

  Kyuheon Kim · 2025-11-20 12:32:12 -08:00
  33a6cc66ab
• tui: add branch to 'codex resume', filter by cwd (#6232)

  By default, show only sessions that shared a cwd with the current cwd.
  `--all` shows all sessions in all cwds. Also, show the branch name from
  the rollout metadata.
  
  <img width="1091" height="638" alt="Screenshot 2025-11-04 at 3 30 47 PM"
  src="https://github.com/user-attachments/assets/aae90308-6115-455f-aff7-22da5f1d9681"
  />

  Jeremy Rose · 2025-11-19 00:47:37 +00:00
  526eb3ff82
• windows sandbox: support multiple workspace roots (#6854)

  The Windows sandbox did not previously support multiple workspace roots
  via config. Now it does

  iceweasel-oai · 2025-11-18 16:35:00 -08:00
  cf57320b9f
• Update defaults to gpt-5.1 (#6652)

  ## Summary
  - update documentation, example configs, and automation defaults to
  reference gpt-5.1 / gpt-5.1-codex
  - bump the CLI and core configuration defaults, model presets, and error
  messaging to the new models while keeping the model-family/tool coverage
  for legacy slugs
  - refresh tests, fixtures, and TUI snapshots so they expect the upgraded
  defaults
  
  ## Testing
  - `cargo test -p codex-core
  config::tests::test_precedence_fixture_with_gpt5_profile`
  
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6916c5b3c2b08321ace04ee38604fc6b)

  Ahmed Ibrahim · 2025-11-17 17:40:11 -08:00
  ddcc60a085
• move cap_sid file into ~/.codex so the sandbox cannot overwrite it (#6798)

  The `cap_sid` file contains the IDs of the two custom SIDs that the
  Windows sandbox creates/manages to implement read-only and
  workspace-write sandbox policies.
  
  It previously lived in `<cwd>/.codex` which means that the sandbox could
  write to it, which could degrade the efficacy of the sandbox. This
  change moves it to `~/.codex/` (or wherever `CODEX_HOME` points to) so
  that it is outside the workspace.

  iceweasel-oai · 2025-11-17 15:49:41 -08:00
  e032d338f2
• Revert "templates and build step for validating/submitting winget package" (#6696)

  Reverts openai/codex#6485

  Ahmed Ibrahim · 2025-11-15 03:47:58 +00:00
  b560c5cef1
• templates and build step for validating/submitting winget package (#6485)
  iceweasel-oai · 2025-11-14 11:06:44 -08:00
  37fba28ac3
• add codex debug seatbelt --log-denials (#4098)

  This adds a debugging tool for analyzing why certain commands fail to
  execute under the sandbox.
  
  Example output:
  
  ```
  $ codex debug seatbelt --log-denials bash -lc "(echo foo > ~/foo.txt)"
  bash: /Users/nornagon/foo.txt: Operation not permitted
  
  === Sandbox denials ===
  (bash) file-write-data /dev/tty
  (bash) file-write-data /dev/ttys001
  (bash) sysctl-read kern.ngroups
  (bash) file-write-create /Users/nornagon/foo.txt
  ```
  
  It operates by:
  
  1. spawning `log stream` to watch system logs, and
  2. tracking all descendant PIDs using kqueue + proc_listchildpids.
  
  this is a "best-effort" technique, as `log stream` may drop logs(?), and
  kqueue + proc_listchildpids isn't atomic and can end up missing very
  short-lived processes. But it works well enough in my testing to be
  useful :)

  Jeremy Rose · 2025-11-10 22:48:14 +00:00
  0271c20d8f
• fix: update brew auto update version check (#6238)

  ### Summary
  * Use
  `https://github.com/Homebrew/homebrew-cask/blob/main/Casks/c/codex.rb`
  to get the latest available version for brew usage.

  Shijie Rao · 2025-11-10 09:05:00 -08:00
  788badd221
• [app-server] feat: add command to generate json schema (#6406)

  Add a `codex generate-json-schema` command for generating a JSON schema
  bundle of app-server types, analogous to the existing `codex
  generate-ts` command for Typescript.

  Owen Lin · 2025-11-10 16:59:14 +00:00
  fbdedd9a06
• fix: use generate_ts from app_server_protocol (#6407)

  Update `codex generate-ts` to use the TS export code from
  `app-server-protocol/src/export.rs`.
  
  I realized there were two duplicate implementations of Typescript export
  code:
  - `app-server-protocol/src/export.rs`
  - the `codex-protocol-ts` crate
  
  The `codex-protocol-ts` crate that `codex generate-ts` uses is out of
  date now since it doesn't handle the V2 namespace from:
  https://github.com/openai/codex/pull/6212.

  Owen Lin · 2025-11-10 08:08:12 -08:00
  42683dadfb
• For npm upgrade on Windows, go through cmd.exe to get path traversal working (#6387)

  On Windows, `npm` by itself does not resolve under std::process::Command
  which does not consider PATHEXT to resolve it to `npm.cmd` in the PATH.
  By running the npm upgrade command via cmd.exe we get proper path
  semantics so it actually works.

  iceweasel-oai · 2025-11-09 21:07:44 -08:00
  625f2208c4
• Improve world-writable scan (#6381)

  1. scan many more directories since it's much faster than the original
  implementation
  2. limit overall scan time to 2s
  3. skip some directories that are noisy - ApplicationData, Installer,
  etc.

  iceweasel-oai · 2025-11-07 21:28:55 -08:00
  917f39ec12
• fix(wsl): normalize Windows paths during update (#6086) (#6097)

  When running under WSL, the update command could receive Windows-style
  absolute paths (e.g., `C:\...`) and pass them to Linux processes
  unchanged, which fails because WSL expects those paths in
  `/mnt/<drive>/...` form.
  
  This patch adds a tiny helper in the CLI (`cli/src/wsl_paths.rs`) that:
  - Detects WSL (`WSL_DISTRO_NAME` or `"microsoft"` in `/proc/version`)  
  - Converts `X:\...` → `/mnt/x/...`  
  
  `run_update_action` now normalizes the package-manager command and
  arguments under WSL before spawning.
  Non-WSL platforms are unaffected.  
  
  Includes small unit tests for the converter.  
  
  **Fixes:** #6086, #6084
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  Jakob Malmo · 2025-11-07 14:49:17 -08:00
  2eecc1a2e4
• core: widen sandbox to allow certificate ops when network is enabled (#5980)

  This allows `gh api` to work in the workspace-write sandbox w/ network
  enabled. Without this we see e.g.
  
  ```
  $ codex debug seatbelt --full-auto gh api repos/openai/codex/pulls --paginate -X GET -F state=all
  Get "https://api.github.com/repos/openai/codex/pulls?per_page=100&state=all": tls: failed to verify certificate: x509: OSStatus -26276
  ```

  Jeremy Rose · 2025-11-06 12:47:20 -08:00
  8501b0b768
• fix: Update the deprecation message to link to the docs (#6211)

  The deprecation message is currently a bit confusing. Users may not
  understand what is `[features].x`. I updated the docs and the
  deprecation message for more guidance.
  
  ---------
  
  Co-authored-by: Gabriel Peal <gpeal@users.noreply.github.com>

  Ahmed Ibrahim · 2025-11-04 21:02:27 +00:00
  d40a6b7f73
• fix: --search shouldn't show deprecation message (#6180)

  Use the new feature flags instead of the old config.

  Ahmed Ibrahim · 2025-11-04 00:11:50 +00:00
  e658c6c73b
• log sandbox commands to $CODEX_HOME instead of cwd (#6171)

  Logging commands in the Windows Sandbox is temporary, but while we are
  doing it, let's always write to CODEX_HOME instead of dirtying the cwd.

  iceweasel-oai · 2025-11-03 13:12:33 -08:00
  07b7d28937
• Fix typo in error message for OAuth login (#6159)

  Error message for attempting to OAuth with a remote RCP is incorrect and
  misleading. The correct config is
  
  ```
  [features]
  rmcp_client = true
  ```
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  Mark Hemmings · 2025-11-03 08:59:00 -08:00
  4d8b71d412
• Windows Sandbox - Alpha version (#4905)

  - Added the new codex-windows-sandbox crate that builds both a library
  entry point (run_windows_sandbox_capture) and a CLI executable to launch
  commands inside a Windows restricted-token sandbox, including ACL
  management, capability SID provisioning, network lockdown, and output
  capture
  (windows-sandbox-rs/src/lib.rs:167, windows-sandbox-rs/src/main.rs:54).
  - Introduced the experimental WindowsSandbox feature flag and wiring so
  Windows builds can opt into the sandbox:
  SandboxType::WindowsRestrictedToken, the in-process execution path, and
  platform sandbox selection now honor the flag (core/src/features.rs:47,
  core/src/config.rs:1224, core/src/safety.rs:19,
  core/src/sandboxing/mod.rs:69, core/src/exec.rs:79,
  core/src/exec.rs:172).
  - Updated workspace metadata to include the new crate and its
  Windows-specific dependencies so the core crate can link against it
  (codex-rs/
      Cargo.toml:91, core/Cargo.toml:86).
  - Added a PowerShell bootstrap script that installs the Windows
  toolchain, required CLI utilities, and builds the workspace to ease
  development
      on the platform (scripts/setup-windows.ps1:1).
  - Landed a Python smoke-test suite that exercises
  read-only/workspace-write policies, ACL behavior, and network denial for
  the Windows sandbox
      binary (windows-sandbox-rs/sandbox_smoketests.py:1).

  iceweasel-oai · 2025-10-30 15:51:57 -07:00
  87cce88f48
• nit: log rmcp_client (#5978)
  jif-oai · 2025-10-30 17:40:38 +00:00
  209af68611
• chore: unify config crates (#5958)
  jif-oai · 2025-10-30 10:28:32 +00:00
  aa76003e28
• chore: config editor (#5878)

  The goal is to have a single place where we actually write files
  
  In a follow-up PR, will move everything config related in a dedicated
  module and move the helpers in a dedicated file

  jif-oai · 2025-10-29 20:52:46 +00:00
  db31f6966d
• [Auth] Choose which auth storage to use based on config (#5792)

  This PR is a follow-up to #5591. It allows users to choose which auth
  storage mode they want by using the new
  `cli_auth_credentials_store_mode` config.

  Celia Chen · 2025-10-27 19:41:49 -07:00
  4a42c4e142
• [Auth] Introduce New Auth Storage Abstraction for Codex CLI (#5569)

  This PR introduces a new `Auth Storage` abstraction layer that takes
  care of read, write, and load of auth tokens based on the
  AuthCredentialsStoreMode. It is similar to how we handle MCP client
  oauth
  [here](https://github.com/openai/codex/blob/main/codex-rs/rmcp-client/src/oauth.rs).
  Instead of reading and writing directly from disk for auth tokens, Codex
  CLI workflows now should instead use this auth storage using the public
  helper functions.
  
  This PR is just a refactor of the current code so the behavior stays the
  same. We will add support for keyring and hybrid mode in follow-up PRs.
  
  I have read the CLA Document and I hereby sign the CLA

  Celia Chen · 2025-10-27 11:01:14 -07:00
  eb5b1b627f