86bc948584
## Why `codex-core` still had a `test-support` crate feature that was enabled by multiple consumers (`core_test_support`, `app_test_support`, and `codex-tui` dev-deps). That introduced a second feature-resolved shape of `codex-core`, which increases compile cost and cache fragmentation across the workspace. The same root issue previously affected `deterministic_process_ids`: we were using crate features as a test/runtime switch, and Cargo had to build extra variants of a very large crate. ## What Changed ### 1) Remove `test-support` as a crate feature - Deleted the feature declaration from `core/Cargo.toml`. - Removed `features = ["test-support"]` from: - `core/tests/common/Cargo.toml` - `app-server/tests/common/Cargo.toml` - `tui/Cargo.toml` (dev-dependency) - Removed Bazel `crate_features = ["test-support"]` from `core/BUILD.bazel`. ### 2) Keep test behavior without feature-gated crate variants - Converted test-only behavior toggles to **explicit runtime switches** backed by `AtomicBool`: - thread-manager test mode toggle - deterministic unified-exec process-id toggle - Enabled those toggles from `core_test_support` ctor so integration tests keep deterministic and test-friendly behavior. ### 3) Replace feature-gated helper APIs with always-compiled hidden helpers - APIs that were previously behind `#[cfg(feature = "test-support")]` are now available as `#[doc(hidden)]` test helpers, avoiding feature-split builds while preserving existing test call sites. ## Expected Benefits ### Concrete dependency-graph effect `cargo tree -p codex-core -e features` now shows only the default feature path for `codex-core`; there are no `test-support` or `deterministic_process_ids` feature edges remaining. ### Build-performance impact - Eliminates feature-driven duplicate `codex-core` compilation variants. - Improves cache reuse across test-support consumers that previously forced separate feature resolution. - Reduces rebuild churn when switching between targets that did and did not depend on the feature-enabled `codex-core` shape. ## Safety / behavior notes - Production behavior remains unchanged by default. - Test-only behavior is now explicit and opt-in via dedicated test toggles, with docstrings clarifying these must stay at default values in production. ## Validation - `just fmt` - `cargo test -p codex-core unified_exec::` - `cargo test -p codex-core --test all unified_exec -- --test-threads=1` - `cargo check -p app_test_support` - `cargo check -p codex-tui --tests` - `cargo check -p codex-core` - `cargo tree -p codex-core -e features`
codex-core
This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.
Dependencies
Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:
macOS
Expects /usr/bin/sandbox-exec to be present.
When using the workspace-write sandbox policy, the Seatbelt profile allows
writes under the configured writable roots while keeping .git (directory or
pointer file), the resolved gitdir: target, and .codex read-only.
Linux
Expects the binary containing codex-core to run the equivalent of codex sandbox linux (legacy alias: codex debug landlock) when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.
All Platforms
Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.