Conversation
This was referenced Apr 1, 2026
bolinfest
added a commit
that referenced
this pull request
Apr 1, 2026
## 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
c042246 to
65ed50f
Compare
## 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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
codex-cloud-tasks-clientwas 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 Bazelcrate_featuresjust to pick an implementation.This change keeps
codex-cloud-tasks-clientfocused 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
codex-cloud-tasks-mock-clientcrate that ownsMockClientmockandonlinefeatures fromcodex-cloud-tasks-clientcodex-cloud-tasks-clientunconditionally depend oncodex-backend-clientand exportHttpClientdirectlycodex-cloud-tasksbehind#[cfg(debug_assertions)], so release builds always initialize the real HTTP clientcodex-cloud-tasksand its tests to usecodex-cloud-tasks-mock-client::MockClientwherever mock behavior is neededcrate_featuresoverride and shrink the manifest verifier allowlist accordinglyHow tested
cargo test -p codex-cloud-tasks-clientcargo test -p codex-cloud-tasks-mock-clientcargo test -p codex-cloud-tasksStack created with Sapling. Best reviewed with ReviewStack.