53 Commits

• fix: Fix tilde expansion to avoid absolute-path escape (#9621)

  ### Motivation
  - Prevent inputs like `~//` or `~///etc` from expanding to arbitrary
  absolute paths (e.g. `/`) because `Path::join` discards the left side
  when the right side is absolute, which could allow config values to
  escape `HOME` and broaden writable roots.
  
  ### Description
  - In `codex-rs/utils/absolute-path/src/lib.rs` update
  `maybe_expand_home_directory` to trim leading separators from the suffix
  and return `home` when the remainder is empty so tilde expansion stays
  rooted under `HOME`.
  - Add a non-Windows unit test
  `home_directory_double_slash_on_non_windows_is_expanded_in_deserialization`
  that validates `"~//code"` expands to `home.join("code")`.
  
  ### Testing
  - Ran `just fmt` successfully.
  - Ran `just fix -p codex-utils-absolute-path` (Clippy autofix)
  successfully.
  - Ran `cargo test -p codex-utils-absolute-path` and all tests passed.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_697007481cac832dbeb1ee144d1e4cbe)

  Tiffany Citra · 2026-01-21 10:43:10 -08:00
  8179312ff5
• fix: writable_roots doesn't recognize home directory symbol in non-windows OS (#9193)

  Fixes:
  ```
  [sandbox_workspace_write]
  writable_roots = ["~/code/"]
  ```
  
  translates to
  ```
  /Users/ccunningham/.codex/~/code
  ```
  (i.e. the home dir symbol isn't recognized)

  Tiffany Citra · 2026-01-20 10:55:01 -08:00
  2c3843728c
• feat: detach non-tty childs (#9477)

  Thanks to the investigations made by
  * @frantic-openai https://github.com/openai/codex/pull/9403
  * @kfiramar https://github.com/openai/codex/pull/9388

  jif-oai · 2026-01-19 11:35:34 +00:00
  dc1b62acbd
• fix: flaky tests (#9373)
  jif-oai · 2026-01-16 17:24:41 +01:00
  2691e1ce21
• chore: close pipe on non-pty processes (#9369)

  Closing the STDIN of piped process when starting them to avoid commands
  like `rg` to wait for content on STDIN and hangs for ever

  jif-oai · 2026-01-16 15:54:32 +01:00
  1668ca726f
• feat: adding piped process to replace PTY when needed (#8797)
  jif-oai · 2026-01-14 18:44:04 +00:00
  577e1fd1b2
• 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
• fix: make the find_resource! macro responsible for the absolutize() call (#8884)

  https://github.com/openai/codex/pull/8879 introduced the
  `find_resource!` macro, but now that I am about to use it in more
  places, I realize that it should take care of this normalization case
  for callers.
  
  Note the `use $crate::path_absolutize::Absolutize;` line is there so
  that users of `find_resource!` do not have to explicitly include
  `path-absolutize` to their own `Cargo.toml`.

  Michael Bolin · 2026-01-07 23:03:43 -08:00
  35fd69a9f0
• feat: introduce find_resource! macro that works with Cargo or Bazel (#8879)

  To support Bazelification in https://github.com/openai/codex/pull/8875,
  this PR introduces a new `find_resource!` macro that we use in place of
  our existing logic in tests that looks for resources relative to the
  compile-time `CARGO_MANIFEST_DIR` env var.
  
  To make this work, we plan to add the following to all `rust_library()`
  and `rust_test()` Bazel rules in the project:
  
  ```
  rustc_env = {
      "BAZEL_PACKAGE": native.package_name(),
  },
  ```
  
  Our new `find_resource!` macro reads this value via
  `option_env!("BAZEL_PACKAGE")` so that the Bazel package _of the code
  using `find_resource!`_ is injected into the code expanded from the
  macro. (If `find_resource()` were a function, then
  `option_env!("BAZEL_PACKAGE")` would always be
  `codex-rs/utils/cargo-bin`, which is not what we want.)
  
  Note we only consider the `BAZEL_PACKAGE` value when the `RUNFILES_DIR`
  environment variable is set at runtime, indicating that the test is
  being run by Bazel. In this case, we have to concatenate the runtime
  `RUNFILES_DIR` with the compile-time `BAZEL_PACKAGE` value to build the
  path to the resource.
  
  In testing this change, I discovered one funky edge case in
  `codex-rs/exec-server/tests/common/lib.rs` where we have to _normalize_
  (but not canonicalize!) the result from `find_resource!` because the
  path contains a `common/..` component that does not exist on disk when
  the test is run under Bazel, so it must be semantically normalized using
  the [`path-absolutize`](https://crates.io/crates/path-absolutize) crate
  before it is passed to `dotslash fetch`.
  
  Because this new behavior may be non-obvious, this PR also updates
  `AGENTS.md` to make humans/Codex aware that this API is preferred.

  Michael Bolin · 2026-01-07 18:06:08 -08:00
  f6b563ec64
• fix: implement 'Allow this session' for apply_patch approvals (#8451)

  **Summary**
  This PR makes “ApprovalDecision::AcceptForSession / don’t ask again this
  session” actually work for `apply_patch` approvals by caching approvals
  based on absolute file paths in codex-core, properly wiring it through
  app-server v2, and exposing the choice in both TUI and TUI2.
  - This brings `apply_patch` calls to be at feature-parity with general
  shell commands, which also have a "Yes, and don't ask again" option.
  - This also fixes VSCE's "Allow this session" button to actually work.
  
  While we're at it, also split the app-server v2 protocol's
  `ApprovalDecision` enum so execpolicy amendments are only available for
  command execution approvals.
  
  **Key changes**
  - Core: per-session patch approval allowlist keyed by absolute file
  paths
  - Handles multi-file patches and renames/moves by recording both source
  and destination paths for `Update { move_path: Some(...) }`.
  - Extend the `Approvable` trait and `ApplyPatchRuntime` to work with
  multiple keys, because an `apply_patch` tool call can modify multiple
  files. For a request to be auto-approved, we will need to check that all
  file paths have been approved previously.
  - App-server v2: honor AcceptForSession for file changes
  - File-change approval responses now map AcceptForSession to
  ReviewDecision::ApprovedForSession (no longer downgraded to plain
  Approved).
  - Replace `ApprovalDecision` with two enums:
  `CommandExecutionApprovalDecision` and `FileChangeApprovalDecision`
  - TUI / TUI2: expose “don’t ask again for these files this session”
  - Patch approval overlays now include a third option (“Yes, and don’t
  ask again for these files this session (s)”).
      - Snapshot updates for the approval modal.
  
  **Tests added/updated**
  - Core:
  - Integration test that proves ApprovedForSession on a patch skips the
  next patch prompt for the same file
  - App-server:
  - v2 integration test verifying
  FileChangeApprovalDecision::AcceptForSession works properly
  
  **User-visible behavior**
  - When the user approves a patch “for session”, future patches touching
  only those previously approved file(s) will no longer prompt gain during
  that session (both via app-server v2 and TUI/TUI2).
  
  **Manual testing**
  Tested both TUI and TUI2 - see screenshots below.
  
  TUI:
  <img width="1082" height="355" alt="image"
  src="https://github.com/user-attachments/assets/adcf45ad-d428-498d-92fc-1a0a420878d9"
  />
  
  
  TUI2:
  <img width="1089" height="438" alt="image"
  src="https://github.com/user-attachments/assets/dd768b1a-2f5f-4bd6-98fd-e52c1d3abd9e"
  />

  Owen Lin · 2026-01-07 20:11:12 +00:00
  66450f0445
• fix: parse git apply paths correctly (#8824)

  Fixes apply.rs path parsing so 
  - quoted diff headers are tokenized and extracted correctly, 
  - /dev/null headers are ignored before prefix stripping to avoid bogus
  dev/null paths, and
  - git apply output paths are unescaped from C-style quoting.
  
  **Why**
  This prevents potentially missed staging and misclassified paths when
  applying or reverting patches, which could lead to incorrect behavior
  for repos with spaces or escaped characters in filenames.
  
  **Impact**
  I checked and this is only used in the cloud tasks support and `codex
  apply <task_id>` flow.

  Thibault Sottiaux · 2026-01-07 13:00:31 +00:00
  a59052341d
• fix: fix readiness subscribe token wrap-around (#8770)

  Fixes ReadinessFlag::subscribe to avoid handing out token 0 or duplicate
  tokens on i32 wrap-around, adds regression tests, and prevents readiness
  gates from getting stuck waiting on an unmarkable or mis-authorized
  token.

  Thibault Sottiaux · 2026-01-06 13:09:02 +00:00
  6346e4f560
• 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
• feat: load ExecPolicyManager from ConfigLayerStack (#8453)

  https://github.com/openai/codex/pull/8354 added support for in-repo
  `.config/` files, so this PR updates the logic for loading `*.rules`
  files to load `*.rules` files from all relevant layers. The main change
  to the business logic is `load_exec_policy()` in
  `codex-rs/core/src/exec_policy.rs`.
  
  Note this adds a `config_folder()` method to `ConfigLayerSource` that
  returns `Option<AbsolutePathBuf>` so that it is straightforward to
  iterate over the sources and get the associated config folder, if any.

  Michael Bolin · 2025-12-22 17:24:17 -08:00
  277babba79
• feat: support in-repo .codex/config.toml entries as sources of config info (#8354)

  - We now support `.codex/config.toml` in repo (from `cwd` up to the
  first `.git` found, if any) as layers in `ConfigLayerStack`. A new
  `ConfigLayerSource::Project` variant was added to support this.
  - In doing this work, I realized that we were resolving relative paths
  in `config.toml` after merging everything into one `toml::Value`, which
  is wrong: paths should be relativized with respect to the folder
  containing the `config.toml` that was deserialized. This PR introduces a
  deserialize/re-serialize strategy to account for this in
  `resolve_config_paths()`. (This is why `Serialize` is added to so many
  types as part of this PR.)
  - Added tests to verify this new behavior.
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8354).
  * #8359
  * __->__ #8354

  Michael Bolin · 2025-12-22 11:07:36 -08:00
  8ff16a7714
• 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
• Fix: /undo destructively interacts with git staging (#8214) (#8303)

  Fixes #8214 by removing the '--staged' flag from the undo git restore
  command. This ensures that while the working tree is reverted to the
  snapshot state, the user's staged changes (index) are preserved,
  preventing data loss. Also adds a regression test.

  GalaxyDetective · 2025-12-19 10:07:41 -08:00
  014235f533
• feat: add config to disable warnings around ghost snapshot (#8178)
  jif-oai · 2025-12-17 18:50:22 +00:00
  3d92b443b0
• feat: fallback unified_exec to shell_command (#8075)
  jif-oai · 2025-12-17 10:29:45 +00:00
  813bdb9010
• feat: ghost snapshot v2 (#8055)

  This PR updates ghost snapshotting to avoid capturing oversized
  untracked artifacts while keeping undo safe. Snapshot creation now
  builds a temporary index from `git status --porcelain=2 -z`, writes a
  tree and detached commit without touching refs, and records any ignored
  large files/dirs in the snapshot report. Undo uses that metadata to
  preserve large local artifacts while still cleaning up new transient
  files.

  jif-oai · 2025-12-15 11:14:36 +01:00
  0d9801d448
• feat: config ghost commits (#7873)
  jif-oai · 2025-12-15 09:13:06 +01:00
  4274e6189a
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

  Changes the `writable_roots` field of the `WorkspaceWrite` variant of
  the `SandboxPolicy` enum from `Vec<PathBuf>` to `Vec<AbsolutePathBuf>`.
  This is helpful because now callers can be sure the value is an absolute
  path rather than a relative one. (Though when using an absolute path in
  a Seatbelt config policy, we still have to _canonicalize_ it first.)
  
  Because `writable_roots` can be read from a config file, it is important
  that we are able to resolve relative paths properly using the parent
  folder of the config file as the base path.

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• fix: race on rx subscription (#7921)

  Fix race where the PTY was sending first chunk before the subscription
  to the broadcast

  jif-oai · 2025-12-12 12:40:54 +01:00
  f152b16ed9
• feat: use remote branch for review is local trails (#7813)
  jif-oai · 2025-12-10 17:04:52 +00:00
  97b90094cd
• chore: rework unified exec events (#7775)
  jif-oai · 2025-12-10 10:30:38 +00:00
  0ad54982ae
• fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)

  This PR attempts to solve two problems by introducing a
  `AbsolutePathBuf` type with a special deserializer:
  
  - `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
  ensures, by constructing, that it represents a value that is an
  absolute, normalized path, which is a stronger guarantee than an
  arbitrary `PathBuf`.
  - Values in `config.toml` that can be either an absolute or relative
  path should be resolved against the folder containing the `config.toml`
  in the relative path case. This PR makes this easy to support: the main
  cost is ensuring `AbsolutePathBufGuard` is used inside
  `deserialize_config_toml_with_base()`.
  
  While `AbsolutePathBufGuard` may seem slightly distasteful because it
  relies on thread-local storage, this seems much cleaner to me than using
  than my various experiments with
  https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
  Further, since the `deserialize()` method from the `Deserialize` trait
  is not async, we do not really have to worry about the deserialization
  work being spread across multiple threads in a way that would interfere
  with `AbsolutePathBufGuard`.
  
  To start, this PR introduces the use of `AbsolutePathBuf` in
  `OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
  no longer requires `settings.codex_home` to be threaded through.
  Furthermore, this sets us up better for a world where multiple
  `config.toml` files from different folders could be loaded and then
  merged together, as the absolutifying of the paths must be done against
  the correct parent folder.

  Michael Bolin · 2025-12-09 17:37:52 -08:00
  fa4cac1e6b
• Vendor ConPtySystem (#7656)

  The repo we were depending on is very large and we need very small part
  of it.
  
  ---------
  
  Co-authored-by: Pavel <pavel@krymets.com>

  pakrym-oai · 2025-12-09 17:23:51 +00:00
  164265bed1
• Fix unified_exec on windows (#7620)

  Fix unified_exec on windows
  
  Requires removal of PSUEDOCONSOLE_INHERIT_CURSOR flag so child processed
  don't attempt to wait for cursor position response (and timeout).
  
  
  https://github.com/wezterm/wezterm/compare/main...pakrym:wezterm:PSUEDOCONSOLE_INHERIT_CURSOR?expand=1
  
  ---------
  
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  Pavel Krymets · 2025-12-05 20:09:43 +00:00
  f48d88067e
• feat: add pycache to excluded directories (#7545)
  jif-oai · 2025-12-03 20:06:55 +00:00
  9e6c2c1e64
• Fix: track only untracked paths in ghost snapshots (#7470)

  # Ghost snapshot ignores
  
  This PR should close #7067, #7395, #7405.
  
  Prior to this change the ghost snapshot task ran `git status
  --ignored=matching` so the report picked up literally every ignored
  file. When a directory only contained entries matched by patterns such
  as `dozens/*.txt`, `/test123/generated/*.html`, or `/wp-includes/*`, Git
  still enumerated them and the large-untracked-dir detection treated the
  parent directory as “large,” even though everything inside was
  intentionally ignored.
  
  By removing `--ignored=matching` we only capture true untracked paths
  now, so those patterns stay out of the snapshot report and no longer
  trigger the “large untracked directories” warning.
  
  ---------
  
  Signed-off-by: lionelchg <lionel.cheng@hotmail.fr>
  Co-authored-by: lionelchg <lionel.cheng@hotmail.fr>

  lionel-oai · 2025-12-02 19:42:33 +01:00
  349734e38d
• feat: ignore standard directories (#7483)
  jif-oai · 2025-12-02 18:42:07 +00:00
  2222cab9ea
• 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
• Delete tiktoken-rs (#7018)
  pakrym-oai · 2025-11-20 11:15:04 -08:00
  52d0ec4cd8
• feat: warning large commits (#6838)
  jif-oai · 2025-11-19 10:22:10 +00:00
  956d3bfac6
• Add the utility to truncate by tokens (#6746)

  - This PR is to make it on path for truncating by tokens. This path will
  be initially used by unified exec and context manager (responsible for
  MCP calls mainly).
  - We are exposing new config `calls_output_max_tokens`
  - Use `tokens` as the main budget unit but truncate based on the model
  family by Introducing `TruncationPolicy`.
  - Introduce `truncate_text` as a router for truncation based on the
  mode.
  
  In next PRs:
  - remove truncate_with_line_bytes_budget
  - Add the ability to the model to override the token budget.

  Ahmed Ibrahim · 2025-11-18 11:36:23 -08:00
  3de8790714
• feat: git branch tooling (#6831)
  jif-oai · 2025-11-18 15:26:09 +00:00
  fc55fd7a81
• 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
• feat: placeholder for image that can't be decoded to prevent 400 (#6773)
  jif-oai · 2025-11-17 16:10:53 +00:00
  7c8d333980
• feat: cache tokenizer (#6609)
  jif-oai · 2025-11-14 17:05:00 +01:00
  f17b392470
• Reasoning level update (#6586)

  Automatically update reasoning levels when migrating between models

  pakrym-oai · 2025-11-13 06:24:36 +00:00
  e3dd362c94
• Use codex-linux-sandbox in unified exec (#6480)

  Unified exec isn't working on Linux because we don't provide the correct
  arg0.
  
  The library we use for pty management doesn't allow setting arg0
  separately from executable. Use the same aliasing strategy we use for
  `apply_patch` for `codex-linux-sandbox`.
  
  Use `#[ctor]` hack to dispatch codex-linux-sandbox calls.
  
  
  Addresses https://github.com/openai/codex/issues/6450

  pakrym-oai · 2025-11-10 17:17:09 -08:00
  6c36318bd8
• [app-server] remove serde(skip_serializing_if = "Option::is_none") annotations (#5939)

  We had this annotation everywhere in app-server APIs which made it so
  that fields get serialized as `field?: T`, meaning if the field as
  `None` we would omit the field in the payload. Removing this annotation
  changes it so that we return `field: T | null` instead, which makes
  codex app-server's API more aligned with the convention of public OpenAI
  APIs like Responses.
  
  Separately, remove the `#[ts(optional_fields = nullable)]` annotations
  that were recently added which made all the TS types become `field?: T |
  null` which is not great since clients need to handle undefined and
  null.
  
  I think generally it'll be best to have optional types be either:
  - `field: T | null` (preferred, aligned with public OpenAI APIs)
  - `field?: T` where we have to, such as types generated from the MCP
  schema:
  https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-06-18/schema.ts
  (see changes to `mcp-types/`)
  
  I updated @etraut-openai's unit test to check that all generated TS
  types are one or the other, not both (so will error if we have a type
  that has `field?: T | null`). I don't think there's currently a good use
  case for that - but we can always revisit.

  Owen Lin · 2025-10-30 18:18:53 +00:00
  89c00611c2
• Add missing "nullable" macro to protocol structs that contain optional fields (#5901)

  This PR addresses a current hole in the TypeScript code generation for
  the API server protocol. Fields that are marked as "Optional<>" in the
  Rust code are serialized such that the value is omitted when it is
  deserialized — appearing as `undefined`, but the TS type indicates
  (incorrectly) that it is always defined but possibly `null`. This can
  lead to subtle errors that the TypeScript compiler doesn't catch. The
  fix is to include the `#[ts(optional_fields = nullable)]` macro for all
  protocol structs that contain one or more `Optional<>` fields.
  
  This PR also includes a new test that validates that all TS protocol
  code containing "| null" in its type is marked optional ("?") to catch
  cases where `#[ts(optional_fields = nullable)]` is omitted.

  Eric Traut · 2025-10-29 12:09:47 -07:00
  069a38a06c
• chore: merge git crates (#5909)

  Merge `git-apply` and `git-tooling` into `utils/`

  jif-oai · 2025-10-29 12:11:44 +00:00
  fa92cd92fa
• feat: image resizing (#5446)

  Add image resizing on the client side to reduce load on the API

  jif-oai · 2025-10-27 16:58:10 +00:00
  aea7610c76
• feat: async ghost commit (#5618)
  jif-oai · 2025-10-27 10:09:10 +00:00
  e92c4f6561
• feat: use actual tokenizer for unified_exec truncation (#5514)
  jif-oai · 2025-10-23 17:08:06 +01:00
  0b4527146e
• feat: local tokenizer (#5508)
  jif-oai · 2025-10-22 16:01:02 +01:00
  fd0673e457
• chore: rework tools execution workflow (#5278)

  Re-work the tool execution flow. Read `orchestrator.rs` to understand
  the structure

  jif-oai · 2025-10-20 20:57:37 +01:00
  5e4f3bbb0b
• Use assert_matches (#4756)

  assert_matches is soon to be in std but is experimental for now.

  pakrym-oai · 2025-10-05 21:12:31 +00:00
  5c42419b02