## Why
We want actionable build-hotspot data from CI so we can tune Rust
workflow performance (for example, target coverage, cache behavior, and
job shape) based on actual compile-time bottlenecks.
`cargo` timing reports are lightweight and provide a direct way to
inspect where compilation time is spent.
## What Changed
- Updated `.github/workflows/rust-release.yml` to run `cargo build` with
`--timings` and upload `target/**/cargo-timings/cargo-timing.html`.
- Updated `.github/workflows/rust-release-windows.yml` to run `cargo
build` with `--timings` and upload
`target/**/cargo-timings/cargo-timing.html`.
- Updated `.github/workflows/rust-ci.yml` to:
- run `cargo clippy` with `--timings`
- run `cargo nextest run` with `--timings` (stable-compatible)
- upload `target/**/cargo-timings/cargo-timing.html` artifacts for both
the clippy and nextest jobs
Artifacts are matrix-scoped via artifact names so timings can be
compared per target/profile.
## Verification
- Confirmed the net diff is limited to:
- `.github/workflows/rust-ci.yml`
- `.github/workflows/rust-release.yml`
- `.github/workflows/rust-release-windows.yml`
- Verified timing uploads are added immediately after the corresponding
timed commands in each workflow.
- Confirmed stable Cargo accepts plain `--timings` for the compile phase
(`cargo test --no-run --timings`) and generates
`target/cargo-timings/cargo-timing.html`.
- Ran VS Code diagnostics on modified workflow files; no new diagnostics
were introduced by these changes.
## Why
`project_doc::tests::skills_are_appended_to_project_doc` and
`project_doc::tests::skills_render_without_project_doc` were assuming a
single synthetic skill in test setup, but they called
`load_skills(&cfg)`, which loads from repo/user/system roots.
That made the assertions environment-dependent. After
[#11531](https://github.com/openai/codex/pull/11531) added
`.codex/skills/test-tui/SKILL.md`, the repo-scoped `test-tui` skill
began appearing in these test outputs and exposed the flake.
## What Changed
- Added a test-only helper in `codex-rs/core/src/project_doc.rs` that
loads skills from an explicit root via `load_skills_from_roots`.
- Scoped that root to `codex_home/skills` with `SkillScope::User`.
- Updated both affected tests to use this helper instead of
`load_skills(&cfg)`:
- `skills_are_appended_to_project_doc`
- `skills_render_without_project_doc`
This keeps the tests focused on the fixture skills they create,
independent of ambient repo/home skills.
## Verification
- `cargo test -p codex-core
project_doc::tests::skills_render_without_project_doc -- --exact`
- `cargo test -p codex-core
project_doc::tests::skills_are_appended_to_project_doc -- --exact`
## Summary
This PR removes the temporary `CODEX_BWRAP_ENABLE_FFI` flag and makes
Linux builds always compile vendored bubblewrap support for
`codex-linux-sandbox`.
## Changes
- Removed `CODEX_BWRAP_ENABLE_FFI` gating from
`codex-rs/linux-sandbox/build.rs`.
- Linux builds now fail fast if vendored bubblewrap compilation fails
(instead of warning and continuing).
- Updated fallback/help text in
`codex-rs/linux-sandbox/src/vendored_bwrap.rs` to remove references to
`CODEX_BWRAP_ENABLE_FFI`.
- Removed `CODEX_BWRAP_ENABLE_FFI` env wiring from:
- `.github/workflows/rust-ci.yml`
- `.github/workflows/bazel.yml`
- `.github/workflows/rust-release.yml`
---------
Co-authored-by: David Zbarsky <zbarsky@openai.com>
## Why
Installing `zstd` via Chocolatey in
`.github/workflows/rust-release-windows.yml` has been taking about a
minute on Windows release runs. This adds avoidable latency to each
release job.
Using DotSlash removes that package-manager install step and pins the
exact binary we use for compression.
## What Changed
- Added `.github/workflows/zstd`, a DotSlash wrapper that fetches
`zstd-v1.5.7-win64.zip` with pinned size and digest.
- Updated `.github/workflows/rust-release-windows.yml` to:
- install DotSlash via `facebook/install-dotslash@v2`
- replace `zstd -T0 -19 ...` with
`${GITHUB_WORKSPACE}/.github/workflows/zstd -T0 -19 ...`
- `windows-aarch64` uses the same win64 upstream zstd artifact because
upstream releases currently publish `win32` and `win64` binaries.
## Verification
- Verified the workflow now resolves the DotSlash file from
`${GITHUB_WORKSPACE}` while the job runs with `working-directory:
codex-rs`.
- Ran VS Code diagnostics on changed files:
- `.github/workflows/rust-release-windows.yml`
- `.github/workflows/zstd`
## Why
`rust-release` cache restore has had very low practical value, while
cache save consistently costs significant time (usually adding ~3
minutes to the critical path of a release workflow).
From successful release-tag runs with cache steps (`289` runs total):
- Alpha tags: cache download averaged ~5s/run, cache upload averaged
~230s/run.
- Stable tags: cache download averaged ~5s/run, cache upload averaged
~227s/run.
- Windows release builds specifically: download ~2s/run vs upload
~169-170s/run.
Hard step-level signal from the same successful release-tag runs:
- Cache restore (`Run actions/cache`): `2,314` steps, total `1,515s`
(~0.65s/step).
- `95.3%` of restore steps finished in `<=1s`; `99.7%` finished in
`<=2s`; `0` steps took `>=10s`.
- Cache save (`Post Run actions/cache`): `2,314` steps, total `66,295s`
(~28.65s/step).
Run-level framing:
- Download total was `<=10s` in `288/289` runs (`99.7%`).
- Upload total was `>=120s` in `285/289` runs (`98.6%`).
The net effect is that release jobs are spending time uploading caches
that are rarely useful for subsequent runs.
## What Changed
- Removed the `actions/cache@v5` step from
`.github/workflows/rust-release.yml`.
- Removed the `actions/cache@v5` step from
`.github/workflows/rust-release-windows.yml`.
- Left build, signing, packaging, and publishing flow unchanged.
## Validation
- Queried historical `rust-release` run/job step timing and compared
cache download vs upload for alpha and stable release tags.
- Spot-checked release logs and observed repeated `Cache not found ...`
followed by `Cache saved ...` patterns.
`SandboxPolicy::ReadOnly` previously implied broad read access and could
not express a narrower read surface.
This change introduces an explicit read-access model so we can support
user-configurable read restrictions in follow-up work, while preserving
current behavior today.
It also ensures unsupported backends fail closed for restricted-read
policies instead of silently granting broader access than intended.
## What
- Added `ReadOnlyAccess` in protocol with:
- `Restricted { include_platform_defaults, readable_roots }`
- `FullAccess`
- Updated `SandboxPolicy` to carry read-access configuration:
- `ReadOnly { access: ReadOnlyAccess }`
- `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
- Preserved existing behavior by defaulting current construction paths
to `ReadOnlyAccess::FullAccess`.
- Threaded the new fields through sandbox policy consumers and call
sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
related tests.
- Updated Seatbelt policy generation to honor restricted read roots by
emitting scoped read rules when full read access is not granted.
- Added fail-closed behavior on Linux and Windows backends when
restricted read access is requested but not yet implemented there
(`UnsupportedOperation`).
- Regenerated app-server protocol schema and TypeScript artifacts,
including `ReadOnlyAccess`.
## Compatibility / rollout
- Runtime behavior remains unchanged by default (`FullAccess`).
- API/schema changes are in place so future config wiring can enable
restricted read access without another policy-shape migration.
## Why
`suite::v2::app_list::list_apps_uses_thread_feature_flag_when_thread_id_is_provided`
has been flaky in CI. The test exercises `thread/start`, which
initializes `codex_apps`. In CI/Linux, that path can reach OS
keyring-backed MCP OAuth credential lookup (`Codex MCP Credentials`) and
intermittently abort the MCP process (observed stack overflow in
`zbus`), causing the test to fail before the assertion logic runs.
## What Changed
- Updated the test config in
`codex-rs/app-server/tests/suite/v2/app_list.rs` to set
`mcp_oauth_credentials_store = "file"` in both relevant config-writing
paths:
- The in-test config override inside
`list_apps_uses_thread_feature_flag_when_thread_id_is_provided`
- `write_connectors_config(...)`, which is used by the v2 `app_list`
test suite
- This keeps test coverage focused on thread-scoped app feature flags
while removing OS keyring/DBus dependency from this test path.
## How It Was Verified
- `cargo test -p codex-app-server`
- `cargo test -p codex-app-server
list_apps_uses_thread_feature_flag_when_thread_id_is_provided --
--nocapture`
These leaked into the repo:
- #4905 `codex-rs/windows-sandbox-rs/Cargo.lock`
- #5391 `codex-rs/app-server-test-client/Cargo.lock`
Note that these affect cache keys such as:
9722567a80/.github/workflows/rust-release.yml (L154)
so it seems best to remove them.
This is in response to seeing this on BuildBuddy:
> There were tests whose specified size is too big. Use the
--test_verbose_timeout_warnings command line option to see which ones
these are.
- Update token usage aggregation to refresh model context window after a
model change.
- Add protocol/core tests, including an e2e model-switch test that
validates switching to a smaller model updates telemetry.
- Clamp auto-compaction to the minimum of configured limit and 90% of
context window
- Add an e2e compact test for clamped behavior
- Update remote compact tests to account for earlier auto-compaction in
setup turns
- Run pre-sampling compact through a single helper that builds
previous-model turn context and compacts before the follow-up request
when switching to a smaller context window.
- Keep compaction events on the parent turn id and add compact suite
coverage for switch-in-session and resume+switch flows.
# External (non-OpenAI) Pull Request Requirements
Before opening this Pull Request, please read the dedicated
"Contributing" markdown file or your PR may be closed:
https://github.com/openai/codex/blob/main/docs/contributing.md
If your PR conforms to our contribution guidelines, replace this text
with a detailed and high quality description of your changes.
Include a link to a bug report or enhancement request.
## Summary
- Remove `Feature::SearchTool` and the `search_tool` config key from the
feature registry/schema.
- Gate `search_tool_bm25` exposure via `Feature::Apps` in
`core/src/tools/spec.rs`.
- Update MCP selection logic in `core/src/codex.rs` to use
`Feature::Apps` for search-tool behavior.
- Update `core/tests/suite/search_tool.rs` to enable `Feature::Apps`.
- Regenerate `core/config.schema.json` via `just write-config-schema`.
## Testing
- `just fmt`
- `cargo test -p codex-core --test all suite::search_tool::`
## Tickets
- None
I gave Codex the following bug report about the logic to report the
host's resources introduced in
https://github.com/openai/codex/pull/11488 and this PR is its proposed
fix.
The fix seems like an escaping issue, mostly.
---
The logic to print out the runner specs has an awk error on Mac:
```
Runner: GitHub Actions 1014936475
OS: macOS 15.7.3
Hardware model: VirtualMac2,1
CPU architecture: arm64
Logical CPUs: 5
Physical CPUs: 5
awk: syntax error at source line 1
context is
{printf >>> \ <<< "%.1f GiB\\n\", $1 / 1024 / 1024 / 1024}
awk: illegal statement at source line 1
Total RAM:
Disk usage:
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk3s5 320Gi 237Gi 64Gi 79% 2.0M 671M 0% /System/Volumes/Data
```
as well as Linux:
```
Runner: GitHub Actions 1014936469
OS: Linux runnervmwffz4 6.11.0-1018-azure #18~24.04.1-Ubuntu SMP Sat Jun 28 04:46:03 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
awk: cmd. line:1: /Model name/ {gsub(/^[ \t]+/,\"\",$2); print $2; exit}
awk: cmd. line:1: ^ backslash not last character on line
CPU model:
Logical CPUs: 4
awk: cmd. line:1: /MemTotal/ {printf \"%.1f GiB\\n\", $2 / 1024 / 1024}
awk: cmd. line:1: ^ backslash not last character on line
Total RAM:
Disk usage:
Filesystem Size Used Avail Use% Mounted on
/dev/root 72G 50G 22G 70% /
```
I don't think this policy change increases the risk, other than
potentially exposing the caller to bugs in these kernel calls, which are
unlikely.
Without this change, some tools are silently failing or making incorrect
decisions about the processor type (e.g. installing x86 binaries rather
than Apple silicon binaries).
This addresses #11210
---------
Co-authored-by: viyatb-oai <viyatb@openai.com>
This stack layer makes app-server thread event delivery connection-aware
so resumed/attached threads only emit notifications and approval prompts
to subscribed connections.
- Added per-thread subscription tracking in `ThreadState`
(`subscribed_connections`) and mapped subscription ids to `(thread_id,
connection_id)`.
- Updated listener lifecycle so removing a subscription or closing a
connection only removes that connection from the thread’s subscriber
set; listener shutdown now happens when the last subscriber is gone.
- Added `connection_closed(connection_id)` plumbing (`lib.rs` ->
`message_processor.rs` -> `codex_message_processor.rs`) so disconnect
cleanup happens immediately.
- Scoped bespoke event handling outputs through `TargetedOutgoing` to
send requests/notifications only to subscribed connections.
- Kept existing threadresume behavior while aligning with the latest
split-loop transport structure.
## Summary
Consolidate `/status` Permissions lines into a simpler view. It should
only show "Default," "Full Access," or "Custom" (with specifics)
## Testing
- [x] many snapshots updated
Windows release builds were compiling and linking four release binaries
on a single runner, which slowed the release pipeline. The
Windows-specific logic also made `rust-release.yml` harder to read and
maintain.
## What Changed
- Extracted Windows release logic into a reusable workflow at
`.github/workflows/rust-release-windows.yml`.
- Updated `.github/workflows/rust-release.yml` to call the reusable
Windows workflow via `workflow_call`.
- Parallelized Windows binary builds with one 4-entry matrix over two
targets (`x86_64-pc-windows-msvc`, `aarch64-pc-windows-msvc`) and two
bundles (`primary`, `helpers`).
- Kept signing centralized per target by downloading both prebuilt
bundles and signing all four executables together.
- Preserved final release artifact behavior and filtered intermediate
`windows-binaries*` artifacts out of the published release asset set.
Users were reporting that when they were actively editing a skill file,
they would see frequent errors (one per second) across all of their
active session until they fixed all frontmatter parse errors. This
change will reduce the chatter at the expense of a slightly longer delay
before skills are updated in the UI.
This addresses #11385
Windows release builds in `.github/workflows/rust-release.yml` were
still using GitHub-hosted `windows-latest` and `windows-11-arm` runners.
This change aligns release builds with the faster dedicated Codex runner
pool already used in CI, and adds machine-spec logging at startup so
runner capacity (CPU/RAM/disk) is visible in build logs.
## What Changed
- Updated the `build` job to support matrix entries that provide a full
`runs_on` object:
- `runs-on: ${{ matrix.runs_on || matrix.runner }}`
- Switched Windows release matrix entries to Codex runners:
- `windows-latest` -> `windows-x64` with:
- `group: codex-runners`
- `labels: codex-windows-x64`
- `windows-11-arm` -> `windows-arm64` with:
- `group: codex-runners`
- `labels: codex-windows-arm64`
- Updated the ARM-specific zstd install condition to match the new
runner id:
- `matrix.runner == 'windows-arm64'`
- Added early platform-specific runner diagnostics steps
(Linux/macOS/Windows) that print OS, CPU, logical CPU count, total RAM,
and disk usage.
1. Move Windows Sandbox NUX to right after trust directory screen
2. Don't offer read-only as an option in Sandbox NUX.
Elevated/Legacy/Quit
3. Don't allow new untrusted directories. It's trust or quit
4. move experimental sandbox features to `[windows]
sandbox="elevated|unelevatd"`
5. Copy tweaks = elevated -> default, non-elevated -> non-admin
## Summary
- Increases `PASTE_BURST_CHAR_INTERVAL` from 8ms to 30ms on Windows to
fix multi-line paste issues in VS Code integrated terminal
- Follows existing pattern of platform-specific timing (like
`PASTE_BURST_ACTIVE_IDLE_TIMEOUT`)
## Problem
When pasting multi-line text in Codex CLI on Windows (especially VS Code
integrated terminal), only the first portion is captured before
auto-submit. The rest arrives as a separate message.
**Root cause**: VS Code's terminal emulation adds latency (~10-15ms per
character) between key events. The 8ms `PASTE_BURST_CHAR_INTERVAL`
threshold is too tight - characters arrive slower than expected, so
burst detection fails and Enter submits instead of inserting a newline.
## Solution
Use Windows-specific timing (30ms) for `PASTE_BURST_CHAR_INTERVAL`,
following the same pattern already used for
`PASTE_BURST_ACTIVE_IDLE_TIMEOUT` (60ms on Windows vs 8ms on Unix).
30ms is still fast enough to distinguish paste from typing (humans type
~200ms between keystrokes).
## Test plan
- [x] All existing paste_burst tests pass
- [ ] Test multi-line paste in VS Code integrated PowerShell on Windows
- [ ] Test multi-line paste in standalone Windows PowerShell
- [ ] Verify no regression on macOS/Linux
Fixes#2137
Co-authored-by: Josh McKinney <joshka@openai.com>
Reapply "Add app-server transport layer with websocket support" with
additional fixes from https://github.com/openai/codex/pull/11313/changes
to avoid deadlocking.
This reverts commit 47356ff83c.
## Summary
To avoid deadlocking when queues are full, we maintain separate tokio
tasks dedicated to incoming vs outgoing event handling
- split the app-server main loop into two tasks in
`run_main_with_transport`
- inbound handling (`transport_event_rx`)
- outbound handling (`outgoing_rx` + `thread_created_rx`)
- separate incoming and outgoing websocket tasks
## Validation
Integration tests, testing thoroughly e2e in codex app w/ >10 concurrent
requests
<img width="1365" height="979" alt="Screenshot 2026-02-10 at 2 54 22 PM"
src="https://github.com/user-attachments/assets/47ca2c13-f322-4e5c-bedd-25859cbdc45f"
/>
---------
Co-authored-by: jif-oai <jif@openai.com>
`codex-core` had accumulated config loading, requirements parsing,
constraint logic, and config-layer state handling in a single crate.
This change extracts that subsystem into `codex-config` to reduce
`codex-core` rebuild/test surface area and isolate future config work.
## What Changed
### Added `codex-config`
- Added new workspace crate `codex-rs/config` (`codex-config`).
- Added workspace/build wiring in:
- `codex-rs/Cargo.toml`
- `codex-rs/config/Cargo.toml`
- `codex-rs/config/BUILD.bazel`
- Updated lockfiles (`codex-rs/Cargo.lock`, `MODULE.bazel.lock`).
- Added `codex-core` -> `codex-config` dependency in
`codex-rs/core/Cargo.toml`.
### Moved config internals from `core` into `config`
Moved modules to `codex-rs/config/src/`:
- `core/src/config/constraint.rs` -> `config/src/constraint.rs`
- `core/src/config_loader/cloud_requirements.rs` ->
`config/src/cloud_requirements.rs`
- `core/src/config_loader/config_requirements.rs` ->
`config/src/config_requirements.rs`
- `core/src/config_loader/fingerprint.rs` -> `config/src/fingerprint.rs`
- `core/src/config_loader/merge.rs` -> `config/src/merge.rs`
- `core/src/config_loader/overrides.rs` -> `config/src/overrides.rs`
- `core/src/config_loader/requirements_exec_policy.rs` ->
`config/src/requirements_exec_policy.rs`
- `core/src/config_loader/state.rs` -> `config/src/state.rs`
`codex-config` now re-exports this surface from `config/src/lib.rs` at
the crate top level.
### Updated `core` to consume/re-export `codex-config`
- `core/src/config_loader/mod.rs` now imports/re-exports config-loader
types/functions from top-level `codex_config::*`.
- Local moved modules were removed from `core/src/config_loader/`.
- `core/src/config/mod.rs` now re-exports constraint types from
`codex_config`.
