## Why
The remaining `vt100-tests` and `debug-logs` features in `codex-tui` were only selecting debug and test-only behavior. Those are exactly the cases where this repo already accepts `#[cfg(debug_assertions)]` as the Cargo-free substitute.
## What changed
- delete `vt100-tests` and `debug-logs` from `codex-tui`
- gate the VT100 integration tests with `debug_assertions` instead of a Cargo feature
- gate the textarea debug log site with `debug_assertions`
- shrink the manifest verifier allowlist again so only the remaining real feature exceptions stay permitted
## Why
`codex-cloud-tasks-client` was mixing two different roles: the real HTTP
client and the mock implementation used by tests and local mock mode.
Keeping both in the same crate forced Cargo feature toggles and Bazel
`crate_features` just to pick an implementation.
This change keeps `codex-cloud-tasks-client` focused on the shared API
surface and real backend client, and moves the mock implementation into
its own crate so we can remove those feature permutations cleanly.
## What changed
- add a new `codex-cloud-tasks-mock-client` crate that owns `MockClient`
- remove the `mock` and `online` features from
`codex-cloud-tasks-client`
- make `codex-cloud-tasks-client` unconditionally depend on
`codex-backend-client` and export `HttpClient` directly
- gate the mock-mode path in `codex-cloud-tasks` behind
`#[cfg(debug_assertions)]`, so release builds always initialize the real
HTTP client
- update `codex-cloud-tasks` and its tests to use
`codex-cloud-tasks-mock-client::MockClient` wherever mock behavior is
needed
- remove the matching Bazel `crate_features` override and shrink the
manifest verifier allowlist accordingly
## How tested
- `cargo test -p codex-cloud-tasks-client`
- `cargo test -p codex-cloud-tasks-mock-client`
- `cargo test -p codex-cloud-tasks`
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16456).
* #16457
* __->__ #16456
## Why
The remaining `vt100-tests` and `debug-logs` features in `codex-tui` were only selecting debug and test-only behavior. Those are exactly the cases where this repo already accepts `#[cfg(debug_assertions)]` as the Cargo-free substitute.
## What changed
- delete `vt100-tests` and `debug-logs` from `codex-tui`
- gate the VT100 integration tests with `debug_assertions` instead of a Cargo feature
- gate the textarea debug log site with `debug_assertions`
- shrink the manifest verifier allowlist again so only the remaining real feature exceptions stay permitted
## Why
`codex-cloud-tasks-client` was still using Cargo features to select its HTTP and mock implementations. That leaks feature permutations into both Cargo and Bazel for a crate that does not need them.
## What changed
- delete the `online` and `mock` crate features from `codex-cloud-tasks-client`
- make `codex-backend-client` unconditional and always export both `HttpClient` and `MockClient`
- remove the internal `features = ["mock", "online"]` activation from `codex-cloud-tasks`
- remove the matching Bazel `crate_features` override
- shrink the manifest verifier allowlist to match the remaining exceptions
## Why
The remaining `vt100-tests` and `debug-logs` features in `codex-tui` were only selecting debug and test-only behavior. Those are exactly the cases where this repo already accepts `#[cfg(debug_assertions)]` as the Cargo-free substitute.
## What changed
- delete `vt100-tests` and `debug-logs` from `codex-tui`
- gate the VT100 integration tests with `debug_assertions` instead of a Cargo feature
- gate the textarea debug log site with `debug_assertions`
- shrink the manifest verifier allowlist again so only the remaining real feature exceptions stay permitted
## Why
`codex-cloud-tasks-client` was still using Cargo features to select its HTTP and mock implementations. That leaks feature permutations into both Cargo and Bazel for a crate that does not need them.
## What changed
- delete the `online` and `mock` crate features from `codex-cloud-tasks-client`
- make `codex-backend-client` unconditional and always export both `HttpClient` and `MockClient`
- remove the internal `features = ["mock", "online"]` activation from `codex-cloud-tasks`
- remove the matching Bazel `crate_features` override
- shrink the manifest verifier allowlist to match the remaining exceptions
## Why
The remaining `vt100-tests` and `debug-logs` features in `codex-tui` were only selecting debug and test-only behavior. Those are exactly the cases where this repo already accepts `#[cfg(debug_assertions)]` as the Cargo-free substitute.
## What changed
- delete `vt100-tests` and `debug-logs` from `codex-tui`
- gate the VT100 integration tests with `debug_assertions` instead of a Cargo feature
- gate the textarea debug log site with `debug_assertions`
- shrink the manifest verifier allowlist again so only the remaining real feature exceptions stay permitted
## Why
`codex-cloud-tasks-client` was still using Cargo features to select its HTTP and mock implementations. That leaks feature permutations into both Cargo and Bazel for a crate that does not need them.
## What changed
- delete the `online` and `mock` crate features from `codex-cloud-tasks-client`
- make `codex-backend-client` unconditional and always export both `HttpClient` and `MockClient`
- remove the internal `features = ["mock", "online"]` activation from `codex-cloud-tasks`
- remove the matching Bazel `crate_features` override
- shrink the manifest verifier allowlist to match the remaining exceptions
## Why
The remaining `vt100-tests` and `debug-logs` features in `codex-tui` were only selecting debug and test-only behavior. Those are exactly the cases where this repo already accepts `#[cfg(debug_assertions)]` as the Cargo-free substitute.
## What changed
- delete `vt100-tests` and `debug-logs` from `codex-tui`
- gate the VT100 integration tests with `debug_assertions` instead of a Cargo feature
- gate the textarea debug log site with `debug_assertions`
- shrink the manifest verifier allowlist again so only the remaining real feature exceptions stay permitted
## Why
`codex-cloud-tasks-client` was still using Cargo features to select its HTTP and mock implementations. That leaks feature permutations into both Cargo and Bazel for a crate that does not need them.
## What changed
- delete the `online` and `mock` crate features from `codex-cloud-tasks-client`
- make `codex-backend-client` unconditional and always export both `HttpClient` and `MockClient`
- remove the internal `features = ["mock", "online"]` activation from `codex-cloud-tasks`
- remove the matching Bazel `crate_features` override
- shrink the manifest verifier allowlist to match the remaining exceptions
## Why
We already enforce workspace metadata and lint inheritance for
`codex-rs` manifests, but we still allow new crate features to slip into
the workspace. That makes it too easy to add more Cargo-only feature
permutations while we are trying to eliminate them.
## What changed
- extend `verify_cargo_workspace_manifests.py` to reject new
`[features]` tables in workspace crates
- reject new optional dependencies that create implicit crate features
- reject new workspace-to-workspace `features = [...]` activations and
`default-features = false`
- add a narrow temporary allowlist for the existing feature-bearing
manifests and internal feature activations
- make the allowlist self-shrinking so a follow-up removal has to delete
its corresponding exception
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16455).
* #16457
* #16456
* __->__ #16455
Makes fuzzy file search use case-insensitive matching instead of
smart-case in `codex-file-search`. I find smart-case to be a poor user
experience -using the wrong case for a letter drops its match so
significantly, it often drops off the results list, effectively making a
search case-sensitive.
## Why
The remaining `vt100-tests` and `debug-logs` features in `codex-tui` were only selecting debug and test-only behavior. Those are exactly the cases where this repo already accepts `#[cfg(debug_assertions)]` as the Cargo-free substitute.
## What changed
- delete `vt100-tests` and `debug-logs` from `codex-tui`
- gate the VT100 integration tests with `debug_assertions` instead of a Cargo feature
- gate the textarea debug log site with `debug_assertions`
- shrink the manifest verifier allowlist again so only the remaining real feature exceptions stay permitted
## Why
`codex-cloud-tasks-client` was still using Cargo features to select its HTTP and mock implementations. That leaks feature permutations into both Cargo and Bazel for a crate that does not need them.
## What changed
- delete the `online` and `mock` crate features from `codex-cloud-tasks-client`
- make `codex-backend-client` unconditional and always export both `HttpClient` and `MockClient`
- remove the internal `features = ["mock", "online"]` activation from `codex-cloud-tasks`
- remove the matching Bazel `crate_features` override
- shrink the manifest verifier allowlist to match the remaining exceptions
## Why
We already enforce workspace metadata and lint inheritance for `codex-rs` manifests, but we still allow new crate features to slip into the workspace. That makes it too easy to add more Cargo-only feature permutations while we are trying to eliminate them.
## What changed
- extend `verify_cargo_workspace_manifests.py` to reject new `[features]` tables in workspace crates
- reject new optional dependencies that create implicit crate features
- reject new workspace-to-workspace `features = [...]` activations and `default-features = false`
- add a narrow temporary allowlist for the existing feature-bearing manifests and internal feature activations
- make the allowlist self-shrinking so a follow-up removal has to delete its corresponding exception
## Why
The remaining `vt100-tests` and `debug-logs` features in `codex-tui` were only selecting debug and test-only behavior. Those are exactly the cases where this repo already accepts `#[cfg(debug_assertions)]` as the Cargo-free substitute.
## What changed
- delete `vt100-tests` and `debug-logs` from `codex-tui`
- gate the VT100 integration tests with `debug_assertions` instead of a Cargo feature
- gate the textarea debug log site with `debug_assertions`
- shrink the manifest verifier allowlist again so only the remaining real feature exceptions stay permitted
## Why
`codex-cloud-tasks-client` was still using Cargo features to select its HTTP and mock implementations. That leaks feature permutations into both Cargo and Bazel for a crate that does not need them.
## What changed
- delete the `online` and `mock` crate features from `codex-cloud-tasks-client`
- make `codex-backend-client` unconditional and always export both `HttpClient` and `MockClient`
- remove the internal `features = ["mock", "online"]` activation from `codex-cloud-tasks`
- remove the matching Bazel `crate_features` override
- shrink the manifest verifier allowlist to match the remaining exceptions
## Why
We already enforce workspace metadata and lint inheritance for `codex-rs` manifests, but we still allow new crate features to slip into the workspace. That makes it too easy to add more Cargo-only feature permutations while we are trying to eliminate them.
## What changed
- extend `verify_cargo_workspace_manifests.py` to reject new `[features]` tables in workspace crates
- reject new optional dependencies that create implicit crate features
- reject new workspace-to-workspace `features = [...]` activations and `default-features = false`
- add a narrow temporary allowlist for the existing feature-bearing manifests and internal feature activations
- make the allowlist self-shrinking so a follow-up removal has to delete its corresponding exception
I noticed that Codex was spending more time on running this lint check
locally than I would like. Now that we have the linter running
cross-platform using Bazel in CI, I find it's best just to update the PR
ASAP to get CI going than to wait for `just argument-comment-lint` to
finish locally before updating the PR.
## Summary
In #11871 we started consolidating on ExecRequest.sandbox_policy instead
of passing in a separate policy object that theoretically could differ
(but did not). This finishes the some parameter cleanup.
This should be a simple noop, since all 3 callsites of this function
already used a cloned object from the ExecRequest value.
## Testing
- [x] Existing tests pass
Michael Bolin