Configuration, policy, and environment tests

fn enterprise_requirement(contents: impl Into<String>) -> Self

Purpose: Creates a new fixture containing one enterprise-managed requirements fragment. Tests use it when they only need a single cloud requirements snippet.

Data flow: It starts from an empty default fixture, takes the provided text, and passes that text into the method that adds a requirements fragment. The result is a fixture whose bundle now contains one requirements entry.

Call relations: This is a convenience shortcut over building a default fixture and then calling the add method. It is used by tests that need to check how enterprise requirements are added and ordered.

Call graph: called by 1 (adds_enterprise_requirements_in_order); 1 external calls (default).

fn enterprise_config(contents: impl Into<String>) -> Self

Purpose: Creates a new fixture containing one enterprise-managed config fragment. Tests use it when they only need a single cloud config snippet.

Data flow: It starts from an empty default fixture, takes the provided text, and passes that text into the method that adds a config fragment. The result is a fixture whose bundle now contains one config entry.

Call relations: This is the config-side twin of CloudConfigBundleFixture::enterprise_requirement. Other helper methods build on it when they need a ready-made loader for cloud config tests.

Call graph: 1 external calls (default).

fn loader_with_enterprise_requirement(
        contents: impl Into<String>,
    ) -> CloudConfigBundleLoader

Purpose: Creates a fake cloud bundle loader containing one enterprise-managed requirements fragment. Tests use this when they want the config system to behave as if cloud requirements were loaded.

Data flow: It receives requirements text, builds a fixture with that text as a requirements fragment, then turns the fixture into a CloudConfigBundleLoader. The output is a loader that will return the prepared bundle during the test.

Call relations: Many config-layer tests call this helper before exercising the real loading code. It first relies on CloudConfigBundleFixture::enterprise_requirement to build the bundle, then hands that bundle to CloudConfigBundleFixture::into_loader so the rest of the system can consume it through the normal loader path.

Call graph: called by 36 (write_value_rejects_feature_requirement_conflict, load_config_layers_applies_matching_remote_sandbox_config, load_config_layers_can_ignore_managed_requirements, load_config_layers_includes_cloud_config_bundle, load_config_layers_includes_cloud_hook_requirements, load_config_layers_resolves_relative_bundle_requirements_paths_against_codex_home, mdm_requirements_take_precedence_over_cloud_config_bundle, active_profile_is_cleared_when_requirements_force_fallback, approvals_reviewer_preserves_valid_user_choice_when_allowed_by_requirements, browser_feature_requirements_are_valid (+15 more)); 1 external calls (enterprise_requirement).

fn loader_with_enterprise_config(contents: impl Into<String>) -> CloudConfigBundleLoader

Purpose: Creates a fake cloud bundle loader containing one enterprise-managed config fragment. Tests use this to check how cloud config is inserted, merged, or rejected by the normal config loading code.

Data flow: It receives config text, builds a fixture with that text as a config fragment, then converts the fixture into a CloudConfigBundleLoader. The result is a loader that returns the prepared bundle without contacting any real service.

Call relations: This helper is called by tests that need cloud config, rather than cloud requirements. It builds on CloudConfigBundleFixture::enterprise_config and then uses CloudConfigBundleFixture::into_loader to present the fixture through the same interface production code expects.

Call graph: called by 2 (load_config_layers_inserts_cloud_config_between_system_and_user, strict_config_rejects_unknown_cloud_config_key); 1 external calls (enterprise_config).

fn add_enterprise_requirement(mut self, contents: impl Into<String>) -> Self

Purpose: Adds one enterprise-managed requirements fragment to an existing fixture. This lets tests build bundles with several requirement snippets in a known order.

Data flow: It takes the current fixture and new requirements text. It counts how many requirements fragments are already present, chooses the next id and name from that count, stores the text in a new CloudRequirementsFragment, and pushes that fragment into the bundle. It returns the updated fixture so more additions can be chained.

Call relations: This is the core helper behind CloudConfigBundleFixture::enterprise_requirement. Tests or other helper methods can call it repeatedly to create multi-fragment bundles, which is useful when testing ordering, precedence, or merging behavior.

Call graph: 2 external calls (into, format!).

fn add_enterprise_config(mut self, contents: impl Into<String>) -> Self

Purpose: Adds one enterprise-managed config fragment to an existing fixture. This lets tests build bundles with several config snippets in a predictable order.

Data flow: It takes the current fixture and new config text. It counts the existing config fragments, creates the next id and display name, stores the text in a new CloudConfigFragment, and appends it to the bundle. It returns the updated fixture so callers can keep building.

Call relations: This is the core helper behind CloudConfigBundleFixture::enterprise_config. It prepares the config fragments that later get returned directly as a bundle or indirectly through a fake loader.

Call graph: 2 external calls (into, format!).

fn into_bundle(self) -> CloudConfigBundle

Purpose: Finishes the fixture and returns the CloudConfigBundle inside it. Tests use this when they want the built bundle itself rather than a loader around it.

Data flow: It consumes the fixture, meaning the fixture is used up, and extracts its stored CloudConfigBundle. Nothing is copied or further changed; the prepared bundle simply becomes the return value.

Call relations: CloudConfigBundleFixture::into_loader calls this first so it can wrap the finished bundle in a loader. It is the handoff point from the test builder object to the actual cloud bundle data structure.

Call graph: called by 1 (into_loader).

fn into_loader(self) -> CloudConfigBundleLoader

Purpose: Turns the prepared fixture into a fake CloudConfigBundleLoader. This allows tests to run the normal config-loading path while controlling exactly what cloud data appears.

Data flow: It consumes the fixture, extracts the finished bundle, and creates a new loader around an asynchronous function that returns that bundle wrapped as a successful optional result. The output is a loader ready to be passed into code under test.

Call relations: This is the final step used by the loader convenience helpers. After requirements or config fragments have been added, this function packages them behind CloudConfigBundleLoader::new so tests can plug fake cloud data into the same flow that production code uses.

Call graph: calls 2 internal fn (new, into_bundle).

fn adds_enterprise_requirements_in_order()

Purpose: This test proves that the cloud configuration fixture builder appends enterprise requirements in the same order they are added. It also verifies the helper gives each generated requirement the expected identifier and display name.

Data flow: The test starts with the text "first" and uses it to create a fixture bundle with one enterprise requirement. It then adds the text "second" as another requirement and turns the fixture into the final bundle object. Finally, it reads the bundle’s enterprise-managed requirements list and compares it with the exact two expected requirement records; the output is a passing test if they match, or a clear test failure if they do not.

Call relations: During the test run, this function calls the fixture helper that creates the first enterprise requirement, then builds on that fixture before checking the result. It hands the actual and expected lists to the assertion macro so the test framework can report whether the helper behaved correctly.

Call graph: calls 1 internal fn (enterprise_requirement); 1 external calls (assert_eq!).

async fn shared_future_runs_once()

Purpose: This test proves that a cloud config loader shares one in-progress load instead of running duplicate work. It matters because loading cloud configuration may involve network or disk work, and doing it twice could waste time or cause inconsistent results.

Data flow: The test starts with a counter set to zero. It creates a loader whose async loading function increments that counter and returns an empty default cloud bundle. Then it asks the loader for the bundle twice at the same time. After both requests finish, it checks two things: both callers got the same result, and the counter says the loading function ran exactly once.

Call relations: During the test, shared_future_runs_once creates a CloudConfigBundleLoader with new, then uses Tokio's join! helper to call loader.get() twice concurrently. The assertions confirm the loader's shared-future behavior: concurrent callers are joined to the same underlying load rather than starting separate loads.

Call graph: calls 1 internal fn (new); 6 external calls (clone, new, new, assert_eq!, default, join!).

fn bundle_layers_preserve_enterprise_managed_bucket_order()

Purpose: This test checks that enterprise-managed cloud config and requirements are converted into layers in the correct priority order. That is important because later or higher-priority layers can decide which setting wins when multiple fragments mention the same kind of rule.

Data flow: The test creates a temporary directory to stand in for a real config base directory. It builds a fake cloud bundle containing two config fragments and two requirements fragments, labeled high and low. It passes that bundle into CloudConfigBundleLayers::from_bundle, then inspects the resulting layers. The config layers should appear in the expected low-then-high order, and composing the requirements should leave the final allowed approval policy as on-request.

Call relations: This test calls from_bundle to exercise the normal conversion path from raw cloud bundle data into config layers. It then calls compose_requirements on the requirements layers to check the practical effect of that ordering: the composed result should reflect the intended enterprise-managed priority.

Call graph: calls 2 internal fn (from_bundle, from_absolute_path); 3 external calls (assert_eq!, tempdir, vec!).

fn bundle_layers_can_strict_validate_enterprise_managed_config()

Purpose: This test confirms that strict validation rejects cloud configuration containing fields the program does not recognize. This prevents a misspelled or unsupported cloud setting from being silently ignored.

Data flow: The test creates a temporary base directory and builds a fake cloud bundle with one enterprise-managed config fragment. That fragment contains unknown_key = true, which is not a valid configuration field. It passes the bundle into CloudConfigBundleLayers::from_bundle_strict_config and expects an error. Finally, it checks that the error identifies the exact fragment and clearly says the unknown field was rejected.

Call relations: This test uses from_bundle_strict_config, which is the stricter version of bundle-to-layer conversion. Instead of accepting the fragment and moving on, that path hands back a CloudConfigLayerError::Invalid, and the test verifies the error is precise enough for a human or calling system to understand what went wrong.

Call graph: calls 2 internal fn (from_bundle_strict_config, from_absolute_path); 4 external calls (new, assert_eq!, tempdir, vec!).

fn fragment(id: &str, name: &str, contents: &str) -> CloudConfigFragment

Purpose: Creates a small fake cloud configuration fragment for tests. It saves each test from repeatedly writing out the same struct fields by hand.

Data flow: It takes an id, a human-readable name, and a text block of configuration. It copies those strings into a new CloudConfigFragment, which the tests can pass into the cloud-layer conversion code.

Call relations: This is a local test helper. The tests use it when they need realistic-looking cloud fragments without involving any real cloud service.

fn toml(contents: &str) -> TomlValue

Purpose: Parses a short TOML configuration string into the in-memory TOML value used by the configuration stack. TOML is the project’s text format for configuration.

Data flow: It receives configuration text, asks the TOML parser to turn that text into structured data, and returns that structured value. If the test text is not valid TOML, it stops the test immediately because the test setup itself is wrong.

Call relations: The enterprise layer ordering test calls this helper to build expected and input configuration values. Inside, it hands parsing to the external TOML parser through from_str.

Call graph: called by 1 (enterprise_layers_precede_user_and_override_system); 1 external calls (from_str).

fn base_dir() -> AbsolutePathBuf

Purpose: Provides a fixed pretend base directory for cloud configuration tests. Using one shared path keeps the tests simple and makes expected path results stable.

Data flow: It starts from the test path /var/lib/codex, converts it into the project’s absolute-path type, and returns that value. Nothing on disk needs to exist; this is just a controlled path value for comparison.

Call relations: All tests that need a cloud configuration base directory call this helper. It relies on the test path-building helper so each test gets the same absolute path shape.

Call graph: called by 6 (enterprise_layers_precede_user_and_override_system, home_relative_path_fields_are_allowed_and_resolved, layers_are_returned_in_stack_order, raw_toml_diagnostics_use_enterprise_layer_name, relative_absolute_path_fields_resolve_against_base_dir, strict_layers_reject_unknown_config_fields); 1 external calls (test_path_buf).

fn layers_are_returned_in_stack_order()

Purpose: Checks that multiple cloud fragments come back in the order the configuration stack expects. This matters because order decides which layer has more influence when settings overlap.

Data flow: It builds two fake cloud fragments, converts them into configuration layers using the fixed base directory, then looks only at each layer’s source name. It compares those names to the expected low-priority-then-high-priority order.

Call relations: During the test, it first calls base_dir for the shared path, then exercises the cloud-fragment conversion code. It finishes by using an equality assertion to prove the produced layer order matches the intended stack order.

Call graph: calls 1 internal fn (base_dir); 2 external calls (assert_eq!, vec!).

fn strict_layers_reject_unknown_config_fields()

Purpose: Verifies that strict cloud configuration refuses fields the system does not recognize. This protects administrators from thinking a misspelled or unsupported setting is being enforced when it is actually ignored.

Data flow: It creates one fake cloud fragment containing unknown_key = true, runs the strict conversion path, and expects an error instead of layers. It then compares that error to the exact enterprise-layer error message that should be shown.

Call relations: The test calls base_dir for context, then calls the strict cloud-layer conversion function. The final assertion checks that the rejection is tied to the correct fragment id and name.

Call graph: calls 1 internal fn (base_dir); 2 external calls (assert_eq!, vec!).

fn enterprise_layers_precede_user_and_override_system()

Purpose: Tests the full priority story among system settings, enterprise-managed cloud settings, and user settings. It proves enterprise settings can override system defaults, while user settings still have the final say where allowed.

Data flow: It starts with a system configuration layer, adds two enterprise cloud layers, and then adds a user layer. It builds a ConfigLayerStack from those inputs, checks the visible layer order, and then checks the final effective configuration produced by merging all layers.

Call relations: This is the broadest test in the file. It uses base_dir and toml helpers, constructs layer entries, creates the stack, and then asserts both the ordering and the final merged result.

Call graph: calls 4 internal fn (base_dir, toml, new, new); 5 external calls (default, assert_eq!, test_path_buf, default, vec!).

fn relative_absolute_path_fields_resolve_against_base_dir()

Purpose: Checks that a relative path in a cloud configuration fragment is converted into an absolute path using the cloud base directory. This keeps managed policy files from being interpreted relative to whatever directory the program happens to run from.

Data flow: It builds a fragment whose model_instructions_file is instructions.md, converts it into layers, reads the stored path back out, and compares it with the expected path resolved against /var/lib/codex.

Call relations: The test calls base_dir, sends the fragment through the cloud-layer conversion code, and uses the shared path resolver to compute the expected answer before asserting equality.

Call graph: calls 2 internal fn (base_dir, resolve_path_against_base); 2 external calls (assert_eq!, vec!).

fn home_relative_path_fields_are_allowed_and_resolved()

Purpose: Checks that cloud configuration may use paths beginning with ~ and that they are resolved consistently. This confirms cloud config follows the same path rules as other managed configuration paths.

Data flow: It creates a fragment with model_instructions_file = "~/instructions.md", converts it into layers, extracts the stored path string, and compares it with the result of resolving that home-relative path against the test base directory.

Call relations: Like the relative-path test, it calls base_dir, runs the cloud-layer conversion, asks the absolute-path utility for the expected result, and then checks the two strings match.

Call graph: calls 2 internal fn (base_dir, resolve_path_against_base); 2 external calls (assert_eq!, vec!).

async fn raw_toml_diagnostics_use_enterprise_layer_name()

Purpose: Makes sure validation errors from enterprise cloud configuration name the enterprise layer clearly. Good diagnostics matter because an administrator or user needs to know which managed policy caused the problem.

Data flow: It creates a cloud fragment whose TOML syntax is parseable but whose model value has the wrong type. It asks the configuration diagnostic code for the first layer error, then checks that the reported path names the enterprise-managed layer and that the error points to the expected line, column, and message.

Call relations: This asynchronous test calls base_dir, creates cloud layers, then hands those layers to first_layer_config_error_from_entries for deeper validation as ConfigToml. It uses assertions to confirm the diagnostic is attached to the enterprise layer rather than to a normal file path.

Call graph: calls 1 internal fn (base_dir); 3 external calls (assert!, assert_eq!, vec!).

fn layer(id: &str, name: &str, contents: &str) -> RequirementsLayerEntry

Purpose: Builds a test requirements layer from an id, a human-readable name, and TOML text. Tests use it to avoid repeating the same setup code for enterprise-managed layers.

Data flow: It receives an id, a name, and a TOML string. It wraps the id and name into an enterprise-managed source label, then asks the production parser to turn the TOML into a RequirementsLayerEntry. The result is a ready-to-compose layer used by the tests.

Call relations: Most tests call this helper when they need one or more sample layers. It hands off to RequirementsLayerEntry::from_toml, so the tests exercise the same parsing path as real enterprise-managed configuration.

Call graph: calls 1 internal fn (from_toml).

fn compose(
    layers: Vec<RequirementsLayerEntry>,
) -> Result<Option<ConfigRequirementsToml>, RequirementsCompositionError>

Purpose: Combines test layers using the normal hostname-free composition path and returns only the plain TOML-shaped result. It keeps tests focused on the final policy values instead of source-tracking details.

Data flow: It receives a list of layer entries. It passes them to the real composer with no hostname, then converts the sourced result into ConfigRequirementsToml if any requirements are present. It returns either no requirements, a final requirements object, or a composition error.

Call relations: Many tests call this helper for ordinary layer-stacking cases. Internally it calls compose_requirements_for_hostname, then strips source metadata with into_toml so the assertion can compare plain configuration.

Call graph: called by 10 (deny_read_only_layers_do_not_leave_empty_permissions_tables, empty_layers_compose_to_none, mcp_requirements_use_regular_toml_merge, network_maps_use_regular_toml_merge, parse_error_names_layer, permissions_deny_read_unions_while_profiles_use_regular_toml_merge, regular_toml_merge_recurses_into_tables, rules_are_appended_in_priority_order, top_level_values_use_toml_priority, windows_requirements_use_regular_toml_merge); 1 external calls (compose_requirements_for_hostname).

fn compose_with_hook_directory_field(
    layers: Vec<RequirementsLayerEntry>,
    hook_directory_field: HookDirectoryField,
) -> Result<Option<ConfigRequirementsToml>, RequirementsCompositionError>

Purpose: Combines layers while telling the composer which hook directory field is active for the current platform or situation. Tests use it to check that only the active managed hook directory is treated as conflict-sensitive.

Data flow: It receives layers and a HookDirectoryField value. It calls the real hook-aware composer with no hostname, converts the result into plain TOML form if present, and returns either the composed requirements or an error.

Call relations: The hook-related tests call this helper. It delegates to compose_requirements_for_hostname_and_hook_directory, which contains the real conflict and merge behavior under test.

Call graph: called by 3 (active_windows_managed_dir_conflicts_fail_closed, hooks_append_groups_and_reject_conflicting_managed_dirs, inactive_hook_dir_conflicts_do_not_fail_composition); 1 external calls (compose_requirements_for_hostname_and_hook_directory).

fn expected_requirements(contents: impl AsRef<str>) -> ConfigRequirementsToml

Purpose: Parses a TOML snippet into the same requirements type produced by the composer, so tests can compare structured values rather than raw strings.

Data flow: It receives anything that can be viewed as text. It reads that text as TOML and returns a ConfigRequirementsToml value, failing the test immediately if the expected TOML itself is invalid.

Call relations: Assertion-heavy tests use this helper to build the expected answer. It relies on toml::from_str, so both expected and actual values are compared as parsed configuration, not as formatting-sensitive text.

Call graph: 2 external calls (as_ref, from_str).

fn empty_layers_compose_to_none()

Purpose: Checks that composing no layers produces no requirements at all. This matters because an empty policy stack should not invent a default requirements object.

Data flow: It starts with an empty list. The list is passed through the compose helper, and the test expects the result to be None. Nothing else is changed.

Call relations: This is a basic boundary test for compose. It shows that compose_requirements_for_hostname treats an empty input as absence of policy, not as an empty but present policy.

Call graph: calls 1 internal fn (compose); 2 external calls (new, assert_eq!).

fn top_level_values_use_toml_priority()

Purpose: Checks that simple top-level settings from a higher-priority layer override lower-priority settings. It also verifies that map-like settings keep keys from lower layers unless a higher layer replaces the same key.

Data flow: It creates a low layer and a high layer with conflicting approval, sandbox, permission, and remote-control values. After composition, the high layer’s direct values are present, while the allowed permission profiles table contains a careful merge of high and low keys.

Call relations: This test calls compose through the helper layer setup. It confirms the basic priority rule used by the broader requirements composition system.

Call graph: calls 1 internal fn (compose); 2 external calls (assert_eq!, vec!).

fn composition_strategy_applies_to_non_cloud_layers()

Purpose: Checks that the same merging rules apply to configuration from non-cloud sources, such as managed device preferences and system files. This prevents local administrator policy sources from behaving differently from enterprise cloud policy.

Data flow: It builds one system-file layer and one managed-device-preferences layer. The composer combines top-level values, feature flags, command rules, and denied read paths. The test then checks both the final plain TOML and the source labels on selected values.

Call relations: This test calls compose_requirements_for_hostname directly because it needs the source-aware result, not just plain TOML. It proves that source tracking and merge priority still work when layers do not come from the usual enterprise-managed helper.

Call graph: calls 1 internal fn (from_absolute_path); 4 external calls (assert_eq!, cfg!, compose_requirements_for_hostname, vec!).

fn single_regular_layer_keeps_enterprise_managed_source()

Purpose: Checks that a value from one enterprise-managed layer remembers where it came from. This is useful for diagnostics, audits, and error messages.

Data flow: It creates one layer that sets allow_managed_hooks_only. After composing, it inspects the sourced field and expects both the boolean value and the enterprise source id and name to be preserved.

Call relations: This test calls compose_requirements_for_hostname directly so it can inspect source metadata. It depends on the layer helper to create the enterprise-managed source.

Call graph: 3 external calls (assert_eq!, compose_requirements_for_hostname, vec!).

fn regular_toml_merge_recurses_into_tables()

Purpose: Checks that nested TOML tables are merged inside their sub-sections instead of being replaced wholesale. This lets a high layer override one nested value without deleting unrelated lower-layer settings.

Data flow: It creates low and high layers with overlapping feature flags and app connector settings. Composition keeps lower-only entries, replaces shared entries with high-priority values, and preserves nested tool settings that the high layer did not mention.

Call relations: This test uses compose and expected_requirements. It exercises the general recursive table-merge behavior that many requirement sections depend on.

Call graph: calls 1 internal fn (compose); 2 external calls (assert_eq!, vec!).

fn merged_table_source_is_composite_in_priority_order()

Purpose: Checks that when a final table contains values from multiple layers, its source is recorded as a composite source in priority order. This makes it clear that the resulting table is not owned by only one layer.

Data flow: It builds separate low and high sources, each contributing one feature flag. After composition, the feature requirements contain both flags and a source label made from high source followed by low source.

Call relations: This test calls compose_requirements_for_hostname directly to inspect sourced data. It verifies that merge behavior and source reporting stay aligned.

Call graph: 3 external calls (assert_eq!, compose_requirements_for_hostname, vec!).

fn mcp_requirements_use_regular_toml_merge()

Purpose: Checks that MCP server requirements use the ordinary nested TOML merge rules. MCP servers are external tool servers, and their identity settings should merge predictably with layer priority.

Data flow: It creates a low layer with one shared MCP server and one low-only server, then a high layer that changes the shared server command. Composition keeps the low-only server and uses the high command for the shared server.

Call relations: This test uses the compose helper. It connects MCP-specific configuration to the same merge behavior tested for other nested tables.

Call graph: calls 1 internal fn (compose); 2 external calls (assert_eq!, vec!).

fn network_maps_use_regular_toml_merge()

Purpose: Checks that experimental network allow/deny maps merge by key. This matters because a higher layer should be able to override one domain or socket without erasing unrelated network rules.

Data flow: It creates low and high layers with domain decisions and Unix socket decisions. Composition keeps unique entries from both layers and uses high-priority values where the same domain or socket appears twice.

Call relations: This test calls compose and compares against parsed expected requirements. It verifies that network policy maps follow the general table-merge model.

Call graph: calls 1 internal fn (compose); 2 external calls (assert_eq!, vec!).

fn windows_requirements_use_regular_toml_merge()

Purpose: Checks that the Windows-specific requirements table follows the normal merge rules. In this case, the higher-priority allowed sandbox implementation replaces the lower one.

Data flow: It creates a low layer allowing one Windows sandbox implementation and a high layer allowing another. Composition returns the high layer’s allowed implementation in the Windows section.

Call relations: This test uses compose. It anchors platform-specific configuration to the same priority behavior as the rest of the requirements system.

Call graph: calls 1 internal fn (compose); 2 external calls (assert_eq!, vec!).

fn remote_sandbox_config_is_applied_per_layer()

Purpose: Checks that hostname-specific remote sandbox settings are applied when the current machine name matches. This lets organizations set different sandbox rules for different classes of machines.

Data flow: It creates a low general sandbox rule and a high remote sandbox rule that matches a build-machine hostname pattern. The composer receives a mixed-case hostname with a trailing dot, normalizes/matches it, and the high remote sandbox value becomes the final setting.

Call relations: This test calls compose_requirements_for_hostname directly because hostname matching is part of the behavior under test. It shows that matching remote sandbox entries participate in normal priority composition.

Call graph: 3 external calls (assert_eq!, compose_requirements_for_hostname, vec!).

fn unmatched_remote_sandbox_config_does_not_shadow_lower_layers()

Purpose: Checks that a remote sandbox block that does not match the current hostname does not erase lower-priority settings. A non-matching special case should behave as if it was not present.

Data flow: It creates a low general sandbox rule and a high remote sandbox rule for a different hostname pattern. The composer receives a hostname that does not match the high rule, so the low layer’s sandbox mode remains in the final output.

Call relations: This test calls compose_requirements_for_hostname directly. It complements the matching-hostname test by checking the safe non-match path.

Call graph: 3 external calls (assert_eq!, compose_requirements_for_hostname, vec!).

fn hostname_resolver_is_not_called_without_remote_sandbox_config()

Purpose: Checks that the composer does not ask for the machine hostname when no layer needs hostname-based selection. This avoids unnecessary work and avoids depending on hostname lookup when it cannot affect the result.

Data flow: It sets up a counter and a hostname resolver closure that would increment that counter if called. The only layer has a normal sandbox setting, so composition succeeds, the counter stays at zero, and the normal setting appears in the result.

Call relations: This test calls compose_requirements_with_hostname_resolver directly. It verifies lazy behavior: the resolver is only used when remote sandbox configuration exists.

Call graph: 4 external calls (default, assert_eq!, compose_requirements_with_hostname_resolver, vec!).

fn hostname_resolver_is_called_once_for_multiple_remote_sandbox_layers()

Purpose: Checks that hostname lookup is shared across multiple remote sandbox layers. The composer should not repeatedly ask for the same hostname while processing one stack.

Data flow: It creates two layers with hostname-based sandbox settings and a resolver that counts calls. Composition uses the resolver once, matches both layers, and the higher-priority sandbox mode becomes the final value.

Call relations: This test calls compose_requirements_with_hostname_resolver directly. It proves the composer caches or otherwise reuses the resolved hostname during one composition pass.

Call graph: 4 external calls (default, assert_eq!, compose_requirements_with_hostname_resolver, vec!).

fn rules_are_appended_in_priority_order()

Purpose: Checks that command prefix rules are collected rather than overwritten, with higher-priority rules placed first. This order matters because earlier policy rules may be checked before later ones.

Data flow: It creates a low layer with an npm rule and a high layer with a git rule. After composition, both rules are present, and the high layer’s git rule appears before the low layer’s npm rule.

Call relations: This test uses compose. It verifies the special list-combining behavior for rules, which differs from simple scalar overriding.

Call graph: calls 1 internal fn (compose); 2 external calls (assert_eq!, vec!).

fn hooks_append_groups_and_reject_conflicting_managed_dirs()

Purpose: Checks two hook behaviors: hook groups are appended in priority order, and conflicting active managed hook directories cause composition to fail closed. "Fail closed" means refusing the configuration rather than choosing a potentially unsafe path.

Data flow: First it composes two layers with the same managed hook directory and different hook groups; the final TOML keeps the shared directory and includes both hook groups with the high group first. Then it composes two layers with different active managed directories; the result is an error that names the field and both conflicting layers.

Call relations: This test uses compose_with_hook_directory_field because the active hook directory field is central to the check. It exercises both successful hook merging and the error path for dangerous directory disagreement.

Call graph: calls 1 internal fn (compose_with_hook_directory_field); 3 external calls (assert!, assert_eq!, vec!).

fn active_windows_managed_dir_conflicts_fail_closed()

Purpose: Checks that conflicting active Windows managed hook directories also cause composition to fail closed. This keeps Windows hook policy from silently choosing one managed directory over another.

Data flow: It creates two layers with different hooks.windows_managed_dir values and marks the Windows managed directory field as active. Composition returns an error, and the test checks that the message names the field and both layers.

Call relations: This test calls compose_with_hook_directory_field. It is the Windows counterpart to the managed_dir conflict check.

Call graph: calls 1 internal fn (compose_with_hook_directory_field); 2 external calls (assert!, vec!).

fn inactive_hook_dir_conflicts_do_not_fail_composition()

Purpose: Checks that conflicts in the inactive hook directory field do not block composition. Only the directory field that matters for the current platform is treated as safety-critical.

Data flow: It runs two scenarios. In one, managed_dir is active, so differing windows_managed_dir values are allowed while hooks merge normally. In the other, windows_managed_dir is active, so differing managed_dir values are allowed. Each scenario produces a final requirements object with hook groups in priority order and regular TOML priority for the inactive field.

Call relations: This test calls compose_with_hook_directory_field for both active-field choices. It completes the hook-directory conflict story by showing which conflicts are ignored and why.

Call graph: calls 1 internal fn (compose_with_hook_directory_field); 2 external calls (assert_eq!, vec!).

fn permissions_deny_read_unions_while_profiles_use_regular_toml_merge()

Purpose: Checks that filesystem deny-read paths are unioned, while permission profile tables still use normal TOML merging. This is important because deny-read paths protect secrets and should not disappear just because a higher layer lists fewer paths.

Data flow: It chooses platform-appropriate path strings, then creates low and high layers. The final filesystem deny_read list contains every unique denied path, while the managed-standard permission profile combines fields with high-priority values overriding matching lower fields.

Call relations: This test uses compose. It verifies a special safety-oriented merge rule for deny_read alongside ordinary profile merging in the same permissions section.

Call graph: calls 1 internal fn (compose); 3 external calls (assert_eq!, cfg!, vec!).

fn deny_read_only_layers_do_not_leave_empty_permissions_tables()

Purpose: Checks that a layer containing only filesystem deny-read settings produces a clean permissions section, not extra empty tables. This keeps the generated requirements clear and avoids misleading empty configuration.

Data flow: It creates one layer with only a deny_read path. After composition, the expected output contains exactly the filesystem deny_read table and no unrelated empty permissions tables.

Call relations: This test calls compose and compares the plain TOML-shaped result. It focuses on output shape after the special deny_read merge logic runs.

Call graph: calls 1 internal fn (compose); 3 external calls (assert_eq!, cfg!, vec!).

fn parse_error_names_layer()

Purpose: Checks that invalid TOML content produces an error message that identifies the bad layer. This makes administrator mistakes much easier to find and fix.

Data flow: It creates one layer with an invalid value type for allowed_approval_policies. Composition fails, and the test checks that the error text includes both the layer name/id and the problematic field.

Call relations: This test uses compose to trigger the normal parsing and composition path. It verifies that errors coming from layer parsing are wrapped with useful source context.

Call graph: calls 1 internal fn (compose); 2 external calls (assert!, vec!).

fn deserialize_skill_config_with_name_selector()

Purpose: This test proves that a skill can be configured by name in TOML text. It also checks that disabling the skill in the text file is preserved in the resulting configuration.

Data flow: It starts with a small TOML snippet containing a skill name and enabled = false. That text is parsed into a SkillConfig. The test then checks that the name was stored, no path was set, and the skill is marked as disabled.

Call relations: During the test run, the Rust test framework calls this function. The function relies on TOML parsing to build the config object, then uses assertions to confirm the parsed result matches the expected name-based skill selection.

Call graph: 3 external calls (assert!, assert_eq!, from_str).

fn deserialize_skill_config_with_path_selector()

Purpose: This test proves that a skill can be configured by a local file path instead of by name. It checks that the path is converted into the project’s absolute-path type, which helps prevent later ambiguity about where the file is.

Data flow: It creates a temporary directory, builds a pretend path to a SKILL.md file, and inserts that path into TOML text. The TOML is parsed into a SkillConfig. The test compares the result with the exact expected configuration: path filled in, name empty, and enabled set to false.

Call relations: The test framework calls this function as part of the configuration test suite. It uses a temporary directory so the path is real enough for path conversion, then hands the TOML text to the parser and checks the final SkillConfig against a manually built expected value.

Call graph: 4 external calls (assert_eq!, format!, tempdir, from_str).

fn memories_config_clamps_count_limits_to_nonzero_values()

Purpose: This test checks that memory-related count limits cannot become zero after configuration is cleaned up. That matters because a zero count could stop useful work from happening at all.

Data flow: It starts with a raw MemoriesToml value where two count settings are explicitly set to zero. That raw value is converted into a final MemoriesConfig. The test then checks that both zero values were raised to one, while all other settings stayed at their defaults.

Call relations: The test framework calls this function when running config tests. The function exercises the conversion from raw TOML-shaped data into the safer runtime configuration, then verifies the conversion enforces minimum usable values.

Call graph: calls 1 internal fn (from); 2 external calls (default, assert_eq!).

fn memories_config_clamps_rate_limit_remaining_threshold()

Purpose: This test checks that a memory configuration percentage is kept between 0 and 100. This prevents impossible settings, such as requiring 101 percent of a rate limit to remain.

Data flow: It first builds raw memory settings with the percentage set to 101, converts them into the final config, and checks that the value becomes 100. Then it repeats the same process with -1 and checks that the value becomes 0. Other settings are expected to remain at their defaults.

Call relations: The test framework calls this function during the configuration test run. It focuses on the cleanup step that turns user-provided memory settings into safe runtime values, verifying both the upper and lower boundaries.

Call graph: calls 1 internal fn (from); 2 external calls (default, assert_eq!).

fn parse_toml(value: &str) -> TomlValue

Purpose: This small helper turns a TOML text snippet into the in-memory TOML value used by the tests. It keeps the test cases short and makes each test focus on the merge behavior instead of parsing setup.

Data flow: It receives a string containing TOML text. It asks the TOML parser to read that string, and if parsing fails it stops the test with a clear message. On success, it returns a TomlValue that the test can pass into the merge code or compare against an expected result.

Call relations: All four tests call this helper when they need a base layer, an overlay layer, or an expected merged TOML value. The helper delegates the actual reading to the external TOML parser, so the tests can speak in realistic TOML snippets rather than manually building every nested value.

Call graph: called by 4 (merge_toml_values_normalizes_legacy_key_from_base_layer, merge_toml_values_normalizes_legacy_key_from_overlay_layer, merge_toml_values_normalizes_permission_network_domains_before_overlaying, merge_toml_values_prefers_canonical_key_when_one_layer_has_both_names); 1 external calls (from_str).

fn merge_toml_values_normalizes_legacy_key_from_base_layer()

Purpose: This test proves that an old memories setting name in the base configuration is converted to the current setting name when another layer is merged over it. This protects users who still have the old key in an older config file.

Data flow: It starts with a base TOML layer that uses the legacy key, and an overlay layer that uses the newer key. After merging, it expects the result to contain only the newer key with the overlay value. It then converts the merged value into ConfigToml and checks that the real memories setting is set to true.

Call relations: The test uses parse_toml to create its input and expected TOML values, then runs the configuration merge being tested. It finishes with equality checks so the test runner can catch both a wrong TOML shape and a wrong deserialized configuration value.

Call graph: calls 1 internal fn (parse_toml); 1 external calls (assert_eq!).

fn merge_toml_values_normalizes_legacy_key_from_overlay_layer()

Purpose: This test checks the opposite layering case: the base uses the current memories setting name, while the overlay still uses the old name. It makes sure an older overlay file can still override the modern setting correctly.

Data flow: It builds a base layer where the current key is false and an overlay where the legacy key is true. After merging, the expected output keeps only the current key and sets it to true. The test also turns the merged TOML into ConfigToml to confirm the program will read the final value as the current memories option.

Call relations: Like the other merge tests, it relies on parse_toml for readable TOML fixtures and uses equality assertions to verify the outcome. It exercises the merge path where the later layer must be normalized before it can correctly replace the earlier value.

Call graph: calls 1 internal fn (parse_toml); 1 external calls (assert_eq!).

fn merge_toml_values_prefers_canonical_key_when_one_layer_has_both_names()

Purpose: This test makes sure that if a single layer contains both the new and old names for the same memories setting, the new official name wins. That prevents an obsolete duplicate key from overriding the value the user put under the current name.

Data flow: It starts with an empty TOML table as the base. The overlay contains both the current key set to true and the legacy key set to false. After merging, the expected result contains only the current key with the true value.

Call relations: This test creates an empty TOML table directly, then uses parse_toml for the overlay and expected result. It checks the final merged TOML with an equality assertion, focusing on the cleanup rule that removes the legacy duplicate and keeps the canonical, meaning official, key.

Call graph: calls 1 internal fn (parse_toml); 3 external calls (Table, assert_eq!, new).

fn merge_toml_values_normalizes_permission_network_domains_before_overlaying()

Purpose: This test verifies that network permission domain names are normalized before layers are combined. In practice, it means "EXAMPLE.COM" and "example.com" are treated as the same domain, as they should be on the internet.

Data flow: It creates a base permission rule that denies example.com and an overlay rule that allows EXAMPLE.COM. During merging, the domain name should be lowercased before deciding whether the overlay replaces the base rule. The final expected TOML has one entry, example.com, with the overlay value allow.

Call relations: The test uses parse_toml to build the base, overlay, and expected permission tables. It then checks the merged value with an equality assertion, confirming that normalization happens early enough for the overlay rule to replace the matching base rule rather than creating a second differently-cased entry.

Call graph: calls 1 internal fn (parse_toml); 1 external calls (assert_eq!).

fn ignored_toml_field_errors_accept_non_file_source_names()

Purpose: This test checks that strict config errors work even when the configuration source is not a normal file path. That is useful for configs passed through another channel, such as an encoded string, while still giving a clear source name in the error.

Data flow: It starts with a made-up source name and TOML text containing a valid model setting plus an unknown unknown_key. The TOML text is parsed, then passed to the strict unknown-field checker. The test expects one error to come out, pointing at unknown_key with the custom source name preserved.

Call relations: During the test run, the Rust test harness runs this function. The function relies on the strict config checker to produce an error, then uses assert_eq! to compare that actual error with the exact error it should have produced.

Call graph: 1 external calls (assert_eq!).

fn type_errors_take_precedence_over_ignored_fields()

Purpose: This test proves that type mistakes are reported before unknown setting names. In human terms, if one setting is shaped wrong and another is unknown, the parser should first explain the concrete value problem it hit.

Data flow: It gives the checker a fake /tmp/config.toml path and TOML text where model_context_window is wrongly written as the string "wide" instead of a number, while unknown_key is also present. The checker returns an error. The test verifies that the returned error points to "wide" and says a number was expected, rather than complaining first about the unknown key.

Call relations: The test harness calls this function as part of the config test suite. Inside, it asks the strict config helper for the first error, builds the expected ConfigError using new, and uses assert_eq! to confirm the helper chose the right error priority.

Call graph: 2 external calls (new, assert_eq!).

fn strict_config_rejects_unknown_feature_key()

Purpose: This test checks that unknown keys inside the top-level [features] section are rejected. It prevents users from thinking they enabled a feature when they actually typed a feature name the program does not know.

Data flow: It creates TOML text with a [features] table containing foo = true. The strict checker reads that text and should return an error because foo is not a known feature flag. The test compares the result with an expected error that points at foo and names it as features.foo.

Call relations: The Rust test runner invokes this function. The function sends a small config snippet through the strict validation path, creates the expected error with new, and then uses assert_eq! to make sure the produced message and text location match exactly.

Call graph: 2 external calls (new, assert_eq!).

fn strict_config_rejects_unknown_profile_feature_key()

Purpose: This test checks the same unknown-feature behavior inside a named profile. Profiles are alternate sets of settings, so strict checking must still catch bad feature names there.

Data flow: It starts with TOML text under [profiles.work.features] containing foo = true. The strict checker examines the nested profile feature table and returns an error. The expected output is an error pointing at foo and spelling out the full setting path: profiles.work.features.foo.

Call relations: When the test suite runs, this function exercises the profile-specific branch of strict config validation. It constructs the expected ConfigError with new and uses assert_eq! to verify the actual error has the right path, location, and message.

Call graph: 2 external calls (new, assert_eq!).

fn strict_config_accepts_opaque_desktop_keys()

Purpose: This test confirms that the desktop config section is allowed to contain keys this strict checker does not understand. That exception lets desktop-specific settings pass through without forcing the shared config parser to know every desktop detail.

Data flow: It provides TOML text with a [desktop] table and a nested [desktop.workspace] table, containing keys such as appearanceTheme and collapsed. The strict checker reads the config and should return no error. The test verifies that the result is None, meaning nothing was rejected.

Call relations: The test harness runs this function with the rest of the strict config tests. Unlike the rejection tests, this one expects the validation helper to stay quiet, and it uses assert_eq! to confirm that no error was returned.

Call graph: 2 external calls (new, assert_eq!).

fn hooks_file_deserializes_existing_json_shape()

Purpose: This test proves that the existing JSON hook file format is still accepted. It uses a realistic hook that runs a command before Bash is used, including a timeout and a status message.

Data flow: It starts with a JSON string shaped like a hooks file. The JSON parser reads that text into a HooksFile value. The test then compares the result with the exact expected structure: one PreToolUse matcher group containing one command hook with its command, timeout, async flag, and status message filled in.

Call relations: The Rust test runner calls this test during the test suite. Inside the test, serde_json::from_str does the reading, and assert_eq! checks that the parsed result matches the expected configuration exactly.

Call graph: 2 external calls (assert_eq!, from_str).

fn hooks_file_rejects_events_outside_hooks_object()

Purpose: This test makes sure JSON hook events are not accepted when they appear in the wrong place. It protects against confusing or accidentally permissive configuration files.

Data flow: It starts with JSON where SessionStart is placed at the top level instead of inside the expected hooks object. The parser is expected to fail. The test then inspects the error text and checks that it complains about the unknown SessionStart field.

Call relations: The Rust test runner calls this test as part of parser validation. The test relies on JSON deserialization to produce an error, then uses assert! to confirm the error is the kind the project expects.

Call graph: 1 external calls (assert!).

fn hook_events_deserialize_from_toml_arrays_of_tables()

Purpose: This test checks that hook events can be written in TOML using arrays of tables, a common TOML style for repeated sections. It confirms that a readable TOML hook definition becomes the right event structure.

Data flow: It begins with TOML text containing a PreToolUse section and one nested hook command. The TOML parser turns that text into a HookEventsToml value. The test compares it with the expected structure: a Bash matcher and a command hook with timeout and status message preserved.

Call relations: The Rust test runner invokes this test. The test hands the TOML sample to toml::from_str, then uses assert_eq! to verify that the parser and the hook data model agree on the meaning of the file.

Call graph: 2 external calls (assert_eq!, from_str).

fn hooks_toml_deserializes_inline_events_and_state_map()

Purpose: This test verifies that a full TOML hooks file can contain both hook definitions and saved hook state. The state records things like whether a hook is enabled and which command hash is trusted.

Data flow: It starts with TOML that includes a state entry keyed by a hook identifier, plus an inline PreToolUse hook definition. The TOML parser reads it into a HooksToml value. The test checks that the events land in the events field and the state entry lands in the state map with enabled and trusted_hash values intact.

Call relations: The Rust test runner calls this test when tests run. It uses toml::from_str to translate text into structured data, BTreeMap to express the expected ordered map, and assert_eq! to confirm the whole combined file is read correctly.

Call graph: 2 external calls (assert_eq!, from_str).

fn managed_hooks_requirements_flatten_hook_events()

Purpose: This test checks the TOML format for managed hook requirements, such as enterprise-controlled hook directories. It confirms that directory settings and hook events can live together in one requirements file.

Data flow: It starts with TOML containing a managed_dir path and a PreToolUse command hook. The TOML parser reads this into ManagedHooksRequirementsToml. The test expects the managed directory to become a PathBuf, the Windows directory field to remain empty, and the hook event to appear under the hooks field.

Call relations: The Rust test runner invokes this test. The test uses toml::from_str for parsing and assert_eq! to prove the flattened TOML event sections are collected into the managed requirements structure correctly.

Call graph: 2 external calls (assert_eq!, from_str).

fn hook_events_deserialize_windows_override_from_toml()

Purpose: This test proves that a hook command can include a Windows-specific replacement command using the snake_case field name command_windows. This lets one hook definition work across operating systems.

Data flow: It begins with TOML containing a normal Unix-style command and a command_windows override. The TOML parser turns the text into HookEventsToml. The test checks that the main command remains unchanged and the Windows command is stored separately in command_windows.

Call relations: The Rust test runner calls this test. It delegates the text reading to toml::from_str, then assert_eq! verifies that the Windows override is accepted and attached to the command hook.

Call graph: 2 external calls (assert_eq!, from_str).

fn hook_events_deserialize_camel_case_windows_override_from_toml()

Purpose: This test confirms that the Windows-specific command override is also accepted with the camelCase field name commandWindows. That keeps the configuration forgiving for users or tools that use camelCase naming.

Data flow: It starts with TOML containing a base command and a commandWindows override. The TOML parser reads it into HookEventsToml. The test checks that the parsed command hook has the same command_windows value as the snake_case version would have produced.

Call relations: The Rust test runner invokes this test along with the other parser tests. It uses toml::from_str to parse the sample and assert_eq! to confirm that the alias field name feeds into the same internal setting.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_stdio_command_server_config()

Purpose: Checks the simplest command-based MCP server configuration: a TOML file with only a command. It proves that the parser fills in safe defaults for everything else.

Data flow: A short TOML string with command = "echo" goes in. The TOML parser turns it into an McpServerConfig, and the test compares the result with the expected standard-input/output transport, no arguments, no environment overrides, enabled by default, not required, and no tool filters. The output is a passing test if all defaults are correct.

Call relations: The Rust test runner calls this test. Inside it, from_str does the real parsing work, and the assertions verify that the configuration model received exactly the values later code would rely on.

Call graph: 3 external calls (assert!, assert_eq!, from_str).

fn deserialize_stdio_command_server_config_with_args()

Purpose: Checks that command-line arguments in TOML are preserved for a command-based MCP server. This matters because many local MCP servers need extra words after the command to start correctly.

Data flow: A TOML snippet containing a command and an args list goes in. The parser builds an McpServerConfig, and the test checks that the transport is standard-input/output with echo plus the two arguments hello and world. The test also confirms the server is still enabled by default.

Call relations: The test runner invokes it as part of the configuration test suite. It relies on from_str to exercise the same deserialization path used by real config loading, then uses equality checks to catch any change in argument handling.

Call graph: 3 external calls (assert!, assert_eq!, from_str).

fn deserialize_remote_stdio_server_requires_absolute_cwd()

Purpose: Verifies that a remote command-based MCP server must have a clear, absolute working directory. This avoids ambiguity about where the command should run on a remote machine.

Data flow: Two invalid TOML snippets go in: one with a remote environment but no cwd, and one with a relative cwd. Each parse is expected to fail. The test then reads the error text and checks that it explains the missing or non-absolute working directory problem.

Call relations: The test runner calls this when checking validation rules. It does not pass data to another project function directly; instead, it depends on the parser returning errors, and the assertions make sure those errors are specific enough to help users.

Call graph: 1 external calls (assert!).

fn deserialize_remote_stdio_server_accepts_absolute_cwd()

Purpose: Checks the matching valid case for remote command servers: an absolute working directory is accepted. This proves the rule is not too strict.

Data flow: The test asks the operating system for a temporary directory path, formats it into TOML as cwd, and parses that TOML. If parsing fails, the test panics with a clear message. If parsing succeeds, it checks that the resulting config stores the same absolute path in the standard-input/output transport.

Call relations: The test runner calls it after setup by the normal test framework. It uses temp_dir and format! to build realistic input, sends that input through from_str, and uses an equality assertion to verify the accepted configuration.

Call graph: 5 external calls (assert_eq!, format!, panic!, temp_dir, from_str).

fn deserialize_stdio_command_server_config_with_arg_with_args_and_env()

Purpose: Checks that a command-based MCP server can include both command-line arguments and fixed environment variables. Environment variables are name-value settings passed to the child process when it starts.

Data flow: A TOML string with command, args, and an env table goes in. The parser turns it into an McpServerConfig, and the test confirms that the command, argument list, and FOO=BAR environment map all land in the standard-input/output transport. The result is a passing test if no information is lost.

Call relations: The test runner calls this case. It exercises from_str and then uses assertions to make sure process-launch settings are grouped under the correct transport type.

Call graph: 3 external calls (assert!, assert_eq!, from_str).

fn deserialize_stdio_command_server_config_with_env_vars()

Purpose: Checks the legacy shorthand for passing through environment variable names to a command-based MCP server. Instead of giving values in the config, the server can ask to copy named variables from the surrounding environment.

Data flow: A TOML snippet with env_vars = ["FOO", "BAR"] goes in. The parser creates a config where those two names are stored as environment-variable requests, with no fixed env map and no arguments. The output is verified by comparing the whole transport value.

Call relations: The test runner invokes it with the rest of the MCP config tests. It calls from_str to use the real parser and hands the parsed result to an equality assertion.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_stdio_command_server_config_with_env_var_sources()

Purpose: Checks the newer, more detailed environment-variable format, where each variable can say where its value should come from. It also confirms the older plain-string format still works.

Data flow: A TOML list containing one plain variable name and two structured variable entries goes in. The parser converts the plain string into a simple name entry, and converts the structured entries into configs with local and remote sources. The test compares the full resulting list to the expected mixed format.

Call relations: The test runner calls this as a compatibility and feature test. It relies on from_str to interpret both old and new shapes, then uses equality checking to ensure downstream code will see a consistent internal form.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_stdio_command_server_config_rejects_unknown_env_var_source()

Purpose: Checks that only supported environment-variable sources are accepted. This prevents a misspelled or invented source from silently doing the wrong thing.

Data flow: A TOML snippet asks for an environment variable source named elsewhere. Parsing is expected to fail. The test reads the error message and checks that it mentions the unsupported source value.

Call relations: The test runner calls this negative test. The parser is expected to stop the bad configuration, and the assertion checks that the error is understandable rather than vague.

Call graph: 1 external calls (assert!).

fn deserialize_stdio_command_server_config_with_cwd()

Purpose: Checks that a command-based MCP server can set its working directory. The working directory is the folder the command starts in, like choosing the folder before running a terminal command.

Data flow: A TOML snippet with cwd = "/tmp" goes into the parser. The resulting config should contain a standard-input/output transport whose cwd field is the path /tmp. The test output is simply pass or fail based on that equality check.

Call relations: The test runner invokes it. It uses from_str to parse the same TOML syntax users write, then confirms the path is stored where process-starting code will later look for it.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_disabled_server_config()

Purpose: Checks that an MCP server can be explicitly turned off in configuration. This lets users keep a server entry around without starting it.

Data flow: A TOML snippet with a command and enabled = false goes in. The parser creates a config, and the test confirms enabled is false while required remains false. The result is a passing test if disabling does not accidentally make the server required.

Call relations: The test runner calls it during config tests. It sends the input through from_str and uses assertions to check the boolean flags that later startup code will consult.

Call graph: 2 external calls (assert!, from_str).

fn deserialize_required_server_config()

Purpose: Checks that an MCP server can be marked as required. A required server is one the application may treat as important enough that failure to start should matter.

Data flow: A TOML snippet with required = true is parsed into an McpServerConfig. The test checks that the resulting required field is true. Nothing else is changed outside the test.

Call relations: The test runner invokes this test. It calls from_str for real parsing and then checks the specific flag used by later orchestration code.

Call graph: 2 external calls (assert!, from_str).

fn deserialize_streamable_http_server_config()

Purpose: Checks the simplest remote HTTP MCP server configuration: a TOML file with just a URL. It proves that a URL selects the HTTP transport and that optional HTTP fields default to empty.

Data flow: A TOML string with url = "https://example.com/mcp" goes in. The parser creates a config whose transport is streamable HTTP, with no bearer-token environment variable and no header maps. The test also confirms the server is enabled by default.

Call relations: The test runner calls this case. It uses from_str to choose the transport from the TOML fields, then assertions confirm that later networking code would see an HTTP endpoint.

Call graph: 3 external calls (assert!, assert_eq!, from_str).

fn deserialize_streamable_http_server_config_with_env_var()

Purpose: Checks that an HTTP MCP server can name an environment variable containing its bearer token. A bearer token is a secret string used to prove the client is allowed to connect.

Data flow: A TOML snippet with a URL and bearer_token_env_var = "GITHUB_TOKEN" goes in. The parser stores the URL and the token variable name in the HTTP transport, without reading the secret itself. The test confirms those exact fields.

Call relations: The test runner invokes it. from_str parses the user-facing config, and the assertions verify that secret lookup is deferred to runtime by storing only the environment-variable name.

Call graph: 3 external calls (assert!, assert_eq!, from_str).

fn deserialize_streamable_http_server_config_with_headers()

Purpose: Checks that HTTP MCP servers can include fixed request headers and headers whose values come from environment variables. Headers are extra named values sent with web requests.

Data flow: A TOML snippet provides a URL, one fixed header, and one environment-backed header. The parser builds an HTTP transport with two optional maps: one mapping X-Foo to bar, and one mapping X-Token to the environment variable TOKEN_ENV. The test compares those maps with the expected result.

Call relations: The test runner calls it. It exercises the HTTP-specific part of from_str, then uses equality checking so later request-building code can depend on these header fields being shaped correctly.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_streamable_http_server_config_with_oauth_resource()

Purpose: Checks that an HTTP MCP server can declare an OAuth resource. OAuth is a common web sign-in and authorization system; the resource says what service the authorization is for.

Data flow: A TOML snippet with a URL and oauth_resource goes into the parser. The resulting server config should store that resource string at the top level. The test compares the stored value with the expected URL.

Call relations: The test runner invokes it. It calls from_str and checks the field that later OAuth setup code can use when requesting or validating authorization.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_streamable_http_server_config_with_oauth_client_id()

Purpose: Checks that an HTTP MCP server can include an OAuth client ID in a nested oauth section. The client ID identifies this application to the authorization service.

Data flow: A TOML snippet with a URL and an [oauth] table containing client_id goes in. The parser creates an McpServerOAuthConfig with that client ID and attaches it to the server config. The test confirms the nested structure is read correctly.

Call relations: The test runner calls this test. It sends nested TOML through from_str, then asserts that the OAuth configuration is available in the form later authentication code expects.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_server_config_with_tool_filters()

Purpose: Checks that a server can list tools to allow and tools to block. This gives users a way to limit what an MCP server may expose.

Data flow: A TOML snippet with enabled_tools = ["allowed"] and disabled_tools = ["blocked"] goes in. The parser turns those lists into optional string lists on the server config. The test checks both lists exactly.

Call relations: The test runner invokes it as part of feature-specific config coverage. It relies on from_str, then verifies the fields that tool-selection logic will later read.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_server_config_with_parallel_tool_calls()

Purpose: Checks that a server can declare support for running multiple tool calls at the same time. This matters for performance, but only servers that safely support it should opt in.

Data flow: A TOML snippet sets supports_parallel_tool_calls = true. The parser fills the server config, and the test checks that the corresponding boolean is true. The test has no outside side effects.

Call relations: The test runner calls it. It uses from_str to exercise config loading and then checks the flag that later tool-running code can use to decide whether parallel calls are allowed.

Call graph: 2 external calls (assert!, from_str).

fn deserialize_server_config_with_default_tool_approval_mode()

Purpose: Checks approval settings for tools, both a default setting and a per-tool override. Approval mode controls whether a tool call is automatically allowed or should ask the user first.

Data flow: A TOML snippet sets default_tools_approval_mode = "approve" and gives the search tool approval_mode = "prompt". The parser creates the config, and the test checks both the default and the specific tool entry. It then serializes the config back to TOML, checks the text contains the default setting, parses it again, and confirms the round-tripped config is identical.

Call relations: The test runner invokes it. It calls from_str to read TOML, to_string to write TOML, then from_str again to prove that reading and writing cooperate without changing approval behavior.

Call graph: 4 external calls (assert!, assert_eq!, from_str, to_string).

fn serialize_round_trips_server_config_with_parallel_tool_calls()

Purpose: Checks that parallel-tool-call support and a tool timeout survive being written back to TOML and read again. This guards against serialization accidentally dropping newer fields.

Data flow: A TOML snippet with a command, supports_parallel_tool_calls = true, and tool_timeout_sec = 2.0 goes in. The parser builds a config, the serializer turns it back into TOML text, and the test checks that the parallel flag appears in the text. The text is parsed again, and the final config must equal the original.

Call relations: The test runner calls this round-trip test. It links from_str and to_string in the same way a config editor or persistence feature might, proving they agree on these fields.

Call graph: 4 external calls (assert!, assert_eq!, from_str, to_string).

fn deserialize_ignores_unknown_server_fields()

Purpose: Checks that unknown fields in a server config are ignored rather than causing failure. This can help compatibility when configs contain fields from another version or another tool.

Data flow: A TOML snippet includes a normal command plus an unknown trust_level field. The parser creates a config instead of rejecting it. The test compares the whole config to an expected value with default environment ID, enabled true, required false, empty tools, and all optional fields unset.

Call relations: The test runner invokes it. It uses from_str to confirm permissive parsing, then a full equality check to make sure the unknown field does not secretly affect any real setting.

Call graph: 2 external calls (assert_eq!, from_str).

fn deserialize_rejects_command_and_url()

Purpose: Checks that a server config cannot specify both a local command and an HTTP URL. A server must choose one transport method, not two competing ways to connect.

Data flow: A TOML snippet containing both command and url goes in. Parsing is expected to fail. The test passes only if the parser rejects the ambiguous configuration.

Call relations: The test runner calls this negative test. It exercises the parser’s validation rule that separates standard-input/output servers from HTTP servers before any later code tries to start or connect to them.

fn deserialize_rejects_env_for_http_transport()

Purpose: Checks that process environment settings are not accepted on HTTP-based MCP servers. Fixed env values only make sense when the program is launching a local command.

Data flow: A TOML snippet with a URL and an env table goes in. Parsing is expected to return an error. No config object is accepted from this input.

Call relations: The test runner invokes it. The parser is the part under test, and the expected failure protects HTTP connection code from receiving irrelevant process-launch settings.

fn deserialize_rejects_headers_for_stdio()

Purpose: Checks that HTTP-only settings are rejected for command-based MCP servers. It covers request headers, environment-backed request headers, OAuth client settings, and OAuth resource settings.

Data flow: Several TOML snippets go in, each using command = "echo" together with a setting that only makes sense for HTTP. Each parse must fail. For the OAuth-related cases, the test also checks the error text so users get a clear explanation that OAuth is not supported for standard-input/output servers.

Call relations: The test runner calls this larger negative test. It repeatedly asks the parser to validate bad mixes of transport-specific fields, and the assertions confirm that the parser stops them before runtime startup or networking code sees them.

Call graph: 1 external calls (assert!).

fn deserialize_rejects_inline_bearer_token_field()

Purpose: Checks that a config cannot contain a raw bearer token directly. This helps avoid storing secrets in plain configuration files.

Data flow: A TOML snippet with a URL and bearer_token = "secret" goes in. Parsing is expected to fail, and the test checks that the error message says inline bearer tokens are not supported. The accepted alternative is to name an environment variable instead.

Call relations: The test runner invokes this security-focused validation test. It depends on the parser rejecting the sensitive field and uses an assertion on the error text to make sure the reason is clear.

Call graph: 1 external calls (assert!).

async fn replace_mcp_servers_serializes_per_tool_approval_overrides() -> anyhow::Result<()>

Purpose: This test proves that tool-specific approval settings for an MCP server are saved correctly. It protects the case where a server has a default approval mode, but individual tools override that default.

Data flow: It starts by creating a unique temporary config directory and an in-memory MCP server named docs. That server has a default approval mode plus separate approval settings for the search and read tools. The test writes this server map through the config edit builder, reads the generated config file as text, and compares it to the expected TOML. Then it loads the MCP server config back through the normal loader and checks that the loaded structure is exactly the same as the original. Finally, it removes the temporary directory and returns success if all checks passed.

Call relations: During the test run, the async test harness calls this function directly. Inside it, the function relies on the config editing path, starting with ConfigEditsBuilder::new, then replacing the MCP server section and applying the edit. It also calls the normal MCP config loading path afterward, so the test covers both writing and reading rather than only one side.

Call graph: calls 1 internal fn (new); 9 external calls (from, from, now, new, assert_eq!, format!, temp_dir, read_to_string, remove_dir_all).

async fn replace_mcp_servers_serializes_oauth_client_id() -> anyhow::Result<()>

Purpose: This test proves that an MCP server's OAuth client ID is saved in the right place in the config file. OAuth is a login/authorization system, and the client ID identifies this application to the service it connects to.

Data flow: It creates a unique temporary config directory and an in-memory MCP server named maas_outlook that connects over HTTP and includes an OAuth client ID. The test writes that server configuration to the temporary config file, reads the file back as text, and checks that the OAuth client ID appears under the server's OAuth section. It then loads the MCP server configuration through the normal loader and verifies that the loaded data matches what was originally written. At the end it deletes the temporary directory.

Call relations: The async test harness calls this function as part of the test suite. The function exercises the same config-editing path a real settings change would use, beginning with ConfigEditsBuilder::new and ending with applying the edit. It then hands the written file to the normal MCP server loader, confirming that the saved OAuth data can be understood by the rest of the configuration system.

Call graph: calls 1 internal fn (new); 8 external calls (from, new, now, assert_eq!, format!, temp_dir, read_to_string, remove_dir_all).

fn test_user_config_path(temp_dir: &TempDir, file_name: &str) -> AbsolutePathBuf

Purpose: This small helper builds an absolute path to a fake user configuration file inside a temporary test folder. It keeps the tests short and makes sure the paths used by the tests look like real full file paths.

Data flow: It receives a temporary directory and a file name. It joins the directory path with that file name, checks that the result is an absolute path, and returns it wrapped in the project’s absolute-path type. If the path is unexpectedly not absolute, the test stops with a clear error message.

Call relations: The user-layer tests call this helper when they need paths for pretend config files, such as a base config file and a profile-specific config file. It does not take part in the configuration logic itself; it simply prepares realistic input for the tests.

Call graph: calls 1 internal fn (from_absolute_path); called by 2 (active_user_layer_is_highest_precedence_user_layer, with_user_config_updates_matching_user_layer_without_replacing_active_profile); 1 external calls (path).

fn origins_use_canonical_key_aliases()

Purpose: This test verifies that when a legacy configuration key is used, the configuration system records the setting under its modern official key name. This prevents the rest of the program from having to remember every old spelling of the same option.

Data flow: The test starts with a small TOML configuration snippet using an older key name. It wraps that snippet in a configuration layer that represents session-provided settings, builds a one-layer configuration stack, and asks the stack where each setting came from. The expected result is that the origin map contains the modern key name and does not contain the legacy key name.

Call relations: This test exercises the configuration stack creation path and then inspects the stack’s origin tracking. It relies on TOML parsing to turn text into configuration data, then uses the stack’s metadata and origins output to prove that key aliasing happened before origins were stored.

Call graph: calls 2 internal fn (new, new); 6 external calls (default, assert!, assert_eq!, default, from_str, vec!).

fn active_user_layer_is_highest_precedence_user_layer()

Purpose: This test checks that when both a base user config and a profile-specific user config exist, the profile config is treated as the active user config. It also checks that the final merged user config still keeps useful values from the base file.

Data flow: The test creates two fake config file paths in a temporary directory. It builds one user layer for the base config, containing a model and an approval policy, and another user layer for a work profile, containing a different model. After building the configuration stack, it checks that the active user file is the profile file. It also checks that the merged user config uses the profile’s model while still keeping the base file’s approval policy.

Call relations: This test uses the path helper to create realistic file paths, then feeds two user layers into the configuration stack. It tells the story of normal profile selection: the stack should pick the higher-priority profile layer as active, while the merge logic combines profile overrides with base settings underneath.

Call graph: calls 3 internal fn (new, new, test_user_config_path); 6 external calls (new, default, assert_eq!, default, from_str, vec!).

fn with_user_config_updates_matching_user_layer_without_replacing_active_profile()

Purpose: This test verifies that changing the contents of one user config layer updates that layer only, without accidentally changing which profile is active. This is important when saving or editing a base config while a profile-specific config is currently in use.

Data flow: The test creates a base user config file and a work profile config file. The base layer starts with a model value, while the profile layer supplies an approval policy. It builds a configuration stack, then asks the stack to replace the config contents for the base file with an updated model value. The returned stack should still report the profile file as active, but its merged user config should now include the updated base model and the profile’s approval policy.

Call relations: This test sets up the same kind of layered user configuration as the previous one, then calls the stack’s user-config update operation. It confirms that the update operation finds the matching file path and changes that layer’s data, while leaving the higher-priority active profile relationship intact.

Call graph: calls 3 internal fn (new, new, test_user_config_path); 6 external calls (new, default, assert_eq!, default, from_str, vec!).

fn canonicalize(
        &'a self,
        path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, PathUri>

Purpose: This gives the loader a clean, absolute version of a path during tests. It lets the test file system behave enough like a real file system for config loading to work.

Data flow: It receives a project path wrapped as a PathUri, plus an unused sandbox setting. It converts the path to a normal absolute path, asks the operating system for the canonical version, then wraps that result back into a PathUri. The output is either the cleaned-up path or an input/output error if the path cannot be resolved.

Call relations: The configuration loader calls this through the ExecutorFileSystem interface when it needs reliable paths. Inside, this method delegates to path conversion helpers and the platform’s path canonicalization, then hands the normalized path back to the loader.

Call graph: calls 2 internal fn (from_abs_path, to_abs_path); 2 external calls (pin, canonicalize).

fn read_file(
        &'a self,
        path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, Vec<u8>>

Purpose: This lets the tests read the temporary config files they just wrote. It is the main file access operation the config loader needs in these tests.

Data flow: It receives a PathUri pointing to a file and an unused sandbox setting. It converts the path to an absolute local path, turns that into a normal filesystem path, and reads the file bytes asynchronously. The output is the file contents as raw bytes, or an input/output error if reading fails.

Call relations: The real config loader calls this method when it wants to load config.toml or the selected profile config file. This test implementation passes the actual disk read to Tokio’s asynchronous file reader and returns the bytes to the loader.

Call graph: calls 1 internal fn (to_abs_path); 3 external calls (pin, read, as_path).

fn read_file_stream(
        &'a self,
        _path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, FileSystemReadStream>

Purpose: This says clearly that streaming reads are not available in this test file system. The tests do not need streaming, so supporting it would add noise without value.

Data flow: It receives a path and an optional sandbox setting, but does not use them. Instead of opening a stream, it immediately returns an error saying this operation is unsupported. Nothing is read or changed.

Call relations: If some tested code unexpectedly tried to read config files as a stream, this method would make that failure obvious. In the intended test path, the loader uses read_file instead, so this method acts as a guardrail.

Call graph: 2 external calls (pin, new).

fn write_file(
        &'a self,
        _path: &'a PathUri,
        _contents: Vec<u8>,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, ()>

Purpose: This marks file writing as outside the scope of the test file system. The tests create files directly with standard filesystem calls before invoking the loader.

Data flow: It receives a destination path, file contents, and an optional sandbox setting, but it does not use them. If called, it stops with an unimplemented error. No file is written.

Call relations: The config loader should only read files for these tests, so this method should never be part of the normal flow. Its presence is required because TestFileSystem must implement the full file system interface.

Call graph: 2 external calls (pin, unimplemented!).

fn create_directory(
        &'a self,
        _path: &'a PathUri,
        _create_directory_options: CreateDirectoryOptions,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorF

Purpose: This marks directory creation as unsupported in these tests. Temporary directories are created by the test setup, not by the config loader.

Data flow: It receives a directory path, creation options, and an optional sandbox setting, but ignores them. If called, it fails immediately with an unimplemented error. No directory is created.

Call relations: This exists only to satisfy the file system interface. The test flow creates its temporary folder separately with tempdir, then the loader only reads from it.

Call graph: 2 external calls (pin, unimplemented!).

fn get_metadata(
        &'a self,
        _path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, FileMetadata>

Purpose: This marks metadata lookup, such as checking whether a path is a file or directory, as unsupported for this narrow test file system.

Data flow: It receives a path and an optional sandbox setting, but does not inspect the path. If called, it stops with an unimplemented error. It returns no metadata.

Call relations: The tested config-loading path is expected not to need metadata. This method is included because the broader file system trait requires it, not because these tests depend on it.

Call graph: 2 external calls (pin, unimplemented!).

fn read_directory(
        &'a self,
        _path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, Vec<ReadDirectoryEntry>>

Purpose: This marks directory listing as unsupported. These tests name the exact config files to read, so they do not need to scan folders.

Data flow: It receives a directory path and an optional sandbox setting, but does not read the directory. If called, it fails with an unimplemented error. No directory entries are returned.

Call relations: The normal test story writes known files and asks the loader to read known paths. If the loader unexpectedly started listing directories here, this method would reveal that mismatch.

Call graph: 2 external calls (pin, unimplemented!).

fn remove(
        &'a self,
        _path: &'a PathUri,
        _remove_options: RemoveOptions,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, ()>

Purpose: This marks deletion as unsupported in the test file system. The tests do not need the loader to remove files.

Data flow: It receives a path, removal options, and an optional sandbox setting, but ignores them. If called, it stops with an unimplemented error. Nothing is deleted.

Call relations: This is present only because the file system interface includes removal. The temporary directory cleanup is handled by the test framework, not by this method.

Call graph: 2 external calls (pin, unimplemented!).

fn copy(
        &'a self,
        _source_path: &'a PathUri,
        _destination_path: &'a PathUri,
        _copy_options: CopyOptions,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    )

Purpose: This marks file copying as unsupported. Config loading should not copy files during these tests.

Data flow: It receives a source path, destination path, copy options, and an optional sandbox setting, but does not use them. If called, it fails with an unimplemented error. No data is copied.

Call relations: The method completes the required file system interface while keeping the test double intentionally small. The tested loader path should rely on canonicalize and read_file, not copying.

Call graph: 2 external calls (pin, unimplemented!).

async fn profile_v2_rejects_matching_legacy_profile_in_base_user_config()

Purpose: This test proves that the loader rejects a new-style selected profile when the base config also defines an old-style profile with the same name. That prevents two different meanings of work from being mixed together.

Data flow: The test creates a temporary folder, writes a base config.toml containing [profiles.work], and writes a separate work.config.toml for the new-style profile. It builds loader overrides that select the work profile and point at work.config.toml. After asking the loader to read this setup, it expects an error, then checks that the error is InvalidData and that the message explains the conflict and points to the advanced config documentation.

Call relations: During the test, setup helpers create the temporary directory, write files, and build test-only loader overrides. The test then calls the config loader through load_config_layers_state using TestFileSystem; the loader reads the files and returns the conflict error that the assertions inspect.

Call graph: calls 2 internal fn (without_managed_config_for_tests, resolve_path_against_base); 4 external calls (assert!, assert_eq!, write, tempdir).

async fn profile_v2_rejects_matching_legacy_profile_selector_in_base_user_config()

Purpose: This test proves that the loader also rejects a collision when the base config selects the same old-style profile name with profile = "work". This catches a second way the old and new profile systems could be confused.

Data flow: The test creates a temporary folder, writes a base config.toml containing profile = "work", and writes a selected work.config.toml. It sets overrides so the loader uses the new-style work profile file. The loader is expected to fail; the test checks that the failure is an invalid configuration error and that the message mentions the conflicting selector and the selected config file.

Call relations: The test uses the same supporting pieces as the previous one: temporary files, test-only overrides, and TestFileSystem for reads. It hands this setup to load_config_layers_state, then verifies that the loader reports the legacy selector conflict instead of accepting it silently.

Call graph: calls 2 internal fn (without_managed_config_for_tests, resolve_path_against_base); 4 external calls (assert!, assert_eq!, write, tempdir).

async fn profile_v2_allows_unrelated_legacy_profiles_in_base_user_config()

Purpose: This test proves that the loader is not too strict. A new-style work profile should still load if the base config contains an old-style profile with a different name, such as dev.

Data flow: The test creates a temporary folder, writes a base config.toml with [profiles.dev], and writes work.config.toml for the selected new-style profile. It sets overrides to choose work, asks the loader to read the configuration, and expects success. No error details are checked because success is the important outcome.

Call relations: This is the positive companion to the rejection tests. It uses the same loader path and file-system test double, but the loader should find no name collision and should complete normally.

Call graph: calls 2 internal fn (without_managed_config_for_tests, resolve_path_against_base); 2 external calls (write, tempdir).

fn blocking_set_model_top_level()

Purpose: Checks that setting the model and reasoning effort writes both values at the top level of a fresh config file. This protects the basic path used when a user changes their default model.

Data flow: It starts with an empty temporary Codex home folder. It applies a blocking config edit with a model name and high reasoning effort, reads config.toml, and compares the full text to the expected two-line file.

Call relations: The Rust test runner calls this test. Inside the test, temporary disk storage is created, the production apply_blocking edit path is exercised, then standard file reading and equality checking confirm the result.

Call graph: 3 external calls (assert_eq!, read_to_string, tempdir).

fn set_service_tier_saves_default_as_default()

Purpose: Checks that the default service tier is saved using the user-facing word default. This matters because the request value may come from protocol code, but the config file should stay clear and stable.

Data flow: It creates a temporary home, builds a config edit that sets the service tier to the default request value, applies it, reads the config file, and expects service_tier = "default".

Call relations: The test runner invokes it. It uses ConfigEditsBuilder::new to build the edit flow and then verifies the builder wrote the expected TOML text.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn set_service_tier_saves_priority_as_fast()

Purpose: Checks that the fast service tier is saved as fast. This keeps the saved configuration aligned with the service tier names users and other code expect.

Data flow: It creates a temporary home folder, asks the edit builder to set the service tier from the Fast request value, applies the edit, then reads the file and compares it with the expected text.

Call relations: The test runner calls this during tests. It goes through the same builder API that normal code would use, then hands the result to file reading and assertion code.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn set_service_tier_preserves_unknown_service_tier()

Purpose: Checks that an unrecognized service tier string is not rejected or rewritten. This is useful for experimental tiers that newer servers may understand before the local app does.

Data flow: It sends the string experimental-tier-id into the config edit builder, applies the edit in a temporary home, reads config.toml, and expects that exact string to be saved.

Call relations: The test runner starts it. The test exercises the builder path and then uses the file contents as proof that unknown values pass through unchanged.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn builder_with_edits_applies_custom_paths()

Purpose: Checks that callers can give the builder a custom low-level edit path, not only use its convenience methods. This keeps the builder flexible for settings that do not have a special helper yet.

Data flow: It creates an edit saying enabled = true, gives that edit to the builder, applies it, then reads the config file and expects that single boolean setting.

Call relations: The test runner calls it. It uses ConfigEditsBuilder::new, passes a vector of edits into with_edits, and verifies the generic path-setting machinery.

Call graph: calls 1 internal fn (new); 4 external calls (assert_eq!, read_to_string, tempdir, vec!).

fn session_picker_view_edit_writes_root_tui_setting()

Purpose: Checks that changing the session picker view writes the setting under the root terminal UI section. This prevents the setting from being misplaced in a profile or another table.

Data flow: It asks for the dense session picker view, applies the generated edit in a temporary home, reads the file, and expects a [tui] table with session_picker_view = "dense".

Call relations: The test runner invokes it. The test uses the helper that creates the session-picker edit, then the builder applies it through the normal config-writing path.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn keymap_binding_edit_writes_root_action_binding()

Purpose: Checks that a single keyboard shortcut for a terminal UI action is written in the right nested keymap table. This protects custom key bindings from being saved in the wrong place.

Data flow: It creates an edit for the composer context and submit action with ctrl-enter, applies it, and reads back a [tui.keymap.composer] section containing that binding.

Call relations: The test runner calls it. The keymap edit helper produces the edit, the builder persists it, and the assertion checks the final TOML text.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn keymap_bindings_edit_writes_single_binding_as_string()

Purpose: Checks that when there is only one shortcut for an action, it is saved as a simple string rather than a list. This keeps the config compact and readable.

Data flow: It passes one binding, ctrl-enter, into the multi-binding helper, applies it, reads the file, and expects the same output format as the single-binding helper.

Call relations: The test runner invokes it. It exercises the keymap bindings helper through the builder and then confirms the writer chooses the simple string form.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn keymap_bindings_edit_writes_multiple_bindings_as_array()

Purpose: Checks that multiple shortcuts for one action are saved as a list. This is the format needed when one action should respond to more than one key combination.

Data flow: It supplies two bindings, applies the config edit, reads the TOML text, parses it into a TOML value tree, and checks that the nested submit value is an array containing both strings.

Call relations: The test runner calls it. The builder writes the file, then TOML parsing is used instead of raw text comparison so the test can focus on the stored list value.

Call graph: calls 1 internal fn (new); 4 external calls (assert_eq!, read_to_string, tempdir, from_str).

fn keymap_binding_edit_replaces_existing_binding_without_touching_profile()

Purpose: Checks that changing a root key binding updates only the root binding and leaves a profile-specific binding alone. This matters because profiles are separate named sets of preferences.

Data flow: It seeds a config file with both a root key binding and a profile key binding. After applying a root binding change, it parses the file and checks that only the root value changed.

Call relations: The test runner invokes it. The test writes seed data to disk, sends the edit through the builder, then uses TOML parsing to inspect both the root and profile branches.

Call graph: calls 1 internal fn (new); 5 external calls (assert_eq!, read_to_string, write, tempdir, from_str).

fn keymap_binding_clear_edit_removes_root_action_binding_without_touching_profile()

Purpose: Checks that clearing a root key binding removes only that root entry. It guards against accidentally deleting a user's profile-specific shortcut.

Data flow: It starts with a config containing root and profile bindings. It applies a clear edit for the root action, parses the result, and confirms the root binding is gone while the profile binding remains.

Call relations: The test runner calls it. The clear-edit helper produces the edit, the builder writes it, and parsed TOML checks prove the edit stayed in the intended branch.

Call graph: calls 1 internal fn (new); 5 external calls (assert_eq!, read_to_string, write, tempdir, from_str).

fn set_model_availability_nux_count_writes_shown_count()

Purpose: Checks that the app records how many times a model availability new-user message has been shown. This prevents repeated prompts from feeling noisy.

Data flow: It creates a small map from model name to count, applies the builder method for this setting, reads the file, and expects the count under [tui.model_availability_nux].

Call relations: The test runner invokes it. The builder turns the in-memory count map into TOML, and the assertion checks the saved table.

Call graph: calls 1 internal fn (new); 4 external calls (from, assert_eq!, read_to_string, tempdir).

fn set_skill_config_writes_disabled_entry()

Purpose: Checks that disabling a skill by file path writes an entry saying that skill is disabled. This lets users turn off a specific skill without deleting it.

Data flow: It supplies a skill file path and enabled: false, applies the edit, reads the config, and expects one [[skills.config]] array entry with the path and disabled flag.

Call relations: The test runner calls it. The test creates a SetSkillConfig edit directly, routes it through the builder, and verifies the serialized TOML.

Call graph: calls 1 internal fn (new); 4 external calls (from, assert_eq!, read_to_string, tempdir).

fn set_skill_config_removes_entry_when_enabled()

Purpose: Checks that re-enabling a skill removes its special disabled entry. This keeps the config file from storing unnecessary defaults.

Data flow: It seeds the config with a disabled skill entry, applies an edit marking that same path enabled, reads the file, and expects it to become empty.

Call relations: The test runner invokes it. The test writes seed TOML, uses the builder to apply the skill edit, and confirms the writer removed now-unneeded configuration.

Call graph: calls 1 internal fn (new); 5 external calls (from, assert_eq!, read_to_string, write, tempdir).

fn set_skill_config_writes_name_selector_entry()

Purpose: Checks that a skill can be disabled by name, not only by file path. This supports skills identified by a registry-like name such as github:yeet.

Data flow: It applies a SetSkillConfigByName edit with enabled: false, reads config.toml, and expects a skills config entry containing the name and disabled flag.

Call relations: The test runner calls it. The test exercises direct edit construction plus builder persistence, then checks the written TOML text.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn blocking_set_model_ignores_inline_legacy_profile_contents()

Purpose: Checks that setting the global model does not rewrite old inline profile settings. This protects users with older config styles from losing profile data.

Data flow: It seeds a config with an active profile stored as an inline TOML table. It applies a global model change, parses the result, and confirms the root model changed while the profile's model and sandbox setting stayed the same.

Call relations: The test runner invokes it. The test bypasses the builder and calls the blocking edit function directly, then uses TOML parsing to compare root and profile data separately.

Call graph: 5 external calls (assert_eq!, read_to_string, write, tempdir, from_str).

fn blocking_set_model_writes_through_symlink_chain()

Purpose: On Unix systems, checks that editing config.toml follows a normal chain of symbolic links. A symbolic link is a file-system shortcut that points to another file.

Data flow: It creates a config path that points through one link to a target file, applies a model edit, checks that the config path is still a link, and reads the target file to confirm the content was written there.

Call relations: The Unix test runner calls it only on Unix. It uses file-system symlink calls to set up the case, then exercises apply_blocking and verifies both link behavior and file contents.

Call graph: 6 external calls (assert!, assert_eq!, read_to_string, symlink_metadata, symlink, tempdir).

fn blocking_set_model_replaces_symlink_on_cycle()

Purpose: On Unix systems, checks that a broken symbolic-link loop does not trap the config writer. If links point in a circle, the editor should replace the unusable config link with a real file.

Data flow: It creates two links that point to each other and makes config.toml point into that loop. After applying a model edit, it checks that config.toml is no longer a symlink and contains the expected model setting.

Call relations: The Unix test runner invokes it on Unix. The test sets up the bad file-system state, calls the production blocking edit path, then checks that the fallback behavior produced a usable file.

Call graph: 6 external calls (assert!, assert_eq!, read_to_string, symlink_metadata, symlink, tempdir).

fn batch_write_table_upsert_preserves_inline_comments()

Purpose: Checks that changing values inside existing tables keeps nearby comments intact. This matters because many users document their config file by hand.

Data flow: It seeds a config with comments around MCP server and sandbox settings. It applies two path updates, reads the file, and expects only the target values to change while comments and layout remain.

Call relations: The test runner calls it. The blocking edit function receives a batch of path edits, and the assertion confirms the writer performs careful in-place-style updates.

Call graph: 5 external calls (assert_eq!, read_to_string, write, tempdir, vec!).

fn blocking_clear_model_does_not_follow_legacy_active_profile()

Purpose: Checks that clearing the global model does not clear the model inside the currently selected legacy profile. Profiles should not be edited just because they are active.

Data flow: It seeds a config with an active inline profile, applies a model edit where the model is absent but reasoning effort is set, then checks the final text keeps the profile unchanged and adds only the root effort setting.

Call relations: The test runner invokes it. It calls apply_blocking directly and uses a raw text comparison to make sure the exact layout and legacy profile content remain.

Call graph: 4 external calls (assert_eq!, read_to_string, write, tempdir).

fn blocking_set_model_does_not_follow_legacy_active_profile()

Purpose: Checks that setting the global model and effort does not overwrite the active profile's own effort setting. This keeps global settings and profile settings separate.

Data flow: It writes a config with profile = "team" and a profile-specific effort. It applies a global model and effort update, reads the file, and expects new root values while the profile table remains unchanged.

Call relations: The test runner calls it. The production blocking edit path is tested against seeded TOML, and the final string comparison proves the edit did not follow the active profile.

Call graph: 4 external calls (assert_eq!, read_to_string, write, tempdir).

fn blocking_set_hide_full_access_warning_preserves_table()

Purpose: Checks that acknowledging the full-access warning adds a notice flag without disturbing an existing notice table. This keeps user comments and unrelated notice values safe.

Data flow: It seeds a [notice] table with a comment and existing value. It applies the hide-warning edit, reads the file, and expects the new boolean flag appended in the same table.

Call relations: The test runner invokes it. The test constructs the notice edit, sends it through apply_blocking, and compares the resulting TOML text exactly.

Call graph: 5 external calls (SetNoticeHideFullAccessWarning, assert_eq!, read_to_string, write, tempdir).

fn blocking_set_hide_rate_limit_model_nudge_preserves_table()

Purpose: Checks that hiding the rate-limit model nudge adds the right flag inside the notice table. It ensures other notice settings are not replaced.

Data flow: It starts with a notice table containing existing = "value", applies the hide-nudge edit, reads the file, and expects both the old value and new flag.

Call relations: The test runner calls it. The notice-specific edit is handed to the blocking config writer, and the assertion confirms the table was extended rather than rebuilt destructively.

Call graph: 5 external calls (SetNoticeHideRateLimitModelNudge, assert_eq!, read_to_string, write, tempdir).

fn blocking_set_hide_gpt5_1_migration_prompt_preserves_table()

Purpose: Checks that hiding a model migration prompt with a simple key name writes that key under [notice]. This records that the user should not see that prompt again.

Data flow: It seeds an existing notice table, applies a migration-prompt hide edit for hide_gpt5_1_migration_prompt, reads the file, and expects the new boolean alongside the existing value.

Call relations: The test runner invokes it. The test uses the migration-prompt edit variant and verifies the blocking writer keeps the table content.

Call graph: 5 external calls (SetNoticeHideModelMigrationPrompt, assert_eq!, read_to_string, write, tempdir).

fn blocking_set_hide_gpt_5_1_codex_max_migration_prompt_preserves_table()

Purpose: Checks that migration prompt keys containing punctuation are quoted correctly in TOML. This prevents invalid config when a model name includes characters like dashes and dots.

Data flow: It seeds a notice table, applies a hide-prompt edit with a punctuation-heavy key, reads the file, and expects the key to be quoted while the old table entry remains.

Call relations: The test runner calls it. It exercises the same migration-prompt edit path as simpler names, but verifies the TOML writer uses safe key syntax.

Call graph: 5 external calls (SetNoticeHideModelMigrationPrompt, assert_eq!, read_to_string, write, tempdir).

fn blocking_record_model_migration_seen_preserves_table()

Purpose: Checks that recording a seen model migration adds a nested map from old model to new model. This helps the app avoid repeating migration notices.

Data flow: It starts with an existing notice table, applies an edit saying migration from gpt-5.2 to gpt-5.4 was seen, reads the file, and expects a [notice.model_migrations] section with that mapping.

Call relations: The test runner invokes it. The blocking config writer receives the record-migration edit and creates the nested notice table while preserving existing notice data.

Call graph: 4 external calls (assert_eq!, read_to_string, write, tempdir).

fn blocking_set_hide_external_config_migration_prompt_home_preserves_table()

Purpose: Checks that hiding the external-config migration prompt for the home config writes a nested home flag. This records prompt state without overwriting the rest of [notice].

Data flow: It seeds [notice], applies the home prompt hide edit, reads the file, and expects a [notice.external_config_migration_prompts] table with home = true.

Call relations: The test runner calls it. It uses the specific edit constructor for the home prompt and verifies the blocking writer adds the nested table.

Call graph: 5 external calls (SetNoticeHideExternalConfigMigrationPromptHome, assert_eq!, read_to_string, write, tempdir).

fn blocking_set_hide_external_config_migration_prompt_project_preserves_table()

Purpose: Checks that hiding an external-config migration prompt for one project stores that project's path as a key. This lets prompt state be tracked separately per project.

Data flow: It seeds a notice table, applies a project hide edit with a project path and true, reads the file, and expects that path under [notice.external_config_migration_prompts.projects].

Call relations: The test runner invokes it. The project-specific notice edit flows through apply_blocking, and the text comparison checks the nested project table.

Call graph: 5 external calls (SetNoticeHideExternalConfigMigrationPromptProject, assert_eq!, read_to_string, write, tempdir).

fn blocking_set_external_config_migration_prompt_home_last_prompted_at_preserves_table()

Purpose: Checks that the last time the home migration prompt was shown is saved under the external-config prompt notice table. This supports throttling prompts so they do not appear too often.

Data flow: It seeds [notice], applies an edit with a Unix-style timestamp number, reads the file, and expects home_last_prompted_at in the nested prompt table.

Call relations: The test runner calls it. The timestamp edit is passed to the blocking writer, and the assertion checks that existing notice content is preserved.

Call graph: 5 external calls (SetNoticeExternalConfigMigrationPromptHomeLastPromptedAt, assert_eq!, read_to_string, write, tempdir).

fn blocking_set_external_config_migration_prompt_project_last_prompted_at_preserves_table()

Purpose: Checks that the last prompt time can be stored separately for a project path. This lets Codex remember prompt timing per project.

Data flow: It starts with a notice table, applies an edit with a project path and timestamp, reads the file, and expects the timestamp under [notice.external_config_migration_prompts.project_last_prompted_at] keyed by that path.

Call relations: The test runner invokes it. The project timestamp edit goes through the blocking config writer, then exact text comparison verifies the nested output.

Call graph: 5 external calls (SetNoticeExternalConfigMigrationPromptProjectLastPromptedAt, assert_eq!, read_to_string, write, tempdir).

fn blocking_replace_mcp_servers_round_trips()

Purpose: Checks that replacing the MCP server list writes a full, readable TOML representation for different server transports. MCP means Model Context Protocol, a way for Codex to connect to external tools and services.

Data flow: It builds two in-memory server configs: one command-line server and one HTTP server. It applies a replace-all edit, reads the config file, and compares it with the expected server tables, including headers, environment variables, timeouts, OAuth data, and tool lists.

Call relations: The test runner calls it. The test constructs realistic McpServerConfig values, sends them through ConfigEdit::ReplaceMcpServers, and checks that serialization to TOML is correct.

Call graph: 8 external calls (new, new, ReplaceMcpServers, assert_eq!, read_to_string, from_secs, tempdir, vec!).

fn blocking_replace_mcp_servers_serializes_tool_approval_overrides()

Purpose: Checks that MCP server tool approval settings are written correctly. These settings decide whether a tool can run automatically or must ask the user first.

Data flow: It builds a server with a default approval mode and one tool-specific approval override, applies the replace edit, reads the file, and expects both the server-level and tool-level approval values.

Call relations: The test runner invokes it. The replace-MCP-server edit exercises the production serializer, and the final string comparison confirms nested tool settings are kept.

Call graph: 7 external calls (new, from, new, ReplaceMcpServers, assert_eq!, read_to_string, tempdir).

fn blocking_replace_mcp_servers_preserves_inline_comments()

Purpose: Checks that replacing MCP servers does not remove a comment inside an existing [mcp_servers] table when the logical server data stays the same. This protects hand-written notes.

Data flow: It seeds a compact inline MCP server entry with a preceding comment. It applies a replace edit with matching server data, reads the file, and expects the original comment and inline entry to remain.

Call relations: The test runner calls it. The test writes seed TOML, constructs the matching server map, applies ReplaceMcpServers, and checks that the writer avoided unnecessary churn.

Call graph: 8 external calls (new, new, new, ReplaceMcpServers, assert_eq!, read_to_string, write, tempdir).

fn blocking_replace_mcp_servers_preserves_inline_comment_suffix()

Purpose: Checks that a comment after an inline MCP server entry remains after the entry is updated. This is important because trailing comments often explain a setting.

Data flow: It seeds an inline server followed by # keep me, then applies a replace edit that adds enabled = false. It reads the file and expects the added field before the preserved trailing comment.

Call relations: The test runner invokes it. The replace edit updates the inline TOML entry, and the assertion ensures the comment suffix is still attached.

Call graph: 8 external calls (new, new, new, ReplaceMcpServers, assert_eq!, read_to_string, write, tempdir).

fn blocking_replace_mcp_servers_preserves_inline_comment_after_removing_keys()

Purpose: Checks that removing fields from an inline MCP server entry does not lose its trailing comment. This protects comments even when the shape of the inline table shrinks.

Data flow: It seeds an inline server with an args field and a trailing comment. It replaces the server with one that has no args, reads the file, and expects the args field gone while the comment remains.

Call relations: The test runner calls it. The MCP replacement serializer edits the inline table, and the test verifies both key removal and comment preservation.

Call graph: 8 external calls (new, new, new, ReplaceMcpServers, assert_eq!, read_to_string, write, tempdir).

fn blocking_replace_mcp_servers_preserves_inline_comment_prefix_on_update()

Purpose: Checks that a comment immediately before an inline MCP server entry remains when the entry is updated. This guards the common pattern of documenting a setting on the line above it.

Data flow: It seeds a [mcp_servers] table with a comment before foo. It replaces the server with a version that adds enabled = false, reads the file, and expects the comment still before the updated inline entry.

Call relations: The test runner invokes it. The replace edit updates the server configuration, while the exact text assertion checks that surrounding comments survived.

Call graph: 8 external calls (new, new, new, ReplaceMcpServers, assert_eq!, read_to_string, write, tempdir).

fn blocking_clear_path_noop_when_missing()

Purpose: Checks that clearing a missing setting does nothing and does not create a new config file. This avoids leaving empty files behind for no real change.

Data flow: It starts with an empty temporary home, applies a clear edit for a path that does not exist, then checks that config.toml was not created.

Call relations: The test runner calls it. The direct apply_blocking path receives a no-op clear edit, and a file-existence assertion confirms it stayed a no-op.

Call graph: 3 external calls (assert!, tempdir, vec!).

fn blocking_set_path_updates_notifications()

Purpose: Checks that a generic path edit can set the terminal UI notifications flag. This proves nested boolean settings are written in a parseable way.

Data flow: It applies a path edit for tui.notifications = false, reads the file, parses it as TOML, and checks that the nested value is the boolean false.

Call relations: The test runner invokes it. The blocking writer handles the generic path edit, and TOML parsing verifies the resulting data rather than only the text layout.

Call graph: 5 external calls (assert_eq!, read_to_string, tempdir, from_str, vec!).

async fn async_builder_set_model_persists()

Purpose: Checks that the asynchronous builder path also persists model settings. Asynchronous code lets the app wait for file work without blocking other tasks.

Data flow: It creates a temporary home, uses the builder's async apply method to set model and effort, waits for it to finish, then reads the file and compares the expected text.

Call relations: The Tokio async test runner calls it. It uses ConfigEditsBuilder::new, the async apply path, and normal file reading to prove the async wrapper reaches the same writer.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn blocking_builder_set_model_round_trips_back_and_forth()

Purpose: Checks that repeated model changes overwrite the previous values cleanly. This guards against duplicate keys or stale model settings accumulating.

Data flow: It writes an initial model and effort, verifies them, writes a different model and effort, verifies those, then writes the original pair again and verifies the file returns to the initial text.

Call relations: The test runner calls it. The builder's blocking apply path is exercised three times in a row, with file reads after each step to confirm stable round trips.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

async fn blocking_set_asynchronous_helpers_available()

Purpose: Checks that convenience helper methods can be used with the async builder path. In this case, it verifies the full-access warning acknowledgement can be saved asynchronously.

Data flow: It uses the builder to set the hide-full-access-warning flag and awaits the async apply. It reads and parses the file, then checks that the notice flag is true.

Call relations: The Tokio async test runner invokes it. The builder helper creates the edit, async apply writes it, and TOML parsing confirms the saved value.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, read_to_string, tempdir).

fn blocking_builder_set_realtime_audio_persists_and_clears()

Purpose: Checks that realtime audio device preferences can be saved and individually cleared. This lets users choose a microphone and speaker, then remove only one choice later.

Data flow: It first saves microphone and speaker names under the audio table and parses the file to confirm both. Then it clears only the microphone, reads again, and confirms the speaker remains while microphone is gone.

Call relations: The test runner calls it. The builder's realtime audio helper methods feed edits into the blocking writer, and TOML parsing checks the before-and-after state.

Call graph: calls 1 internal fn (new); 4 external calls (assert_eq!, read_to_string, tempdir, from_str).

fn blocking_builder_set_realtime_voice_persists_and_clears()

Purpose: Checks that a realtime voice preference can be saved and then cleared. This protects the voice setting used by realtime audio features.

Data flow: It saves the voice cedar, parses the config to confirm it appears under [realtime], then applies a clear edit and parses again to confirm the voice key is gone.

Call relations: The test runner invokes it. The builder's realtime voice helper is used with blocking apply, and parsed TOML confirms both persistence and removal.

Call graph: calls 1 internal fn (new); 4 external calls (assert_eq!, read_to_string, tempdir, from_str).

fn replace_mcp_servers_blocking_clears_table_when_empty()

Purpose: Checks that replacing MCP servers with an empty map removes the MCP server table. This keeps the config from retaining old server definitions after the user deletes them.

Data flow: It seeds a config with one MCP server, applies ReplaceMcpServers with an empty collection, reads the file, and checks that the text no longer contains mcp_servers.

Call relations: The test runner calls it. The direct blocking replace edit exercises the cleanup path for MCP servers, and the final assertion confirms the table was removed.

Call graph: 6 external calls (new, ReplaceMcpServers, assert!, read_to_string, write, tempdir).

fn trim_single_trailing_newline(contents: &str) -> &str

Purpose: This small helper removes one final newline from a text string if it has one. The tests use it so two otherwise identical files do not fail comparison just because one ends with a newline and the other does not.

Data flow: It receives a text slice. If the text ends with \n, it returns the same text without that last newline; otherwise it returns the original text unchanged. It does not allocate new text or change the original string.

Call relations: The exact schema text comparison calls this helper on both the repository fixture and the newly generated file. That lets the test focus on meaningful differences while tolerating a single trailing-newline mismatch.

fn config_schema_matches_fixture()

Purpose: This test makes sure the schema generated by the code matches the schema file committed to the repository. It protects users and tools from seeing an outdated config.schema.json.

Data flow: It starts by finding and reading the saved schema fixture. It also asks the config code to generate a fresh schema, then parses both as JSON values and normalizes them before comparing. If the normalized JSON differs, it builds a readable diff and fails the test with instructions to regenerate the fixture. After that, it writes a fresh schema to a temporary file and compares the actual file text against the fixture, with small allowances for line endings and one trailing newline.

Call relations: During the test suite, this function acts as the main guardrail for schema drift. It calls the schema generator and schema writer from the config module, uses JSON parsing to compare meaning rather than raw text first, and uses the helper trim_single_trailing_newline for the final exact-text check.

Call graph: 12 external calls (new, from_lines, assert_eq!, find_resource!, panic!, from_slice, from_str, to_string_pretty, read_to_string, canonicalize (+2 more)).

fn config_schema_hides_unsupported_inline_mcp_bearer_token()

Purpose: This test confirms that the public config schema does not expose an unsupported inline bearer_token setting for MCP server configuration. It also confirms that the safer bearer_token_env_var setting is still present.

Data flow: It generates the schema JSON, parses it into a JSON value, then looks inside the RawMcpServerConfig properties section. From that object, it checks whether two property names are present. The expected result is that bearer_token is absent and bearer_token_env_var is present.

Call relations: This test runs alongside the broader schema fixture test, but it checks one specific behavior directly. It depends on config_schema_json to produce the schema and then verifies the schema's public shape so users are guided away from putting bearer tokens directly in config files.

Call graph: 3 external calls (assert_eq!, from_slice, config_schema_json).

fn stdio_mcp(command: &str) -> McpServerConfig

Purpose: Builds a simple test MCP server configuration that would launch a local command through standard input and output. MCP means Model Context Protocol, a way for Codex to talk to external tools or services.

Data flow: It receives a command name as text, puts that command into an MCP server config with empty arguments and mostly default settings, and returns the ready-made config object. It does not start anything; it only creates test data.

Call relations: Several MCP allowlist tests call this helper when they need a fake local-command MCP server. It keeps those tests focused on filtering rules instead of repeating the same setup details.

Call graph: called by 5 (filter_mcp_servers_by_allowlist_allows_all_when_unset, filter_mcp_servers_by_allowlist_blocks_all_when_empty, filter_mcp_servers_by_allowlist_enforces_identity_rules, filter_plugin_mcp_servers_by_allowlist_blocks_unlisted_plugin, filter_plugin_mcp_servers_by_allowlist_enforces_plugin_and_identity_rules); 2 external calls (new, new).

fn http_mcp(url: &str) -> McpServerConfig

Purpose: Builds a simple test MCP server configuration that would connect over HTTP. It is used when tests need a fake network-based MCP server.

Data flow: It receives a URL, places it into an HTTP MCP transport config, fills the rest with safe default-like values, and returns the config object. No network request is made.

Call relations: MCP allowlist and plugin-selection tests call this helper to create repeatable HTTP server examples. It plays the same setup role as stdio_mcp, but for URL-based servers.

Call graph: called by 5 (filter_mcp_servers_by_allowlist_allows_all_when_unset, filter_mcp_servers_by_allowlist_blocks_all_when_empty, filter_mcp_servers_by_allowlist_enforces_identity_rules, filter_plugin_mcp_servers_by_allowlist_enforces_plugin_and_identity_rules, selected_plugin_wins_after_discovered_plugin_requirements); 1 external calls (new).

async fn derive_legacy_sandbox_policy_for_test(
    cfg: &ConfigToml,
    sandbox_mode_override: Option<SandboxMode>,
    windows_sandbox_level: WindowsSandboxLevel,
    active_project: Option<&Projec

Purpose: Converts the newer permission-profile configuration into the older sandbox policy shape used by legacy code paths. Tests use it to confirm old and new permission systems stay compatible.

Data flow: It receives a parsed config, optional sandbox override, Windows sandbox level, optional active project, and optional permission-profile constraint. It asks the config to derive a permission profile, then tries to turn that profile into a legacy sandbox policy rooted at /; if that conversion fails, it logs a warning and returns a read-only fallback.

Call relations: Sandbox-policy tests call this helper when they need to compare the newer permission model with the older sandbox representation. It hands off first to derive_permission_profile, then to the profile’s legacy conversion method.

Call graph: calls 1 internal fn (derive_permission_profile); called by 4 (derive_sandbox_policy_falls_back_to_read_only_for_implicit_defaults, derive_sandbox_policy_preserves_windows_downgrade_for_unsupported_fallback, test_sandbox_config_parsing, test_untrusted_project_gets_workspace_write_sandbox); 1 external calls (new).

async fn load_config_normalizes_relative_cwd_override() -> std::io::Result<()>

Purpose: Checks that a relative current-working-directory override is converted into an absolute path. This matters because later file access checks need one clear, unambiguous directory.

Data flow: The test creates the expected absolute path for nested, loads config with cwd set to the relative path nested, and checks that the resulting runtime config stores the absolute version.

Call relations: The Rust test runner executes this test. It calls the normal config-loading path so the same path-normalization behavior used in real runs is verified.

Call graph: calls 1 internal fn (relative_to_current_dir); 6 external calls (default, from, load_from_base_config_with_overrides, assert_eq!, default, tempdir).

async fn test_toml_parsing()

Purpose: Checks that several TOML snippets deserialize into the expected in-memory config values. It covers history settings and the memories feature, including an older legacy field name.

Data flow: The test feeds TOML strings into the TOML parser, compares the parsed structs with expected values, then loads one memories config into the full runtime config and checks that defaults and explicit values resolve correctly.

Call relations: The test runner calls it as part of the config test suite. It uses TOML parsing directly for raw config checks and Config::load_from_base_config_with_overrides for final runtime behavior.

Call graph: 5 external calls (load_from_base_config_with_overrides, assert!, assert_eq!, default, tempdir).

fn parses_bundled_skills_config()

Purpose: Verifies that bundled skills settings can be read from TOML. Skills here are built-in capability packs or instructions that Codex can include.

Data flow: It parses a TOML snippet with [skills] and [skills.bundled], then checks that the resulting config records bundled skills as disabled and instruction inclusion as false.

Call relations: The test runner calls it during config parsing tests. It exercises the TOML deserialization layer only, without loading the full runtime config.

Call graph: 2 external calls (assert_eq!, from_str).

fn tools_web_search_true_deserializes_to_none()

Purpose: Checks backward-compatible parsing for tools.web_search = true. The expected result is that the old boolean setting is accepted but does not create a detailed web-search config.

Data flow: It parses a TOML tools section with web_search = true and checks that the parsed web_search field is None, while other tool settings are also absent.

Call relations: The test runner calls it to guard old config compatibility. It relies only on TOML deserialization.

Call graph: 2 external calls (assert_eq!, from_str).

fn tools_web_search_false_deserializes_to_none()

Purpose: Checks backward-compatible parsing for tools.web_search = false. Like the true case, the old boolean form is accepted but ignored into an empty optional field.

Data flow: It parses a TOML tools section with web_search = false and confirms the resulting tools config has no detailed web-search value.

Call relations: The test runner calls it alongside the matching true-value test. Together they make sure either old boolean value remains harmless.

Call graph: 2 external calls (assert_eq!, from_str).

fn tools_experimental_request_user_input_defaults_to_enabled()

Purpose: Verifies that declaring the experimental request-user-input tool section without an explicit value turns it on by default.

Data flow: It parses an empty [tools.experimental_request_user_input] section and checks that the parsed config contains that tool with enabled set to true.

Call relations: The test runner calls it to protect default behavior at the TOML parsing layer.

Call graph: 2 external calls (assert_eq!, from_str).

fn tools_experimental_request_user_input_can_be_disabled()

Purpose: Verifies that the experimental request-user-input tool can be explicitly turned off in TOML.

Data flow: It parses a TOML section where enabled = false, then checks that the parsed tool config records enabled as false.

Call relations: The test runner calls it as the counterpart to the default-enabled test. It checks parsing, not full runtime loading.

Call graph: 2 external calls (assert_eq!, from_str).

async fn load_config_resolves_experimental_request_user_input_enabled() -> std::io::Result<()>

Purpose: Checks that the parsed request-user-input tool setting reaches the final runtime config. This ensures a user’s off switch is not lost during config loading.

Data flow: It builds a base config where the experimental tool is disabled, loads the full config, and verifies the final experimental_request_user_input_enabled flag is false.

Call relations: The test runner executes it. It passes through Config::load_from_base_config_with_overrides, so it covers the real config resolution path.

Call graph: 5 external calls (load_from_base_config_with_overrides, assert!, default, default, tempdir).

async fn load_config_resolves_code_mode_config() -> std::io::Result<()>

Purpose: Checks that code-mode feature settings load correctly, including excluded tool namespaces. A namespace is a named group of tools.

Data flow: It parses TOML enabling code mode and listing namespaces to exclude, loads the runtime config, then checks both the exclusion list and that the Code Mode feature is enabled.

Call relations: The test runner calls it to cover both TOML parsing and final feature resolution through the normal config loader.

Call graph: 6 external calls (load_from_base_config_with_overrides, assert!, assert_eq!, default, tempdir, from_str).

fn rejects_provider_auth_with_env_key()

Purpose: Ensures a model provider cannot define both an environment-variable API key and a custom auth command. That would be ambiguous because there would be two competing ways to get credentials.

Data flow: It parses an invalid provider config and expects parsing to fail. It then checks the error message names the exact conflict.

Call relations: The test runner calls this as a validation test. The failure happens during TOML deserialization.

Call graph: 1 external calls (assert!).

fn rejects_provider_aws_for_custom_provider()

Purpose: Ensures AWS-specific provider settings are only allowed for the built-in Amazon Bedrock provider. This prevents custom providers from accidentally accepting settings they cannot use.

Data flow: It parses a custom provider with an [aws] section, expects an error, and checks that the message explains AWS config is only supported for amazon-bedrock.

Call relations: The test runner calls it to guard provider validation in the config parser.

Call graph: 1 external calls (assert!).

fn accepts_amazon_bedrock_aws_profile_override()

Purpose: Checks that Amazon Bedrock accepts supported AWS override fields, specifically profile and region.

Data flow: It parses TOML under model_providers.amazon-bedrock.aws, then looks up the provider and confirms the profile and region values were stored.

Call relations: The test runner calls it as the positive counterpart to AWS provider rejection tests. It checks parsing only.

Call graph: 1 external calls (assert_eq!).

async fn load_config_applies_amazon_bedrock_aws_profile_override()

Purpose: Checks that Amazon Bedrock AWS profile and region overrides survive the full config-loading process.

Data flow: It parses a config selecting Amazon Bedrock and setting AWS profile and region, loads the runtime config, then checks the active provider ID and its AWS fields.

Call relations: The test runner calls it to verify the real loader applies the parsed provider override, not just that parsing succeeds.

Call graph: 4 external calls (load_from_base_config_with_overrides, assert_eq!, default, tempdir).

async fn load_config_rejects_unsupported_amazon_bedrock_overrides()

Purpose: Ensures Amazon Bedrock can only be customized in the supported AWS profile and region fields. Other provider fields are rejected to avoid creating a half-custom built-in provider.

Data flow: It parses TOML with both allowed AWS fields and unsupported provider changes, then loads config expecting an invalid-data error with a clear message.

Call relations: The test runner calls it to validate runtime config loading, because the rejection is checked when the full config is assembled.

Call graph: 5 external calls (load_from_base_config_with_overrides, assert!, assert_eq!, default, tempdir).

fn config_toml_deserializes_model_availability_nux()

Purpose: Checks that the TUI can remember how often a model-availability new-user notice has been shown for each model. TUI means terminal user interface.

Data flow: It parses a TOML map of model names to counts and checks that the parsed TUI config contains those counts plus the expected TUI defaults.

Call relations: The test runner calls it to protect TOML deserialization for terminal UI settings.

Call graph: 2 external calls (assert_eq!, from_str).

fn config_toml_status_line_use_colors_defaults_to_enabled()

Purpose: Verifies that the TUI status line uses colors by default when a [tui] section is present.

Data flow: It parses an otherwise empty TUI section and checks that status_line_use_colors is true.

Call relations: The test runner calls it as a default-value check in the TOML parsing layer.

Call graph: 2 external calls (assert!, from_str).

fn config_toml_deserializes_status_line_use_colors_disabled()

Purpose: Verifies that users can turn off colored status-line output in the TUI.

Data flow: It parses TOML with status_line_use_colors = false and checks that the parsed TUI config records false.

Call relations: The test runner calls it as the explicit-off counterpart to the default-enabled test.

Call graph: 2 external calls (assert!, from_str).

fn config_toml_deserializes_terminal_resize_reflow_config()

Purpose: Checks that the TUI resize reflow limit can be read from config. Reflow means rearranging terminal text after the window size changes.

Data flow: It parses TOML setting terminal_resize_reflow_max_rows to 9000 and checks that the parsed TUI config stores Some(9000).

Call relations: The test runner calls it to cover one specific TUI parsing field.

Call graph: 2 external calls (assert_eq!, from_str).

async fn runtime_config_defaults_model_availability_nux()

Purpose: Checks that the runtime config has a sensible default for model-availability notice tracking when no config is provided.

Data flow: It loads a completely default config and compares the final model_availability_nux value with its default struct.

Call relations: The test runner calls it to cover full config loading rather than just raw TOML parsing.

Call graph: 5 external calls (load_from_base_config_with_overrides, assert_eq!, default, default, tempdir).

fn test_tui_vim_mode_default_defaults_to_false()

Purpose: Verifies that Vim-style key behavior in the TUI is off unless the user enables it.

Data flow: It parses an empty TUI section and checks that vim_mode_default is false.

Call relations: The test runner calls it as a TUI default parsing check.

Call graph: 2 external calls (assert!, from_str).

fn test_tui_vim_mode_default_true()

Purpose: Verifies that Vim-style key behavior can be turned on in TUI config.

Data flow: It parses TOML with vim_mode_default = true and checks that the parsed TUI config records true.

Call relations: The test runner calls it as the explicit-on counterpart to the Vim-mode default test.

Call graph: 2 external calls (assert!, from_str).

fn test_tui_raw_output_mode_defaults_to_false()

Purpose: Checks that raw output mode in the TUI is off by default. Raw output mode likely means showing less-formatted or less-processed output.

Data flow: It parses an empty TUI section and checks that raw_output_mode is false.

Call relations: The test runner calls it to protect the default value in parsed config.

Call graph: 2 external calls (assert!, from_str).

fn test_tui_raw_output_mode_true()

Purpose: Checks that raw output mode can be enabled in TUI config.

Data flow: It parses TOML with raw_output_mode = true and confirms the parsed TUI config stores true.

Call relations: The test runner calls it as the explicit-on counterpart to the raw-output default test.

Call graph: 2 external calls (assert!, from_str).

async fn runtime_config_uses_tui_raw_output_mode()

Purpose: Checks that the raw output mode setting is carried into the final runtime config.

Data flow: It parses TOML enabling raw output mode, loads the full config, and checks that tui_raw_output_mode is true in the runtime config.

Call relations: The test runner calls it to verify the normal loader connects the parsed TUI setting to the runtime field.

Call graph: 5 external calls (load_from_base_config_with_overrides, assert!, default, tempdir, from_str).

fn config_toml_deserializes_permission_profiles()

Purpose: Checks that a rich permission profile can be read from TOML. The profile includes workspace roots, filesystem rules, network rules, and network MITM hooks; MITM means a controlled proxy can inspect or modify matching traffic.

Data flow: It parses a detailed permissions TOML example and compares the resulting nested config structs with the expected profile, including ordered hooks and action definitions.

Call relations: The test runner calls it to verify the parser accepts the full permission-profile shape that later runtime loading depends on.

Call graph: 2 external calls (assert_eq!, from_str).

fn config_toml_rejects_empty_mitm_action_reference_list()

Purpose: Ensures a network MITM hook cannot declare an empty action list. Failing closed is safer than silently doing nothing when traffic matches.

Data flow: It parses a TOML hook whose action array is empty, expects parsing to fail, and checks the error message points to the empty action list.

Call relations: The test runner calls it as a validation test for permission-profile TOML.

Call graph: 1 external calls (assert!).

fn config_toml_rejects_empty_mitm_action_definition()

Purpose: Ensures a named MITM action must actually do something, such as stripping or injecting a header.

Data flow: It parses TOML where a hook references an action, but the action definition is empty. It expects an error and checks that the message says at least one operation is required.

Call relations: The test runner calls it to make sure unsafe or meaningless MITM action definitions are rejected during parsing.

Call graph: 1 external calls (assert!).

fn permissions_profile_network_to_proxy_config_preserves_mitm_hooks()

Purpose: Checks that network permission TOML converts into proxy configuration without losing MITM hook details.

Data flow: It builds a network config in memory with one hook and one action, converts it to proxy config, and checks the mode, MITM flag, host, method, and header-stripping action.

Call relations: The test runner calls it to verify the conversion method used after parsing. It does not load a full app config.

Call graph: 7 external calls (from, new, assert!, assert_eq!, default, default, vec!).

fn permissions_profile_network_to_proxy_config_preserves_mitm_hook_declaration_order()

Purpose: Checks that MITM hooks keep the order users wrote them in. Order matters because earlier traffic rules may be more specific than later ones.

Data flow: It parses TOML with two hooks declared in a deliberate order, converts the network settings to proxy config, and checks the resulting hook list follows the same order.

Call relations: The test runner calls it to connect TOML parsing with proxy-config conversion behavior.

Call graph: 2 external calls (assert_eq!, from_str).

async fn permissions_profiles_proxy_policy_does_not_start_managed_network_proxy_without_feature() -> std::io::Result<()>

Purpose: Checks that simply enabling network access in a permission profile does not start the managed network proxy unless the feature is enabled.

Data flow: It creates temporary home and working directories, loads a config with network enabled in a permission profile, then verifies network sandboxing is enabled but no managed proxy config is present.

Call relations: The test runner calls it through the full config loader. It sets up a fake git workspace so project-root logic behaves like a real checkout.

Call graph: 8 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, write).

async fn permissions_profiles_proxy_policy_starts_managed_network_proxy() -> std::io::Result<()>

Purpose: Despite its name, this test confirms that a profile containing proxy settings still does not start the managed proxy when the network-proxy feature is not enabled.

Data flow: It loads a permission profile with network access, a proxy URL, and SOCKS disabled. The final config keeps network access enabled but leaves the managed proxy absent.

Call relations: The test runner calls it as a full-loader regression test. It is paired with later tests that enable the feature and expect the proxy to appear.

Call graph: 8 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, write).

async fn network_proxy_feature_is_no_op_without_sandbox_network() -> std::io::Result<()>

Purpose: Checks that enabling the network-proxy feature alone does nothing if sandbox network access is still off.

Data flow: It loads config with network_proxy = true but no permission setting that allows network access, then verifies the network policy remains restricted and no proxy config is created.

Call relations: The test runner calls it to prove the feature flag does not override the more basic network-sandbox decision.

Call graph: 6 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, from_str).

async fn network_proxy_feature_matrix_preserves_sandbox_network_semantics() -> std::io::Result<()>

Purpose: Tests many combinations of old and new network settings to ensure the network-proxy feature does not change whether network access itself is allowed.

Data flow: It loops over cases covering permission profiles and legacy workspace-write sandbox settings, with network access on or off and proxy feature on or off. For each case it loads config and checks the network sandbox policy and whether managed proxy config appears.

Call relations: The test runner calls it as a broad matrix test. It uses the normal loader for each case so interactions between legacy sandboxing, permission profiles, and feature flags are tested together.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert_eq!, Access, write).

async fn network_proxy_cli_overrides_merge_toggle_with_proxy_config() -> std::io::Result<()>

Purpose: Checks that command-line overrides can turn on the network proxy while also changing proxy details such as SOCKS support.

Data flow: It writes a real config file enabling workspace-write network access, builds config with CLI overrides for the network proxy feature and SOCKS setting, then checks that the proxy starts with the expected host and SOCKS disabled.

Call relations: The test runner calls it through ConfigBuilder, which simulates a more realistic config load from disk plus command-line overrides.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 6 external calls (default, new, assert!, assert_eq!, write, vec!).

async fn experimental_network_requirements_enable_proxy_without_feature() -> std::io::Result<()>

Purpose: Checks that enterprise-style experimental network requirements can configure the managed proxy even when the user-facing network-proxy feature flag is off.

Data flow: It builds config using a cloud config bundle fixture that declares experimental network enabled. The final config should not report the normal feature flag as enabled, but should report managed network requirements and have an enabled proxy config.

Call relations: The test runner calls it through ConfigBuilder and a cloud-config fixture. This covers managed configuration, not ordinary user TOML.

Call graph: calls 2 internal fn (loader_with_enterprise_requirement, without_managed_config_for_tests); 2 external calls (new, assert!).

async fn network_proxy_feature_uses_profile_network_proxy_settings() -> std::io::Result<()>

Purpose: Checks that when the network-proxy feature is enabled, proxy settings from the active permission profile are used.

Data flow: It loads a config with network_proxy = true, network access enabled, a custom proxy URL, and SOCKS disabled. It checks the final network policy, proxy host and port, and SOCKS state.

Call relations: The test runner calls it as the positive version of the earlier no-feature proxy tests.

Call graph: 8 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, from_str).

async fn disabled_network_proxy_feature_does_not_start_profile_proxy_policy() -> std::io::Result<()>

Purpose: Checks that explicitly disabling the network-proxy feature prevents the managed proxy from starting, even when a permission profile includes proxy settings.

Data flow: It loads a profile with network access and proxy details, but a feature config where network proxy is disabled. It verifies the feature is off and the runtime permissions contain no managed proxy.

Call relations: The test runner calls it to guard the off switch for proxy startup.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert!, Access, from_str).

async fn permissions_profiles_network_disabled_by_default_does_not_start_proxy() -> std::io::Result<()>

Purpose: Checks that network rules such as allowed domains do not imply network access is enabled. The user must explicitly enable network access before proxy-related behavior can start.

Data flow: It loads a permission profile with a domain allow rule but no enabled = true, then checks that no managed network proxy config exists.

Call relations: The test runner calls it through the full config loader, with a fake git workspace for realistic workspace-root behavior.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert!, Access, write).

async fn default_permissions_profile_populates_runtime_sandbox_policy() -> std::io::Result<()>

Purpose: Checks that selecting a default permission profile produces the expected runtime filesystem and network sandbox rules. A sandbox is a safety boundary that limits what files or network resources code can use.

Data flow: It creates a temporary workspace with a docs folder, loads a config whose default profile grants minimal read access, write access to the workspace root, and read access to docs. It then checks the runtime filesystem policy, legacy sandbox projection, write denial for .git, network restriction, and active profile ID.

Call relations: The test runner calls it as a core end-to-end permission-profile test. It verifies both the new runtime permission model and the older legacy sandbox view.

Call graph: 10 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, Scoped, create_dir_all, write).

async fn default_permissions_extended_profile_preserves_parent_metadata() -> std::io::Result<()>

Purpose: Checks that when a permission profile extends another profile, the final active-profile metadata still records that parent relationship.

Data flow: It loads a config with a base profile and a dev profile that extends it. The final config should show dev as active and base as its parent.

Call relations: The test runner calls it to protect profile inheritance metadata during full config loading.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert_eq!, Access, write).

async fn permission_profile_override_populates_runtime_permissions() -> std::io::Result<()>

Purpose: Checks that a direct permission-profile override wins and fills the runtime permissions. In this case, the override disables sandbox restrictions, resulting in full access.

Data flow: It loads default config with a harness override setting the permission profile to Disabled, then verifies the effective profile, absence of an active named profile, and legacy full-access sandbox.

Call relations: The test runner calls it through the config loader using overrides, similar to how a harness or command-line layer can force settings.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, default).

fn permission_snapshot_setter_preserves_permission_constraints()

Purpose: Checks that restoring permissions from a session snapshot cannot violate existing permission constraints. A constraint is a rule saying which values are allowed.

Data flow: It creates permissions constrained to allow only a read-only profile, then tries to apply a workspace-write snapshot. The setter returns an error, and the original read-only profile remains unchanged.

Call relations: The test runner calls it directly on the permissions object. It exercises the snapshot setter rather than full config loading.

Call graph: calls 7 internal fn (new, allow_any, allow_only, from_approval_and_profile, active, read_only, workspace_write); 2 external calls (assert!, assert_eq!).

async fn permission_profile_override_preserves_managed_unrestricted_filesystem() -> std::io::Result<()>

Purpose: Checks that a managed permission profile with unrestricted filesystem access is preserved, while network access remains restricted.

Data flow: It loads config with a managed override specifying unrestricted filesystem and restricted network. It then checks the effective profile and the legacy projection, which becomes an external sandbox with restricted network.

Call relations: The test runner calls it through the normal loader to verify managed-profile overrides survive config resolution.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, default).

async fn managed_unrestricted_permission_profile_still_enables_network_requirements() -> std::io::Result<()>

Purpose: Checks that managed network requirements can still be recognized even when the legacy sandbox view of a managed unrestricted profile is lossy.

Data flow: It loads a managed profile with unrestricted filesystem and enabled network, confirms the legacy projection is full access, then rebuilds the config layer stack with network requirements and checks that managed network requirements are considered enabled.

Call relations: The test runner calls it to cover a subtle interaction between permission profiles, legacy sandbox projection, and managed configuration requirements.

Call graph: calls 2 internal fn (new, new); 6 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default).

async fn permission_profile_override_keeps_memories_root_out_of_legacy_projection() -> std::io::Result<()>

Purpose: Checks that a permission-profile override does not accidentally add the memories storage directory to the old legacy sandbox’s writable paths.

Data flow: It builds a permission profile from runtime filesystem rules that allow writing project roots but only reading the root. After loading config, it checks the memories directory is not writable and that the legacy sandbox projection has no writable roots.

Call relations: The test runner calls it to guard against leaking extra write access when converting newer permissions into the older sandbox format.

Call graph: calls 2 internal fn (from_runtime_permissions, restricted); 7 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default, vec!).

async fn permission_profile_override_preserves_configured_network_policy_without_starting_proxy() -> std::io::Result<()>

Purpose: Checks that a permission-profile override can replace the effective permission profile without accidentally starting a managed proxy from the configured profile.

Data flow: It loads a config containing a named profile with network and proxy settings, while also passing an override that disables permissions. The final config has no managed network proxy and uses the override profile.

Call relations: The test runner calls it through the full loader to verify override precedence and proxy-startup rules work together.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access).

async fn workspace_root_glob_none_compiles_to_filesystem_pattern_entry() -> std::io::Result<()>

Purpose: Checks that a glob pattern under workspace roots, such as **/*.env, becomes a real filesystem glob rule rather than a literal project-root entry. This matters because deny rules for matching files must actually match files across workspace roots.

Data flow: It creates temporary project roots, builds a custom permission profile with a scoped workspace rule, and loads that config. It then reads the produced filesystem sandbox policy and verifies that each workspace root has a deny glob entry for .env files, while no unexpanded special-path entry remains.

Call relations: The Rust test runner calls this test. Inside, it drives Config::load_from_base_config_with_overrides, then uses path resolution and policy inspection to confirm that config loading translated the user-facing rule into concrete sandbox entries.

Call graph: calls 1 internal fn (resolve_path_against_base); 9 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Scoped, write, vec!).

async fn permissions_profiles_require_default_permissions() -> std::io::Result<()>

Purpose: Ensures Codex rejects a config that defines custom permission profiles but does not say which one should be active. Without this, Codex would have to guess which access rules to use.

Data flow: It builds a config with a permissions table but no default_permissions value. Loading the config is expected to fail, and the test checks that the failure is an invalid-input error with a specific message.

Call relations: The test runner invokes this as a negative test. It calls the main config loader and confirms that the loader stops early instead of silently choosing a profile.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert_eq!, Access, write).

async fn default_permissions_can_select_builtin_profile_without_permissions_table() -> std::io::Result<()>

Purpose: Checks that a built-in permission profile can be selected directly, even when the config does not define any custom permission profiles. This lets users choose standard safe modes without writing a full permissions table.

Data flow: It loads a config whose default_permissions names the built-in workspace profile. The resulting config is inspected to confirm explicit profile mode is active, no custom profiles exist, the active profile is the workspace profile, the project root is writable, and .git metadata is protected.

Call relations: The test runner calls this test. The test relies on config loading to expand a built-in profile into a filesystem sandbox policy, then checks the policy’s write decisions.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!).

async fn default_permissions_read_only_keeps_add_dir_read_only() -> std::io::Result<()>

Purpose: Verifies that selecting the built-in read-only profile stays read-only even when extra writable roots are supplied at runtime. This prevents a read-only choice from being weakened by separate command-line or runtime options.

Data flow: It creates a current directory and an additional root, loads config with the built-in read-only profile, and passes the additional root as an override. It then checks that the additional root cannot be written and that the active profile is read-only.

Call relations: The test runner calls this test during config tests. It exercises the interaction between default_permissions and ConfigOverrides.additional_writable_roots through the config loader.

Call graph: 6 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, vec!).

async fn workspace_profile_applies_rules_to_runtime_and_profile_workspace_roots() -> std::io::Result<()>

Purpose: Checks that workspace-root rules apply both to runtime roots and roots declared inside a permission profile. This ensures all intended project areas get the same protection and access behavior.

Data flow: It creates three fake project roots: the current directory, a runtime extra root, and a profile-defined root. After loading a custom profile, it verifies which roots are stored as runtime workspace roots, which roots are effective overall, and whether the sandbox allows writing roots while blocking .git and .codex inside each one.

Call relations: The test runner calls this test. It sends both config-defined roots and override-defined roots into the config loader, then checks the resulting permissions object and filesystem policy.

Call graph: 9 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Scoped, create_dir_all, vec!).

async fn explicit_builtin_workspace_profile_ignores_legacy_workspace_write_settings() -> std::io::Result<()>

Purpose: Ensures that explicitly choosing the built-in workspace profile does not accidentally inherit older sandbox_workspace_write settings. This avoids mixing two configuration systems in a way that grants unexpected access.

Data flow: It loads config with default_permissions set to the built-in workspace profile while also providing legacy writable roots and network access. It then confirms the network remains restricted and the legacy extra root is not added as a direct filesystem grant.

Call relations: The test runner invokes this test. It checks that the modern permission-profile path in Config::load_from_base_config_with_overrides takes precedence over legacy sandbox settings.

Call graph: 6 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, vec!).

async fn default_permissions_profile_can_extend_builtin_workspace() -> std::io::Result<()>

Purpose: Checks that a custom profile can extend the built-in workspace profile and selectively override parts of it. This lets users start from a safe default and make small changes.

Data flow: It defines a custom profile that extends workspace access, adds network access, and changes the temporary-directory rule from write to read. After loading, it checks that project-root writes and metadata protections are inherited, slash-temp write access remains, tmpdir write access is replaced by read access, network access is enabled, and the active profile records its parent.

Call relations: The test runner calls this test. The config loader combines the built-in parent profile with the custom child profile, and the test verifies the merged result.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access).

async fn default_permissions_profile_can_extend_builtin_read_only() -> std::io::Result<()>

Purpose: Checks that a custom profile can extend the built-in read-only profile without losing its read-only filesystem behavior. It also confirms the child can enable network access.

Data flow: It loads a custom profile that extends read-only and turns on network access. The resulting policy is checked to ensure the current directory can be read but not written, while the network sandbox policy is enabled and the active profile records the extension.

Call relations: The test runner invokes this test. It exercises profile inheritance in the config loader for the read-only built-in profile.

Call graph: 6 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!).

async fn empty_config_defaults_to_builtin_profile_for_trusted_project() -> std::io::Result<()>

Purpose: Checks which built-in permission profile Codex chooses when there is no explicit permission config but the current project is trusted. This preserves the expected fallback behavior.

Data flow: It marks the temporary project as trusted, loads otherwise empty config, and inspects the chosen active profile and filesystem policy. On Windows it expects read-only behavior because sandbox support differs; on other systems it expects workspace-write behavior with metadata carveouts.

Call relations: The test runner calls this test. It feeds project trust information into the config loader and checks the fallback permission decision.

Call graph: 7 external calls (default, from, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!).

async fn empty_config_defaults_to_builtin_profile_for_untrusted_project() -> std::io::Result<()>

Purpose: Checks the default permission profile when the config is empty but the project is marked untrusted. The test documents the current fallback behavior while still checking that access is not broader than intended on Windows.

Data flow: It loads config for an untrusted temporary project, then checks the active built-in profile and whether the current directory can be read and, depending on the operating system, written. It also verifies metadata carveouts for the workspace behavior on non-Windows systems.

Call relations: The test runner invokes this test. The config loader combines project trust data with platform-specific sandbox behavior, and the test checks the resulting policy.

Call graph: 7 external calls (default, from, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!).

async fn implicit_builtin_workspace_profile_preserves_sandbox_workspace_write_settings() -> std::io::Result<()>

Purpose: Checks that when Codex implicitly falls back to workspace-write mode, older workspace-write settings are still honored. This keeps backward compatibility for users who have not moved to explicit permission profiles.

Data flow: It loads config for a trusted project with legacy writable roots, network access, and temp-directory exclusions. The resulting policy must allow writing the extra root, enable network access, report no clean active permission profile, and project back to the expected legacy sandbox policy.

Call relations: The test runner calls this test. It exercises the compatibility path where the config loader derives modern permissions from legacy sandbox settings.

Call graph: 8 external calls (default, from, new, load_from_base_config_with_overrides, assert!, assert_eq!, panic!, vec!).

async fn implicit_builtin_workspace_profile_preserves_add_dir_metadata_carveouts() -> std::io::Result<()>

Purpose: Verifies that additional writable roots keep protective carveouts for metadata directories like .git, .agents, and .codex when workspace mode is chosen implicitly. This prevents extra roots from becoming too open.

Data flow: It creates an extra root with metadata subdirectories, loads config that falls back to workspace permissions, and passes the extra root as an additional writable root. The policy must allow writing the root itself but deny writing the sensitive metadata subdirectories.

Call relations: The test runner invokes this test. It checks the config loader’s legacy-compatible treatment of additional_writable_roots.

Call graph: 7 external calls (default, from, new, load_from_base_config_with_overrides, assert!, create_dir_all, vec!).

async fn empty_config_defaults_to_builtin_read_only_without_trust_decision() -> std::io::Result<()>

Purpose: Checks that with no project trust decision and no explicit permission settings, Codex defaults to read-only access. This is the safer choice when Codex does not know whether the project should be trusted.

Data flow: It loads a completely default config in a temporary directory. The resulting policy is checked to ensure the current directory can be read but not written.

Call relations: The test runner calls this test. It exercises the config loader’s safest fallback path.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert!, default).

async fn default_permissions_can_select_builtin_full_access_profile() -> std::io::Result<()>

Purpose: Checks that the built-in full-access profile can be selected by its current supported name. This mode disables the sandbox, so the test makes sure it is represented clearly.

Data flow: It loads config with default_permissions set to the full-access built-in profile. The resulting permission profile is expected to be disabled, meaning no sandbox restriction, and the active profile ID must match the requested built-in name.

Call relations: The test runner invokes this test. It calls the config loader and checks the permission-profile object that comes out.

Call graph: 4 external calls (default, new, load_from_base_config_with_overrides, assert_eq!).

async fn legacy_danger_no_sandbox_is_rejected() -> std::io::Result<()>

Purpose: Ensures an old full-access alias is no longer accepted as a built-in profile name. This avoids silently supporting stale or misleading configuration.

Data flow: It loads config with default_permissions set to :danger-no-sandbox. Loading must fail, and the test checks the exact error message explaining that the built-in profile is unknown.

Call relations: The test runner calls this negative test. It confirms that config loading validates built-in profile names rather than mapping old aliases.

Call graph: 4 external calls (default, new, load_from_base_config_with_overrides, assert_eq!).

async fn user_defined_permission_profile_names_cannot_use_builtin_prefix() -> std::io::Result<()>

Purpose: Checks that custom permission profiles cannot use names beginning with the reserved built-in prefix :. This prevents user-defined names from being confused with Codex’s built-in profiles.

Data flow: It defines a custom profile named :custom and tries to select it. The loader must reject the config with an invalid-input error and a clear message about the reserved prefix.

Call relations: The test runner invokes this test. It drives the config loader’s profile-name validation.

Call graph: 6 external calls (from, default, new, load_from_base_config_with_overrides, assert_eq!, default).

async fn unknown_builtin_permission_profile_name_is_rejected() -> std::io::Result<()>

Purpose: Ensures that a default_permissions value that looks like a built-in profile but is not recognized is rejected. This catches typos instead of falling back to a surprising mode.

Data flow: It loads config with default_permissions = ':unknown'. Loading must fail with an invalid-input error saying the built-in profile is unknown.

Call relations: The test runner calls this negative test. It verifies built-in profile lookup in the config loader.

Call graph: 4 external calls (default, new, load_from_base_config_with_overrides, assert_eq!).

async fn permissions_profiles_allow_direct_write_roots_outside_workspace_root() -> std::io::Result<()>

Purpose: Checks that a custom permission profile can directly grant write access to an absolute path outside the project workspace. This supports deliberate access to external folders.

Data flow: It creates a project and a separate external directory, defines a profile granting write access to the external absolute path, and loads the config. It then checks the custom profile summary, confirms the path is writable, and verifies the legacy sandbox projection includes that path as a writable root.

Call relations: The test runner invokes this test. It exercises absolute-path entries in permission profiles and their conversion into both modern and legacy sandbox views.

Call graph: calls 1 internal fn (from_absolute_path); 9 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, canonicalize, write).

async fn permissions_profiles_reject_nested_entries_for_non_workspace_roots() -> std::io::Result<()>

Purpose: Ensures nested subpath rules are rejected for special entries that do not support them. This prevents configs that look precise but cannot be interpreted safely.

Data flow: It defines a scoped rule under :minimal with a nested docs entry. Loading is expected to fail with an invalid-input error explaining that :minimal does not support nested entries.

Call relations: The test runner calls this negative test. It checks validation inside the config loader before such rules become sandbox policies.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert_eq!, Scoped, write).

async fn load_workspace_permission_profile(
    profile: PermissionProfileToml,
) -> std::io::Result<Config>

Purpose: Provides a small helper for tests that need to load a single custom permission profile named dev. It avoids repeating the same temporary project setup in several related tests.

Data flow: It receives a PermissionProfileToml, creates temporary Codex home and project directories, writes a fake .git marker, wraps the profile in a config with default_permissions = 'dev', and returns the loaded Config or an I/O error.

Call relations: This helper is called by the tests for unknown special paths and missing or empty filesystem sections. It hands their supplied profile to Config::load_from_base_config_with_overrides and returns the full config for inspection.

Call graph: called by 4 (permissions_profiles_allow_empty_filesystem_with_warning, permissions_profiles_allow_missing_filesystem_with_warning, permissions_profiles_allow_unknown_special_paths, permissions_profiles_allow_unknown_special_paths_with_nested_entries); 5 external calls (from, default, new, load_from_base_config_with_overrides, write).

async fn permissions_profiles_allow_unknown_special_paths() -> std::io::Result<()>

Purpose: Checks forward compatibility for unknown special filesystem paths. Older Codex versions should warn and ignore what they do not understand rather than crashing on future config keys.

Data flow: It uses load_workspace_permission_profile to load a profile containing :future_special_path. The resulting policy keeps an unknown special-path entry, the legacy sandbox view is read-only, and startup warnings mention that the path is not recognized.

Call relations: The test runner calls this test, which delegates setup to load_workspace_permission_profile. It then inspects both the modern policy and compatibility warnings.

Call graph: calls 1 internal fn (load_workspace_permission_profile); 4 external calls (from, assert!, assert_eq!, Access).

async fn permissions_profiles_allow_unknown_special_paths_with_nested_entries() -> std::io::Result<()>

Purpose: Checks that unknown future special paths with nested entries are also tolerated with a warning. This keeps configuration files usable across versions.

Data flow: It loads a profile containing :future_special_path with a nested docs rule. The policy records an unknown special path with that subpath, and startup warnings explain that the combination is not recognized and will be ignored.

Call relations: The test runner invokes this test. It uses load_workspace_permission_profile for setup, then checks the policy and warnings.

Call graph: calls 1 internal fn (load_workspace_permission_profile); 4 external calls (from, assert!, assert_eq!, Scoped).

async fn permissions_profiles_allow_missing_filesystem_with_warning() -> std::io::Result<()>

Purpose: Ensures a custom permission profile with no filesystem section is allowed but produces a warning. This is safer than failing immediately while still telling the user the profile grants no recognized file access.

Data flow: It loads a profile whose filesystem field is absent. The resulting filesystem sandbox policy is restricted with no entries, the legacy view is read-only, and startup warnings mention that the profile has no recognized filesystem entries.

Call relations: The test runner calls this test. It relies on load_workspace_permission_profile for the standard profile-loading setup.

Call graph: calls 1 internal fn (load_workspace_permission_profile); 2 external calls (assert!, assert_eq!).

async fn permissions_profiles_allow_empty_filesystem_with_warning() -> std::io::Result<()>

Purpose: Checks that an explicitly empty filesystem section is treated like no recognized filesystem access and produces a warning. This helps users notice a profile that may not do what they intended.

Data flow: It loads a profile with an empty filesystem entries map. The resulting policy is restricted with no entries, and startup warnings mention that profile dev defines no recognized filesystem entries.

Call relations: The test runner invokes this test. It uses load_workspace_permission_profile to load the test profile before checking the warning and policy.

Call graph: calls 1 internal fn (load_workspace_permission_profile); 3 external calls (new, assert!, assert_eq!).

async fn permissions_profiles_reject_workspace_root_parent_traversal() -> std::io::Result<()>

Purpose: Ensures workspace-root scoped entries cannot use .. to escape to a parent or sibling directory. This is an important safety check against granting access outside the intended project tree.

Data flow: It defines a scoped workspace-root rule for ../sibling and tries to load the config. Loading must fail with an invalid-input error saying the subpath must be a descendant path without . or .. components.

Call relations: The test runner calls this negative test. It verifies path validation inside the permission-profile loader.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert_eq!, Scoped, write).

async fn permissions_profiles_allow_network_enablement() -> std::io::Result<()>

Purpose: Checks that a custom permission profile can explicitly enable network access. This confirms filesystem permissions and network permissions are combined correctly.

Data flow: It loads a dev profile with minimal read filesystem access and network.enabled = true. The resulting permissions must report enabled network access, and the legacy sandbox projection must also show full network access.

Call relations: The test runner invokes this test. It exercises the config loader’s network section and its conversion to the older sandbox-policy view.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert!, Access, write).

fn tui_theme_deserializes_from_toml()

Purpose: Checks that the terminal UI theme setting can be read from TOML. This lets users choose a named visual theme.

Data flow: It parses a small TOML snippet with [tui] theme = 'dracula'. The parsed config is checked to ensure the TUI theme field contains dracula.

Call relations: The test runner calls this parser-focused test. It uses TOML deserialization directly rather than the full runtime config loader.

Call graph: 1 external calls (assert_eq!).

fn tui_theme_defaults_to_none()

Purpose: Checks that if a TUI section does not name a theme, the theme remains unset. This lets later code choose the normal default behavior.

Data flow: It parses a TOML snippet with an empty [tui] section. The parsed config is checked to confirm the theme field is None.

Call relations: The test runner invokes this direct TOML deserialization test.

Call graph: 1 external calls (assert_eq!).

fn tui_session_picker_view_deserializes_from_toml()

Purpose: Checks that the TUI session picker view mode can be read from TOML. In this case, the text value dense must become the matching enum value.

Data flow: It parses [tui] session_picker_view = 'dense' and inspects the parsed TUI config. The output must contain SessionPickerViewMode::Dense.

Call relations: The test runner calls this test. It validates the TOML-to-typed-config conversion for this UI setting.

Call graph: 1 external calls (assert_eq!).

fn tui_pet_deserializes_from_toml()

Purpose: Checks that the optional TUI pet name can be read from TOML. This is a simple parser test for a user-facing interface option.

Data flow: It parses [tui] pet = 'chefito'. The parsed config should contain the string chefito in the TUI pet field.

Call relations: The test runner invokes this direct TOML parsing test.

Call graph: 1 external calls (assert_eq!).

fn tui_session_picker_view_defaults_to_none()

Purpose: Checks that the session picker view setting is unset when not provided. This separates raw parsed config from runtime defaults that may be applied later.

Data flow: It parses an empty [tui] section and checks that session_picker_view is None.

Call relations: The test runner calls this parser-default test.

Call graph: 1 external calls (assert_eq!).

fn tui_pet_defaults_to_none()

Purpose: Checks that no TUI pet is selected when the config does not provide one. This prevents accidental default pets at the raw TOML layer.

Data flow: It parses an empty [tui] section and verifies the pet field is None.

Call relations: The test runner invokes this TOML deserialization test.

Call graph: 1 external calls (assert_eq!).

fn tui_pet_anchor_deserializes_from_toml()

Purpose: Checks that the TUI pet anchor position can be read from TOML. The value screen-bottom must map to the screen-bottom enum setting.

Data flow: It parses [tui] pet_anchor = 'screen-bottom' and verifies the parsed TUI config contains TuiPetAnchor::ScreenBottom.

Call relations: The test runner calls this parser test. It verifies accepted text values for the pet anchor option.

Call graph: 1 external calls (assert_eq!).

fn tui_pet_anchor_defaults_to_composer()

Purpose: Checks that an empty TUI section gives the pet anchor its default location, the composer. This means the default is applied during TUI config deserialization.

Data flow: It parses an empty [tui] section and checks that pet_anchor is TuiPetAnchor::Composer.

Call relations: The test runner invokes this default-value test for TOML parsing.

Call graph: 1 external calls (assert_eq!).

fn tui_pet_anchor_rejects_unknown_value()

Purpose: Ensures unknown pet anchor values are rejected with a useful error. This helps users fix typos instead of getting a silently ignored setting.

Data flow: It parses TOML containing pet_anchor = 'bottom' and expects parsing to fail. The error text must mention the unknown value and the accepted alternatives.

Call relations: The test runner calls this negative parser test. It checks the TOML deserializer’s validation for enum values.

Call graph: 1 external calls (assert!).

fn tui_config_missing_notifications_field_defaults_to_enabled()

Purpose: Checks the full default TUI config when the [tui] section exists but omits notification settings. This protects the expected defaults for many interface options.

Data flow: It parses an empty [tui] section, extracts the TUI config, and compares it to an explicit Tui value. The expected value includes default notifications, animations, tooltips, colors, pet anchor, keymap, and other UI defaults.

Call relations: The test runner invokes this deserialization test. It verifies that the Tui data model’s defaults are applied consistently.

Call graph: 1 external calls (assert_eq!).

async fn runtime_config_resolves_terminal_resize_reflow_defaults_and_overrides()

Purpose: Checks how the runtime config resolves terminal resize reflow row limits. This setting controls how much terminal content Codex may reflow after resize, including default, limited, and disabled modes.

Data flow: It loads default config and expects automatic row handling. It then loads config with terminal_resize_reflow_max_rows = 9000 and expects a numeric limit, then loads config with 0 and expects limits to be disabled.

Call relations: The test runner calls this async test. Unlike raw TOML parser tests, it goes through Config::load_from_base_config_with_overrides to verify final runtime settings.

Call graph: 6 external calls (default, load_from_base_config_with_overrides, assert_eq!, default, default, tempdir).

async fn forced_chatgpt_workspace_id_empty_values_disable_runtime_restriction() -> std::io::Result<()>

Purpose: Checks how empty or blank forced_chatgpt_workspace_id values are normalized. Empty values should mean no runtime workspace restriction, while real IDs should be trimmed and kept.

Data flow: It loops over several TOML snippets: unset, empty string, whitespace, empty list, blank list entries, and mixed blank plus real IDs. Each is parsed and loaded, then the final config field is compared to either None or the cleaned list of workspace IDs.

Call relations: The test runner invokes this async test. It combines TOML parsing with the full config loader to check final normalized runtime behavior.

Call graph: 6 external calls (load_from_base_config_with_overrides, assert_eq!, default, tempdir, from_str, vec!).

async fn legacy_remote_thread_store_endpoint_is_rejected()

Purpose: Ensures an old remote thread-store endpoint setting still parses but is rejected when the config is loaded. This gives users a clear message that the feature is no longer supported.

Data flow: It parses TOML containing experimental_thread_store_endpoint, then passes it to the config loader. Loading must fail, and the error text must mention the setting and say it is no longer supported.

Call relations: The test runner calls this test. It separates deserialization compatibility from runtime validation: old config can be read far enough to produce a helpful load-time error.

Call graph: 5 external calls (load_from_base_config_with_overrides, assert!, default, tempdir, from_str).

fn profile_tui_rejects_unsupported_settings()

Purpose: Checks that profile-specific TUI config rejects unsupported fields such as theme. This prevents users from thinking a per-profile UI setting works when it does not.

Data flow: It parses TOML with [profiles.work.tui] theme = 'dark' and expects parsing to fail. The error must mention an unknown field and name theme.

Call relations: The test runner invokes this direct TOML parser test. It checks validation for profile-scoped TUI settings.

Call graph: 1 external calls (assert!).

async fn runtime_config_resolves_session_picker_view_default_and_override()

Purpose: Checks the final runtime default and override behavior for the TUI session picker view. The raw config can be unset, but runtime config should choose a concrete mode.

Data flow: It first loads default config and expects the runtime session picker view to be Dense. It then loads config with the root TUI setting set to Comfortable and expects the runtime value to match the override.

Call relations: The test runner calls this async test. It uses the full config loader to verify final runtime values, not just raw TOML fields.

Call graph: 6 external calls (default, load_from_base_config_with_overrides, assert_eq!, default, default, tempdir).

async fn test_sandbox_config_parsing()

Purpose: Checks legacy sandbox mode parsing for full access, read-only, and workspace-write modes. This protects backward-compatible sandbox behavior while accounting for platform differences.

Data flow: It parses several TOML snippets and passes each to a test helper that derives the legacy sandbox policy. It verifies that full-access ignores workspace-write network settings, read-only ignores workspace-write network settings, and workspace-write produces writable roots and temp exclusions on non-Windows while falling back to read-only on Windows.

Call relations: The test runner invokes this async test. It calls derive_legacy_sandbox_policy_for_test, uses test path helpers to build platform-safe absolute paths, and compares the derived policy to expected SandboxPolicy values.

Call graph: calls 1 internal fn (derive_legacy_sandbox_policy_for_test); 4 external calls (assert_eq!, cfg!, test_absolute_path, format!).

async fn legacy_sandbox_mode_builds_profiles_with_compatible_projection() -> std::io::Result<()>

Purpose: Checks that old-style sandbox settings still produce the newer permission profile correctly. This protects users who still have legacy config files from getting different file or network access than they asked for.

Data flow: The test creates temporary Codex and working folders, then tries three legacy sandbox modes. Each config string is loaded into a Config, converted into the newer file-system and network policies, and compared back to the legacy policy. The result should be a round trip: old setting in, equivalent new permission policy out.

Call relations: The test runner calls this during configuration tests. It exercises Config::load_from_base_config_with_overrides and the conversion methods between legacy sandbox policies and the newer permissions model.

Call graph: 9 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!, test_absolute_path, unreachable!, vec!).

fn filter_mcp_servers_by_allowlist_enforces_identity_rules()

Purpose: Checks that MCP servers are only kept enabled when both their name and identity match an allowed requirement. Identity means the actual command or URL, not just the display name.

Data flow: The test starts with several fake MCP servers, some command-based and some URL-based. It supplies requirements that allow only exact command or URL matches. After filtering, matching servers remain enabled and mismatched or unlisted servers are disabled with a requirements reason.

Call relations: The test runner calls this to verify filter_mcp_servers_by_requirements. It protects the rule that an allowlist is not just a list of names; it must also confirm what the server actually connects to or runs.

Call graph: calls 3 internal fn (new, http_mcp, stdio_mcp); 3 external calls (from, from, assert_eq!).

fn filter_mcp_servers_by_allowlist_allows_all_when_unset()

Purpose: Checks that if no MCP requirements are provided, existing MCP servers are not blocked. This preserves the normal user-configured behavior when there is no managed allowlist.

Data flow: The test creates two fake servers and passes no requirements into the filter. The servers go in enabled and come out still enabled, with no disabled reason added.

Call relations: The test runner calls this around the same filtering helper as the stricter allowlist tests. It confirms that filter_mcp_servers_by_requirements only restricts servers when a requirements source exists.

Call graph: calls 2 internal fn (http_mcp, stdio_mcp); 2 external calls (from, assert_eq!).

fn filter_mcp_servers_by_allowlist_blocks_all_when_empty()

Purpose: Checks that an explicitly empty MCP allowlist blocks every configured MCP server. An empty policy means nothing is approved, not that the policy is absent.

Data flow: The test creates two fake servers and passes an empty requirements map with a managed-policy source. The filter changes both servers to disabled and records that requirements caused the disablement.

Call relations: The test runner calls this to verify the difference between no requirements and empty requirements. It exercises filter_mcp_servers_by_requirements in the strict managed-policy case.

Call graph: calls 3 internal fn (new, http_mcp, stdio_mcp); 3 external calls (new, from, assert_eq!).

fn filter_plugin_mcp_servers_by_allowlist_enforces_plugin_and_identity_rules()

Purpose: Checks that MCP servers coming from a plugin must be allowed for that specific plugin and must match the required identity. This stops one plugin from getting approval meant for another or from changing the server command behind the same name.

Data flow: The test creates plugin-derived MCP servers, then supplies requirements for one plugin. One server name and command match, another has the right name but wrong command, and another is unlisted. After filtering, only the exact match remains enabled.

Call relations: The test runner calls this to exercise filter_plugin_mcp_servers_by_requirements. It connects plugin identity rules to the same allowlist safety model used for global MCP servers.

Call graph: calls 3 internal fn (new, http_mcp, stdio_mcp); 3 external calls (from, from, assert_eq!).

fn filter_plugin_mcp_servers_by_allowlist_blocks_unlisted_plugin()

Purpose: Checks that if requirements mention a different plugin, this plugin's MCP servers are disabled. This prevents requirements for one plugin from accidentally approving another plugin.

Data flow: The test creates one server for sample@test but supplies requirements only for other@test. Filtering marks the sample@test server disabled and records the requirements source.

Call relations: The test runner calls this as a plugin-specific allowlist edge case. It verifies that filter_plugin_mcp_servers_by_requirements checks the plugin key before looking at server names.

Call graph: calls 2 internal fn (new, stdio_mcp); 3 external calls (from, from, assert_eq!).

async fn rebuild_preserving_session_layers_refreshes_requirements() -> std::io::Result<()>

Purpose: Checks that rebuilding configuration keeps session-level choices but refreshes managed requirements and non-session layers. This matters when a running conversation needs updated policy without losing temporary session overrides.

Data flow: The test builds one refreshed config stack with new user, project, and managed settings plus requirements. It builds another older thread config stack with session overrides. Rebuilding combines them: session overrides remain where allowed, managed requirements are refreshed, and disallowed session-only MCP servers become disabled.

Call relations: The test runner calls this to exercise Config::rebuild_preserving_session_layers. It also uses ConfigLayerStack and Config::load_config_with_layer_stack to model the same layered loading path used by the application.

Call graph: calls 3 internal fn (new, new, resolve_path_against_base); 6 external calls (from, default, new, load_config_with_layer_stack, assert_eq!, vec!).

async fn rebuild_preserving_session_layers_refreshes_plugin_derived_mcp_config() -> anyhow::Result<()>

Purpose: Checks that rebuilding configuration can turn plugin-derived MCP servers on when the refreshed config enables plugins. Plugin MCP servers are servers declared by an installed plugin rather than directly by the user.

Data flow: The test writes fake plugin metadata and an .mcp.json file to a temporary plugin cache. It builds a refreshed config with plugins enabled and an older thread config with plugins disabled. After rebuilding, converting to MCP config includes the plugin's server and records which plugin supplied it.

Call relations: The test runner calls this around Config::rebuild_preserving_session_layers and Config::to_mcp_config. It verifies that plugin discovery is based on the refreshed effective config, not stale thread settings.

Call graph: calls 3 internal fn (new, new, resolve_path_against_base); 7 external calls (default, new, load_config_with_layer_stack, assert_eq!, create_dir_all, write, vec!).

async fn to_mcp_config_omits_plugin_id_when_user_server_shadows_plugin_mcp() -> anyhow::Result<()>

Purpose: Checks that a user-defined MCP server wins over a plugin-defined MCP server with the same name, and that the winning server is not falsely labeled as plugin-provided.

Data flow: The test writes a plugin server named sample and a user config server with the same name but a different URL. After loading config and converting to MCP config, the user URL is present and the plugin attribution map is empty.

Call relations: The test runner calls this to verify ConfigBuilder loading and Config::to_mcp_config. It protects the precedence rule that direct user config shadows plugin-provided MCP entries.

Call graph: calls 1 internal fn (new); 6 external calls (new, assert!, assert_eq!, default, create_dir_all, write).

async fn selected_plugin_wins_after_discovered_plugin_requirements() -> anyhow::Result<()>

Purpose: Checks that a server explicitly selected from a plugin can override a disabled discovered plugin server. This allows deliberate user selection while still enforcing enterprise requirements on automatically discovered servers.

Data flow: The test creates a plugin with two servers and an enterprise requirement that allows only one. The unlisted discovered server is disabled. Then the test converts to MCP config again with an explicit selected-plugin registration for that unlisted name, and the selected server appears as enabled with selected-plugin source information.

Call relations: The test runner calls this to exercise Config::to_mcp_config and Config::to_mcp_config_with_plugin_registrations. It checks the ordering between discovered plugin requirements and explicit plugin selections.

Call graph: calls 5 internal fn (new, from_selected_plugin, loader_with_enterprise_requirement, new, http_mcp); 5 external calls (new, assert_eq!, default, create_dir_all, write).

async fn to_mcp_config_empty_mcp_requirements_disable_plugin_mcps() -> anyhow::Result<()>

Purpose: Checks that an enterprise policy with an empty MCP server allowlist disables MCP servers supplied by plugins. Empty means no plugin MCP server is approved.

Data flow: The test creates a plugin with one MCP server, enables the plugin, and loads an enterprise requirement containing an empty mcp_servers table. The resulting MCP config still knows about the server, but marks it disabled with the enterprise requirements reason.

Call relations: The test runner calls this through ConfigBuilder and Config::to_mcp_config. It complements the global MCP empty-allowlist test for plugin-derived servers.

Call graph: calls 2 internal fn (loader_with_enterprise_requirement, new); 5 external calls (new, assert_eq!, default, create_dir_all, write).

async fn add_dir_override_extends_workspace_writable_roots() -> std::io::Result<()>

Purpose: Checks that command-line extra writable directories are added to workspace-write sandbox permissions without duplication. This lets a user work across nearby project folders without granting broader access.

Data flow: The test creates frontend and backend folders, starts in frontend, and passes backend twice in two forms: relative and absolute. The loaded config should include backend once as a writable root, except on Windows where this legacy sandbox mode downgrades to read-only.

Call relations: The test runner calls this to exercise Config::load_from_base_config_with_overrides. It verifies how sandbox overrides feed into the legacy sandbox policy.

Call graph: 9 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, cfg!, default, panic!, create_dir_all, vec!).

async fn default_zsh_path_sets_runtime_zsh_path() -> std::io::Result<()>

Purpose: Checks that a provided default zsh shell path is copied into the runtime config. This lets packaged builds tell Codex where their bundled zsh lives.

Data flow: The test creates a fake path named packaged-zsh and passes it as an override. Config loading returns a Config whose zsh_path field points to that path.

Call relations: The test runner calls this through Config::load_from_base_config_with_overrides. It confirms that loader overrides can set runtime-only values not necessarily written in the user TOML.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, default).

async fn sqlite_home_defaults_to_codex_home_for_workspace_write() -> std::io::Result<()>

Purpose: Checks that SQLite data defaults to the Codex home folder when workspace-write sandbox mode is used. This keeps database files in a known writable place.

Data flow: The test loads default config with a workspace-write sandbox override. The resulting sqlite_home field should equal the temporary Codex home path.

Call relations: The test runner calls this to verify default path selection inside Config::load_from_base_config_with_overrides.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, default).

async fn workspace_write_includes_configured_writable_root_once_without_memories_root() -> std::io::Result<()>

Purpose: Checks that configured writable roots are deduplicated and that the memories folder is not automatically created or made writable. This avoids both clutter and accidental write permission expansion.

Data flow: The test supplies the same writable root twice and enables workspace-write mode. On non-Windows systems, the final policy contains that root once and does not contain the memories root. The memories directory should not exist as a side effect of config loading.

Call relations: The test runner calls this around Config::load_from_base_config_with_overrides and legacy sandbox policy creation. It covers a subtle permission edge case for memory-related paths.

Call graph: 8 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!, panic!, vec!).

async fn memory_tool_makes_memories_root_readable_without_creating_or_widening_writes() -> std::io::Result<()>

Purpose: Checks that enabling the memories feature makes the memories folder readable but not writable, and does not create it during config loading. Read access lets the tool inspect memories without granting unnecessary write access.

Data flow: The test enables the memories feature and workspace-write mode, then loads config. It verifies the memories directory was not created, the file-system policy can read that path, and it cannot write it. On non-Windows systems, the legacy writable-roots list also excludes it.

Call relations: The test runner calls this to verify the newer file-system permission policy and its legacy projection. It exercises Config::load_from_base_config_with_overrides and permission queries.

Call graph: calls 1 internal fn (from); 7 external calls (from, default, new, load_from_base_config_with_overrides, assert!, cfg!, panic!).

async fn config_defaults_to_file_cli_auth_store_mode() -> std::io::Result<()>

Purpose: Checks that CLI authentication credentials default to file storage. This gives a predictable fallback when the user has not asked for keychain or ephemeral storage.

Data flow: The test loads an empty config. The resulting cli_auth_credentials_store_mode should be File.

Call relations: The test runner calls this through Config::load_from_base_config_with_overrides. It establishes the default used before any explicit credential-store setting is resolved.

Call graph: 5 external calls (new, load_from_base_config_with_overrides, assert_eq!, default, default).

async fn config_resolves_explicit_keyring_auth_store_mode() -> std::io::Result<()>

Purpose: Checks that an explicit keyring request for CLI credentials is passed through the resolver. The resolver may adjust the choice depending on the build version.

Data flow: The test loads config with cli_auth_credentials_store set to Keyring. It compares the final mode to resolve_cli_auth_credentials_store_mode for the current package version.

Call relations: The test runner calls this to connect TOML parsing, config loading, and credential-store resolution.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, default).

async fn config_resolves_default_oauth_store_mode() -> std::io::Result<()>

Purpose: Checks that MCP OAuth credential storage defaults are resolved through the OAuth store resolver. OAuth credentials are tokens used to authorize MCP servers.

Data flow: The test loads empty config. The final mcp_oauth_credentials_store_mode should match resolving Auto for the current package version.

Call relations: The test runner calls this through Config::load_from_base_config_with_overrides. It verifies default OAuth storage behavior.

Call graph: 5 external calls (new, load_from_base_config_with_overrides, assert_eq!, default, default).

fn local_dev_builds_force_file_cli_auth_store_modes()

Purpose: Checks that local development builds force CLI credential storage to file for Auto and Keyring choices. This avoids using a real system keyring during local development, while still allowing ephemeral storage.

Data flow: The test calls the CLI credential-store resolver with a local development version string and several requested modes. Keyring and Auto become File, Ephemeral stays Ephemeral, and a normal version keeps Keyring.

Call relations: The test runner calls this directly against resolve_cli_auth_credentials_store_mode. It isolates the version-based rule from the rest of config loading.

Call graph: 1 external calls (assert_eq!).

fn local_dev_builds_force_file_mcp_oauth_store_modes()

Purpose: Checks that local development builds force MCP OAuth credential storage to file for Auto and Keyring choices. This keeps development runs from depending on the operating system keyring.

Data flow: The test calls the OAuth credential-store resolver with the local development version and with a normal release version. Local Auto and Keyring become File, while a normal release Keyring stays Keyring.

Call relations: The test runner calls this directly against resolve_mcp_oauth_credentials_store_mode. It mirrors the CLI credential-store test for MCP OAuth tokens.

Call graph: 1 external calls (assert_eq!).

async fn feedback_enabled_defaults_to_true() -> std::io::Result<()>

Purpose: Checks that a present but otherwise default feedback config leaves feedback enabled. This prevents an empty feedback table from accidentally turning feedback off.

Data flow: The test loads config with a default feedback section. The final feedback_enabled field is true.

Call relations: The test runner calls this through Config::load_from_base_config_with_overrides. It verifies the defaulting rule for feedback settings.

Call graph: 6 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, default, default).

fn web_search_mode_defaults_to_none_if_unset()

Purpose: Checks that web search has no explicit mode when neither config nor legacy feature flags request it. None means the rest of the system can apply its normal fallback.

Data flow: The test creates empty config and default feature settings, then resolves web search mode. The result is None.

Call relations: The test runner calls this directly against resolve_web_search_mode. It establishes the baseline before override cases.

Call graph: calls 1 internal fn (with_defaults); 2 external calls (assert_eq!, default).

fn web_search_mode_prefers_config_over_legacy_flags()

Purpose: Checks that the newer web_search config field wins over older feature flags. This avoids conflicting settings producing surprising results.

Data flow: The test sets web_search to Live and also enables an older cached-search feature flag. Resolving the mode returns Live from the config field.

Call relations: The test runner calls this against resolve_web_search_mode. It documents precedence between modern config and legacy flags.

Call graph: calls 1 internal fn (with_defaults); 2 external calls (default, assert_eq!).

fn web_search_mode_disabled_overrides_legacy_request()

Purpose: Checks that explicitly disabling web search wins even if an older flag requests web search. User or policy intent to disable should be respected.

Data flow: The test sets web_search to Disabled and enables a legacy request flag. Resolving returns Disabled.

Call relations: The test runner calls this against resolve_web_search_mode as another precedence case.

Call graph: calls 1 internal fn (with_defaults); 2 external calls (default, assert_eq!).

fn web_search_mode_for_turn_uses_preference_for_read_only()

Purpose: Checks that read-only permission mode does not change a cached web search preference. Read-only still permits the preferred cached search behavior.

Data flow: The test wraps Cached in a constrained setting and uses a read-only permission profile. The per-turn resolver returns Cached.

Call relations: The test runner calls this directly against resolve_web_search_mode_for_turn. It verifies interaction between web search and permission profiles.

Call graph: calls 2 internal fn (allow_any, read_only); 1 external calls (assert_eq!).

fn web_search_mode_for_turn_prefers_live_for_disabled_permissions()

Purpose: Checks that when permissions are disabled, cached web search is promoted to live search if live search is allowed. This reflects the runtime's preferred behavior for that permission profile.

Data flow: The test starts with a constrained setting that allows any mode and prefers Cached. With PermissionProfile::Disabled, the resolver returns Live.

Call relations: The test runner calls this against resolve_web_search_mode_for_turn. It covers the special case for disabled permission profiles.

Call graph: calls 1 internal fn (allow_any); 1 external calls (assert_eq!).

fn web_search_mode_for_turn_respects_disabled_for_disabled_permissions()

Purpose: Checks that an explicit Disabled web search preference remains disabled even when permissions are disabled. The resolver should not turn web search on against the setting.

Data flow: The test starts with Disabled as the allowed preference and a disabled permission profile. The per-turn mode remains Disabled.

Call relations: The test runner calls this against resolve_web_search_mode_for_turn. It guards against over-eager fallback to live search.

Call graph: calls 1 internal fn (allow_any); 1 external calls (assert_eq!).

fn web_search_mode_for_turn_falls_back_when_live_is_disallowed() -> anyhow::Result<()>

Purpose: Checks that if live web search is not allowed by a constraint, the resolver falls back to the configured cached mode. A constraint is a rule that rejects disallowed values.

Data flow: The test creates a constrained web search setting that allows only Disabled and Cached. With disabled permissions, the resolver would normally prefer Live, but Live is rejected, so it returns Cached.

Call relations: The test runner calls this against resolve_web_search_mode_for_turn. It verifies that policy constraints are honored during fallback.

Call graph: calls 1 internal fn (new); 1 external calls (assert_eq!).

async fn project_profiles_are_ignored() -> std::io::Result<()>

Purpose: Checks that profile declarations inside project-local config are ignored and produce a warning. This stops a project folder from silently selecting a profile that should only be chosen from user-level config.

Data flow: The test writes a trusted project entry in user config and a project .codex config that names a profile and model. Loading config for that workspace leaves the model unset and records a startup warning telling the user to move those settings to user-level config if desired.

Call relations: The test runner calls this through ConfigBuilder. It verifies the project config loading path and warning behavior.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 7 external calls (default, new, assert!, assert_eq!, format!, create_dir_all, write).

async fn feature_table_overrides_legacy_flags() -> std::io::Result<()>

Purpose: Checks that the modern features table can turn off a feature even if older defaults or flags might say otherwise. This makes the feature table the clear source of truth.

Data flow: The test sets apply_patch_freeform to false in the features table. After loading config, the ApplyPatchFreeform feature is not enabled.

Call relations: The test runner calls this through Config::load_from_base_config_with_overrides. It checks feature resolution from TOML.

Call graph: calls 1 internal fn (from); 6 external calls (new, default, new, load_from_base_config_with_overrides, assert!, default).

async fn legacy_toggles_map_to_features() -> std::io::Result<()>

Purpose: Checks that older experimental toggle fields still enable the corresponding new feature flag. This keeps old config files working after feature settings were reorganized.

Data flow: The test sets experimental_use_unified_exec_tool to true. The loaded config has the UnifiedExec feature enabled and also keeps the legacy boolean field true.

Call relations: The test runner calls this through Config::load_from_base_config_with_overrides. It verifies backward compatibility between old and new feature controls.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert!, default).

async fn responses_websocket_features_do_not_change_wire_api() -> std::io::Result<()>

Purpose: Checks that enabling response websocket feature flags does not change the selected wire API. Wire API means the network protocol shape used to talk to the model provider.

Data flow: The test enables each websocket-related feature key in turn and loads config. In both cases, the model provider still uses the Responses wire API.

Call relations: The test runner calls this through Config::load_from_base_config_with_overrides. It protects against feature flags accidentally changing provider protocol selection.

Call graph: calls 1 internal fn (from); 6 external calls (new, default, new, load_from_base_config_with_overrides, assert_eq!, default).

async fn config_honors_explicit_file_oauth_store_mode() -> std::io::Result<()>

Purpose: Checks that an explicit request to store MCP OAuth credentials in files is honored. This gives users or policy a clear way to avoid keyring storage.

Data flow: The test loads config with mcp_oauth_credentials_store set to File. The final OAuth store mode is File.

Call relations: The test runner calls this through Config::load_from_base_config_with_overrides. It complements the default and keyring OAuth store tests.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, default).

async fn managed_config_overrides_oauth_store_mode() -> anyhow::Result<()>

Purpose: Checks that managed configuration can override the user's OAuth credential storage choice. Managed config usually represents enterprise policy and must take precedence.

Data flow: The test writes user config requesting File and managed config requesting Keyring. It loads the layered config, confirms the effective TOML says Keyring, then builds the final Config and confirms the resolved OAuth store mode follows Keyring for the current version.

Call relations: The test runner calls this through load_config_layers_state, deserialize_config_toml_with_base, and Config::load_from_base_config_with_overrides. It verifies precedence across the full managed-config path.

Call graph: calls 1 internal fn (with_managed_config_path_for_tests); 6 external calls (new, new, load_from_base_config_with_overrides, assert_eq!, default, write).

async fn load_global_mcp_servers_returns_empty_if_missing() -> anyhow::Result<()>

Purpose: Checks that asking for global MCP servers from a home folder with no config returns an empty set rather than an error. Missing config is a normal first-run state.

Data flow: The test creates an empty temporary Codex home and calls load_global_mcp_servers. The result is an empty map.

Call relations: The test runner calls this directly against load_global_mcp_servers. It verifies graceful behavior for absent config files.

Call graph: 2 external calls (new, assert!).

async fn replace_mcp_servers_round_trips_entries() -> anyhow::Result<()>

Purpose: Checks that replacing the global MCP server list writes all important fields and can later read them back. It also checks that replacing with an empty list removes the servers.

Data flow: The test builds a docs MCP server with command, arguments, working directory, timeouts, environment id, and enabled status. It applies a ReplaceMcpServers edit, reloads global servers, and checks the fields survived. Then it applies an empty replacement and reloads to confirm the list is empty.

Call relations: The test runner calls this through apply_blocking and load_global_mcp_servers. It verifies the edit-and-read path for global MCP configuration.

Call graph: calls 1 internal fn (apply_blocking); 10 external calls (new, from_secs, new, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, vec!).

async fn managed_config_wins_over_cli_overrides() -> anyhow::Result<()>

Purpose: Checks that managed config has higher priority than command-line overrides. This is important because enterprise policy should not be bypassed by a local CLI flag.

Data flow: The test writes user config with model base, managed config with model managed_config, and passes a CLI override model cli. The layered effective config deserializes to model managed_config.

Call relations: The test runner calls this through load_config_layers_state and deserialize_config_toml_with_base. It focuses specifically on layer precedence.

Call graph: calls 1 internal fn (with_managed_config_path_for_tests); 4 external calls (new, String, assert_eq!, write).

async fn load_global_mcp_servers_accepts_legacy_ms_field() -> anyhow::Result<()>

Purpose: Checks that the old startup_timeout_ms field is still accepted for MCP servers. This keeps older config files working even if the preferred representation changed.

Data flow: The test writes a docs MCP server using startup_timeout_ms equal to 2500. Loading global MCP servers returns a server whose startup timeout is 2500 milliseconds.

Call relations: The test runner calls this directly against load_global_mcp_servers. It verifies backward-compatible parsing.

Call graph: 3 external calls (new, assert_eq!, write).

fn mcp_servers_toml_parses_per_tool_approval_overrides()

Purpose: Checks that MCP TOML can set both a default tool approval mode and an approval override for a specific tool. Approval mode controls whether a tool can run automatically or must ask.

Data flow: The test parses TOML for a docs server with a default prompt mode and a search tool set to approve. The parsed ConfigToml contains both settings in the expected fields.

Call relations: The test runner calls this by deserializing ConfigToml directly. It verifies the shape of MCP server TOML parsing.

Call graph: 1 external calls (assert_eq!).

fn mcp_servers_toml_ignores_unknown_server_fields()

Purpose: Checks that unknown fields inside an MCP server entry are ignored rather than failing parsing. This gives some tolerance for older or newer config fields.

Data flow: The test parses a docs MCP server containing an unrecognized trust_level field. Parsing succeeds and the server equals the expected command-based server.

Call relations: The test runner calls this through TOML deserialization of ConfigToml. It verifies forgiving parsing for MCP server entries.

Call graph: 1 external calls (assert_eq!).

fn mcp_servers_toml_parses_tool_approval_override_for_reserved_name()

Purpose: Checks that a tool named command can still have its approval override parsed. This matters because command is also a meaningful server field name, so the parser must not confuse the two.

Data flow: The test parses TOML with mcp_servers.docs.tools.command.approval_mode set to approve. The parsed server contains a tool config for the tool name command with approval mode Approve.

Call relations: The test runner calls this by deserializing ConfigToml. It guards against naming collisions in the nested MCP tools table.

Call graph: 1 external calls (assert_eq!).

fn desktop_toml_round_trips_opaque_nested_values() -> anyhow::Result<()>

Purpose: Checks that desktop-specific settings can store arbitrary nested values and survive serialization. Opaque here means the core config code does not need to understand every desktop setting.

Data flow: The test parses a desktop table with strings, arrays, and nested objects. It confirms the values are stored as JSON-like data, serializes the config back to TOML, reparses it, and confirms the desktop data is unchanged.

Call relations: The test runner calls this through ConfigToml TOML parse and serialization. It protects desktop settings from being lost or reshaped by core config code.

Call graph: 2 external calls (assert_eq!, to_string).

async fn to_mcp_config_preserves_apps_feature_from_config() -> std::io::Result<()>

Purpose: Checks that app-related MCP settings flow from Config into the MCP runtime config. It also verifies that the Apps feature flag actually controls whether apps are enabled.

Data flow: The test loads default config, sets an apps product SKU, and converts to MCP config, which should enable apps and carry the SKU. Then it disables and re-enables the Apps feature and checks the MCP config follows the feature state.

Call relations: The test runner calls this around Config::to_mcp_config. It verifies the bridge from general config features into MCP runtime settings.

Call graph: calls 1 internal fn (new); 6 external calls (new, load_from_base_config_with_overrides, assert!, assert_eq!, default, default).

async fn to_mcp_config_flows_mcp_tool_prefix_from_feature() -> std::io::Result<()>

Purpose: Checks that the feature controlling MCP tool name prefixes is reflected in MCP runtime config. Prefixing helps avoid tool-name collisions, while the feature can turn that off.

Data flow: The test converts default config to MCP config and sees prefix_mcp_tool_names enabled. After enabling the NonPrefixedMcpToolNames feature, converting again reports prefixing disabled.

Call relations: The test runner calls this through Config::to_mcp_config. It verifies feature-to-runtime translation for MCP tool naming.

Call graph: calls 1 internal fn (new); 5 external calls (new, load_from_base_config_with_overrides, assert!, default, default).

async fn to_mcp_config_preserves_auth_elicitation_feature_from_config() -> std::io::Result<()>

Purpose: Checks that enabling the auth elicitation feature gives MCP clients form and URL elicitation capabilities. Elicitation means the server can ask the client to collect information from the user, such as an auth form or link.

Data flow: The test converts default config and sees the default client elicitation capability. After enabling AuthElicitation, converting again includes form and URL capabilities.

Call relations: The test runner calls this through Config::to_mcp_config. It verifies that an experimental feature flag reaches the MCP client capability settings.

Call graph: calls 1 internal fn (new); 5 external calls (new, load_from_base_config_with_overrides, assert_eq!, default, default).

async fn load_global_mcp_servers_rejects_inline_bearer_token() -> anyhow::Result<()>

Purpose: Checks that MCP server config rejects an inline bearer token and tells users to use an environment-variable form instead. A bearer token is a secret credential, and storing it directly in config is unsafe.

Data flow: The test writes an MCP server with a URL and bearer_token value. Loading global MCP servers returns an InvalidData error whose message mentions bearer_token and bearer_token_env_var.

Call relations: The test runner calls this directly against load_global_mcp_servers. It enforces a security rule in config parsing.

Call graph: 4 external calls (new, assert!, assert_eq!, write).

async fn replace_mcp_servers_serializes_env_sorted() -> anyhow::Result<()>

Purpose: Checks that environment variables for a command-based MCP server are written in a stable alphabetical order and can be loaded back. This matters because predictable config output is easier to review and avoids noisy file changes.

Data flow: It starts with a temporary Codex home and one MCP server named docs whose environment variables are deliberately out of order. It applies a replace-server edit, reads the generated config file, and expects ALPHA_VAR before ZIG_VAR. It then reloads the server config and confirms the command, arguments, environment variables, empty inherited-variable list, and missing working directory all survived.

Call relations: The test runner calls this test. Inside the test, apply_blocking performs the config edit, the filesystem read checks the exact TOML text, and load_global_mcp_servers proves the written file can be read back into the same server shape.

Call graph: calls 1 internal fn (apply_blocking); 11 external calls (from, from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string (+1 more)).

async fn replace_mcp_servers_serializes_env_vars() -> anyhow::Result<()>

Purpose: Checks that a command-based MCP server can record which environment variables should be inherited by name. These are not fixed values; they are names like ALPHA and BETA that Codex should pick up from the surrounding environment.

Data flow: It builds a temporary config with one docs server whose env_vars list contains ALPHA and BETA. After applying the replacement, it reads the config file and checks that the list appears. It then reloads the MCP servers and verifies the docs server still has the same env_vars list.

Call relations: The test runner invokes it as part of the config tests. It uses apply_blocking to write the server table and load_global_mcp_servers to confirm the serialized field is understood on the way back in.

Call graph: calls 1 internal fn (apply_blocking); 10 external calls (from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string, vec!).

async fn replace_mcp_servers_serializes_sourced_env_vars() -> anyhow::Result<()>

Purpose: Checks that environment variable references can include a named source, not just a plain variable name. This supports cases where a value should come from a specific provider such as a remote source.

Data flow: It creates a docs MCP server with two inherited environment entries: a legacy plain name and a structured entry with name REMOTE_TOKEN and source remote. It writes the config, checks that the mixed list is serialized in TOML, then reloads everything and compares the loaded map with the original map.

Call relations: The test runner calls this. The test exercises apply_blocking for writing and load_global_mcp_servers for reading, making sure newer structured env-var syntax stays compatible with older plain-string syntax.

Call graph: calls 1 internal fn (apply_blocking); 9 external calls (from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, read_to_string, vec!).

async fn replace_mcp_servers_serializes_cwd() -> anyhow::Result<()>

Purpose: Checks that a command-based MCP server can store its working directory. A working directory tells the server where it should behave as if it was started from.

Data flow: It prepares one docs server with cwd set to /tmp/codex-mcp. After applying the server replacement, it reads the config file and checks for the cwd field. It then reloads the server and confirms the path is present on the command-based transport.

Call relations: The test runner invokes it. The edit path goes through apply_blocking, and the verification path goes through the written TOML plus load_global_mcp_servers.

Call graph: calls 1 internal fn (apply_blocking); 10 external calls (from, new, from, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string).

async fn replace_mcp_servers_streamable_http_serializes_bearer_token() -> anyhow::Result<()>

Purpose: Checks that an HTTP-based MCP server can save a bearer-token environment variable name. A bearer token is a secret access token; the config stores the environment variable name, not the secret itself.

Data flow: It creates a docs server using a streamable HTTP URL, with bearer_token_env_var set to MCP_TOKEN and a startup timeout of two seconds. It writes the config and compares the exact TOML output. Then it reloads the server and confirms the URL, token variable name, absence of header maps, and timeout value.

Call relations: The test runner calls it. apply_blocking writes the server replacement, while load_global_mcp_servers confirms the HTTP transport settings and timeout survive a write-read cycle.

Call graph: calls 1 internal fn (apply_blocking); 9 external calls (from, from_secs, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string).

async fn replace_mcp_servers_streamable_http_serializes_custom_headers() -> anyhow::Result<()>

Purpose: Checks that an HTTP-based MCP server can save fixed HTTP headers and headers whose values come from environment variables. Headers are extra pieces of information sent with an HTTP request.

Data flow: It creates a docs HTTP MCP server with a URL, bearer-token variable, startup timeout, one fixed header, and one environment-backed header. It applies the config edit, reads the generated TOML, and expects separate sections for fixed and environment-backed headers. It reloads the config and confirms both header maps match.

Call relations: The test runner invokes it. The test uses apply_blocking to serialize nested HTTP options and load_global_mcp_servers to make sure those nested sections are parsed back into the HTTP transport.

Call graph: calls 1 internal fn (apply_blocking); 9 external calls (from, from_secs, from, new, new, ReplaceMcpServers, assert_eq!, panic!, read_to_string).

async fn replace_mcp_servers_streamable_http_removes_optional_sections() -> anyhow::Result<()>

Purpose: Checks that optional HTTP MCP server settings are removed from the config file when they are no longer present. This prevents stale bearer tokens, headers, or timeout values from lingering after a user clears them.

Data flow: It first writes a docs HTTP server with optional token, header sections, and timeout, then verifies those items appear. It then replaces the same server with only a URL and no optional values. The final config is expected to contain only the URL, and the reloaded server should have no token, no headers, and no startup timeout.

Call relations: The test runner calls it. It runs apply_blocking twice to mimic updating an existing config, then uses a direct file check and load_global_mcp_servers to ensure old optional sections were actually deleted, not merely ignored.

Call graph: calls 1 internal fn (apply_blocking); 10 external calls (from, from_secs, from, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string).

async fn replace_mcp_servers_streamable_http_isolates_headers_between_servers() -> anyhow::Result<()>

Purpose: Checks that HTTP-specific header settings stay attached only to the HTTP server they belong to. This protects other MCP servers from accidentally receiving unrelated authentication or header configuration.

Data flow: It writes two MCP servers: docs uses streamable HTTP with custom headers, while logs uses a command-based server with no headers. It reads the config and checks that only docs has header sections. It reloads the config and confirms docs kept its headers while logs still has no environment map.

Call relations: The test runner invokes it. apply_blocking writes a multi-server replacement, and load_global_mcp_servers verifies that serialization did not smear HTTP options across neighboring server entries.

Call graph: calls 1 internal fn (apply_blocking); 12 external calls (from, from_secs, from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, panic! (+2 more)).

async fn replace_mcp_servers_serializes_disabled_flag() -> anyhow::Result<()>

Purpose: Checks that a disabled MCP server is written with enabled = false and loads back as disabled. This lets users keep a server definition without currently using it.

Data flow: It creates a docs command-based MCP server with enabled set to false. After applying the replacement, it reads the config text and checks for the disabled flag. It reloads the servers and confirms docs.enabled is false.

Call relations: The test runner calls this test. It relies on apply_blocking to write the edit and load_global_mcp_servers to prove the disabled state is not lost.

Call graph: calls 1 internal fn (apply_blocking); 7 external calls (from, new, new, new, ReplaceMcpServers, assert!, read_to_string).

async fn replace_mcp_servers_serializes_required_flag() -> anyhow::Result<()>

Purpose: Checks that an MCP server marked as required is saved and loaded correctly. A required server likely means Codex should treat that tool provider as important rather than optional.

Data flow: It creates a docs command-based server with required set to true, writes it to the config file, and checks that the TOML contains required = true. It then reloads the server map and confirms the required flag is true.

Call relations: The test runner invokes it. The test follows the standard write-read path: apply_blocking writes the replacement, and load_global_mcp_servers validates the result.

Call graph: calls 1 internal fn (apply_blocking); 7 external calls (from, new, new, new, ReplaceMcpServers, assert!, read_to_string).

async fn replace_mcp_servers_serializes_tool_filters() -> anyhow::Result<()>

Purpose: Checks that per-server tool allow and block lists are saved and read back. These lists let a user say which tools from an MCP server may or may not be used.

Data flow: It creates a docs server with enabled_tools set to allowed and disabled_tools set to blocked. After writing the config, it checks that both lists appear in the TOML. It reloads the servers and verifies both lists are present on the docs server.

Call relations: The test runner calls it. apply_blocking serializes the tool filters, and load_global_mcp_servers confirms the filters remain attached to the server.

Call graph: calls 1 internal fn (apply_blocking); 9 external calls (from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, read_to_string, vec!).

async fn replace_mcp_servers_streamable_http_serializes_oauth_resource() -> anyhow::Result<()>

Purpose: Checks that an HTTP MCP server can store OAuth-related information. OAuth is a common login/permission system; here the test verifies both the client ID and the resource URL are preserved.

Data flow: It builds a docs HTTP server with an OAuth client ID and oauth_resource URL. It writes the config, checks that the OAuth section and resource field appear, reloads the server, and confirms the resource and client ID can be read from the loaded config.

Call relations: The test runner invokes it. apply_blocking writes the OAuth-related fields, and load_global_mcp_servers checks that those fields are parsed into the MCP server config correctly.

Call graph: calls 1 internal fn (apply_blocking); 7 external calls (from, new, new, ReplaceMcpServers, assert!, assert_eq!, read_to_string).

async fn set_model_updates_defaults() -> anyhow::Result<()>

Purpose: Checks that the config edit builder can set the default model and reasoning effort. Reasoning effort is the model’s requested depth of thinking, such as high.

Data flow: It starts with an empty temporary config area. The edit builder sets model to gpt-5.4 and reasoning effort to High, then applies the edit. The test reads the generated config file, parses it as TOML, and confirms both default fields were written.

Call relations: The test runner calls it. It exercises ConfigEditsBuilder::new, set_model, and apply, then uses TOML parsing to inspect the written result.

Call graph: calls 1 internal fn (new); 4 external calls (new, assert_eq!, read_to_string, from_str).

async fn for_config_writes_selected_user_config_file() -> anyhow::Result<()>

Purpose: Checks that edits go to the user-selected config file, not always the base config file. This matters when a user is working with a named profile stored in a separate config file.

Data flow: It creates two config files: the base config with a provider setting and a selected work config with an old model. It builds a Config that points at the selected file, applies a model update through ConfigEditsBuilder::for_config, then reads both files. The selected file should contain the new model and effort, while the base file should be unchanged.

Call relations: The test runner invokes it. ConfigBuilder creates a loaded config with loader overrides, and ConfigEditsBuilder::for_config uses that loaded config to choose the correct write target.

Call graph: calls 2 internal fn (without_managed_config_for_tests, without_managed_config_for_tests); 6 external calls (new, assert_eq!, for_config, read_to_string, write, from_str).

fn profile_v2_config_path_resolves_validated_names() -> anyhow::Result<()>

Purpose: Checks that a validated profile name maps to the expected profile config filename. For example, profile work should live in work.config.toml.

Data flow: It creates a temporary Codex home, parses work as a ProfileV2Name, and asks the resolver for the config path. The output should be the absolute path to work.config.toml inside the Codex home.

Call relations: The normal test runner calls this synchronous test. It directly exercises resolve_profile_v2_config_path after ProfileV2Name parsing has already accepted the name.

Call graph: 2 external calls (new, assert_eq!).

async fn set_model_overwrites_existing_model() -> anyhow::Result<()>

Purpose: Checks that changing the default model replaces existing default model fields without disturbing profile-specific model settings. Profiles are named sets of overrides.

Data flow: It writes a config with a default model, default reasoning effort, and a dev profile with its own model. It applies a new default model and high reasoning effort, then parses the file. The default values should change, while the dev profile model should remain gpt-4.1.

Call relations: The test runner invokes it. ConfigEditsBuilder updates the top-level defaults, and the final TOML parse verifies that nested profile data was left intact.

Call graph: calls 1 internal fn (new); 5 external calls (new, assert_eq!, read_to_string, write, from_str).

fn cwd_path(&self) -> PathBuf

Purpose: Returns the temporary current-working-directory path stored in a precedence test fixture. It is a small convenience helper for tests that need a normal PathBuf.

Data flow: It reads the fixture’s cwd temporary directory and converts its path into an owned PathBuf. Nothing else is changed.

Call relations: Other precedence-related tests can call this helper when they need to pass the fixture’s working directory into config loading or override code.

Call graph: 1 external calls (path).

fn codex_home(&self) -> AbsolutePathBuf

Purpose: Returns the fixture’s temporary Codex home as an absolute path. This helps tests avoid mistakes caused by relative paths.

Data flow: It reads the fixture’s codex_home temporary directory and converts it to an AbsolutePathBuf. The fixture itself is unchanged.

Call relations: Other precedence tests can call this helper when constructing config builders or loaders that require an absolute Codex home path.

Call graph: 1 external calls (abs).

async fn cli_override_sets_compact_prompt() -> std::io::Result<()>

Purpose: Checks that a command-line override can directly set the compact prompt. A compact prompt is the text used when summarizing or compressing context.

Data flow: It creates a temporary Codex home and a ConfigOverrides object containing compact_prompt text. It loads a config from default TOML plus the override. The resulting Config should expose the override text as its compact prompt.

Call relations: The test runner calls it. Config::load_from_base_config_with_overrides combines base config and overrides, and this test checks that the override wins.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, default).

async fn loads_compact_prompt_from_file() -> std::io::Result<()>

Purpose: Checks that Codex can read the compact prompt from a file path in the config. It also verifies surrounding whitespace is trimmed.

Data flow: It creates a workspace, writes a compact_prompt.txt file with padded text, and puts that file path in ConfigToml. It loads config with the workspace as the current directory. The resulting compact_prompt should be summarize differently without the extra spaces.

Call relations: The test runner invokes it. Config::load_from_base_config_with_overrides reads the configured file and turns its contents into the final compact prompt.

Call graph: 6 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, create_dir_all, write).

async fn load_config_uses_requirements_guardian_policy_config() -> std::io::Result<()>

Purpose: Checks that guardian policy text from managed requirements config is used. A guardian policy is instruction text for automatic safety or review behavior.

Data flow: It builds a config layer stack whose requirements layer contains policy text with extra spaces. It loads config with that layer stack. The resulting guardian_policy_config should contain the trimmed policy text.

Call relations: The test runner calls it. ConfigLayerStack carries the requirements data, and Config::load_config_with_layer_stack merges it into the final Config.

Call graph: calls 1 internal fn (new); 6 external calls (default, new, new, load_config_with_layer_stack, assert_eq!, default).

fn config_toml_deserializes_auto_review_policy()

Purpose: Checks that the [auto_review] policy field in TOML parses into ConfigToml. This protects the user-facing config syntax for review policy text.

Data flow: It parses a short TOML string containing an auto_review policy. It then looks inside the parsed ConfigToml and expects to find the same policy string.

Call relations: The test runner invokes this direct parsing test. It relies on TOML deserialization and does not load the full runtime Config.

Call graph: 1 external calls (assert_eq!).

async fn load_config_uses_auto_review_guardian_policy_config() -> std::io::Result<()>

Purpose: Checks that user config under auto_review.policy becomes the final guardian policy when no higher-priority requirements policy is present.

Data flow: It builds a ConfigToml with auto_review.policy containing padded text. It loads config with a temporary working directory. The final Config should contain the trimmed policy text.

Call relations: The test runner calls it. Config::load_from_base_config_with_overrides performs the config merge and trimming behavior being checked.

Call graph: 4 external calls (default, new, load_from_base_config_with_overrides, assert_eq!).

async fn requirements_guardian_policy_beats_auto_review() -> std::io::Result<()>

Purpose: Checks precedence when both managed requirements and user auto-review policy provide guardian policy text. The managed requirements policy should win.

Data flow: It creates a layer stack with a managed guardian policy and also creates user ConfigToml with a different auto_review policy. After loading config with both sources, the final guardian_policy_config should be the managed policy.

Call relations: The test runner invokes it. Config::load_config_with_layer_stack combines the user config and layer stack, and this test verifies the intended priority order.

Call graph: calls 1 internal fn (new); 5 external calls (default, new, new, load_config_with_layer_stack, assert_eq!).

async fn load_config_ignores_empty_auto_review_guardian_policy_config() -> std::io::Result<()>

Purpose: Checks that an auto_review policy containing only spaces is treated as missing. This prevents blank settings from becoming meaningful policy text.

Data flow: It loads a ConfigToml where auto_review.policy is just whitespace. The final Config should have no guardian_policy_config.

Call relations: The test runner calls it. Config::load_from_base_config_with_overrides is expected to trim and discard empty policy values.

Call graph: 4 external calls (default, new, load_from_base_config_with_overrides, assert_eq!).

async fn load_config_ignores_empty_requirements_guardian_policy_config() -> std::io::Result<()>

Purpose: Checks that a managed requirements guardian policy containing only spaces is ignored. Blank managed text should not override other behavior as if it were real policy.

Data flow: It creates a layer stack whose requirements policy is whitespace, then loads config. The final Config should have guardian_policy_config set to none.

Call relations: The test runner invokes it. Config::load_config_with_layer_stack receives the requirements layer and is expected to discard the empty value after trimming.

Call graph: calls 1 internal fn (new); 6 external calls (default, new, new, load_config_with_layer_stack, assert_eq!, default).

async fn load_config_rejects_missing_agent_role_config_file() -> std::io::Result<()>

Purpose: Checks that an agent role pointing to a missing config file is rejected with a clear error. Agent roles define specialized assistant personas or jobs, so broken file links should be caught early.

Data flow: It builds ConfigToml with an agents.researcher role whose config_file points to a file that does not exist. Loading the config should fail. The test checks that the error is InvalidInput and that the message names the bad field and says the file must exist.

Call relations: The test runner calls it. Config::load_from_base_config_with_overrides performs validation and returns the error that the test inspects.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default).

async fn agent_role_relative_config_file_resolves_against_config_toml() -> std::io::Result<()>

Purpose: Checks that a relative agent role config_file path in config.toml is resolved relative to that config file’s location. This makes ./agents/researcher.toml mean the expected nearby file.

Data flow: It creates an agents/researcher.toml file, writes a main config.toml that references it with a relative path, and loads config. The resulting researcher role should point to the full role file path and keep the nickname candidates from config.toml.

Call relations: The test runner invokes it. ConfigBuilder loads the user config from the temporary Codex home and performs relative-path resolution during build.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 4 external calls (new, assert_eq!, create_dir_all, write).

async fn agent_role_relative_config_file_resolves_from_config_layer() -> std::io::Result<()>

Purpose: Checks that relative agent role file paths also work when the role came from a config layer rather than directly from the base config. The path should still be based on the layer’s source file.

Data flow: It creates a role file and a config layer entry that acts as if it came from config.toml and references ./agents/researcher.toml. It loads config with the layer stack. The final researcher role should point to the actual role file path.

Call relations: The test runner calls it. ConfigLayerStack carries both the parsed layer and its source location, and Config::load_config_with_layer_stack uses that location to resolve the relative path.

Call graph: calls 1 internal fn (new); 10 external calls (default, new, load_config_with_layer_stack, assert_eq!, default, default, create_dir_all, write, from_str, vec!).

async fn agent_role_file_metadata_overrides_config_toml_metadata() -> std::io::Result<()>

Purpose: Checks that metadata inside an agent role file can override metadata from config.toml. This lets the role file be the main source of truth for its own description and nicknames.

Data flow: It writes a role file with description, nickname candidates, developer instructions, and model, while config.toml gives different description and nicknames plus the file path. After loading config, the role should use the file’s description and nickname list, while keeping the resolved config_file path.

Call relations: The test runner invokes it. ConfigBuilder loads the main config, reads the referenced role file, merges them, and the test verifies the file metadata wins.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 4 external calls (new, assert_eq!, create_dir_all, write).

async fn agent_role_file_without_developer_instructions_is_dropped_with_warning() -> std::io::Result<()>

Purpose: Checks that a discovered standalone agent role file is ignored if it lacks developer_instructions. Developer instructions are the core behavior guidance for an agent role, so a discovered role without them is incomplete.

Data flow: It creates a trusted fake repository with two standalone role files under .codex/agents: researcher without developer_instructions and reviewer with them. After loading config from inside the repo, researcher should be absent, reviewer should load, and startup warnings should mention the missing developer_instructions requirement.

Call relations: The test runner calls it. ConfigBuilder discovers standalone agent files based on the current workspace and trust settings, validates them, and records warnings for invalid ones.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 8 external calls (default, new, assert!, assert_eq!, format!, create_dir_all, create_dir_all, write).

async fn legacy_agent_role_config_file_allows_missing_developer_instructions() -> std::io::Result<()>

Purpose: Checks that older split agent-role configs referenced from config.toml may still omit developer_instructions. This preserves backward compatibility for legacy configurations.

Data flow: It writes a role config file containing model settings but no developer instructions, then references it from config.toml with a description. After loading config, the researcher role should still exist and point to the role file.

Call relations: The test runner invokes it. ConfigBuilder follows the legacy config_file reference and applies the older validation rules for roles declared through config.toml.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 4 external calls (new, assert_eq!, create_dir_all, write).

async fn agent_role_without_description_after_merge_is_dropped_with_warning() -> std::io::Result<()>

Purpose: Checks that an agent role is dropped if, after combining config.toml and its role file, it still has no description. A description is needed so users can understand what the role is for.

Data flow: It writes a researcher role file with developer instructions but no description, and config.toml references it without adding a description. A reviewer role in config.toml has a description. After loading, researcher should be absent, reviewer should remain, and warnings should mention that researcher needs a description.

Call relations: The test runner calls it. ConfigBuilder merges role metadata from config.toml and role files, then validates the merged result and stores startup warnings for invalid roles.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 5 external calls (new, assert!, assert_eq!, create_dir_all, write).

async fn discovered_agent_role_file_without_name_is_dropped_with_warning() -> std::io::Result<()>

Purpose: Checks that a discovered standalone agent role file must define a non-empty name. The name decides how the role is addressed in the final agent role map.

Data flow: It creates a trusted repository with two standalone role files: researcher lacks name, reviewer has name, description, and developer instructions. After loading config, researcher should be absent, reviewer should load, and startup warnings should mention the missing non-empty name.

Call relations: The test runner invokes it. ConfigBuilder discovers role files under .codex/agents, validates standalone file requirements, and reports invalid files through startup_warnings.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 8 external calls (default, new, assert!, assert_eq!, format!, create_dir_all, create_dir_all, write).

async fn agent_role_file_name_takes_precedence_over_config_key() -> std::io::Result<()>

Purpose: Checks that when a referenced role file declares its own name, that file-provided name is used instead of the key from config.toml. This lets a role file rename the role it defines.

Data flow: It writes a role file referenced under agents.researcher, but the file itself says name = archivist. After loading config, there should be no researcher role; instead, an archivist role should exist with file-provided metadata and the resolved config file path.

Call relations: The test runner calls it. ConfigBuilder reads the role file during the config build and lets the role file’s name control the final map key.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 4 external calls (new, assert_eq!, create_dir_all, write).

async fn loads_legacy_split_agent_roles_from_config_toml() -> std::io::Result<()>

Purpose: Checks that multiple legacy agent roles split across config.toml and separate role files still load correctly. This protects existing user setups with one file per role.

Data flow: It creates researcher and reviewer role files, then writes config.toml entries that describe each role, point to the files, and provide nickname candidates. After loading config, both roles should have the expected descriptions, resolved file paths, and nickname lists.

Call relations: The test runner invokes it. ConfigBuilder reads the main config, follows each legacy config_file reference, and assembles the final agent_roles map.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 4 external calls (new, assert_eq!, create_dir_all, write).

async fn discovers_multiple_standalone_agent_role_files() -> std::io::Result<()>

Purpose: Checks that Codex can discover several standalone agent role files across relevant .codex/agents folders in a trusted workspace. This lets projects ship role definitions near the code they apply to.

Data flow: It creates a fake trusted repository, then places role files at the repo root and in nested package-level .codex/agents folders. It loads config from a nested working directory. The final config should include researcher, reviewer, and writer roles with their descriptions and nickname candidates.

Call relations: The test runner calls it. ConfigBuilder uses the current workspace and project trust information to discover standalone role files, parse them, and add them to the final agent_roles map.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 6 external calls (default, new, assert_eq!, format!, create_dir_all, write).

async fn mixed_legacy_and_standalone_agent_role_sources_merge_with_precedence() -> std::io::Result<()>

Purpose: Checks that agent roles from older global config and newer standalone project files are merged correctly. It proves that a project-local agent file wins when it defines the same role, while roles found only in global config still remain available.

Data flow: It creates a fake Codex home, a fake Git project, global agent role entries, global agent files, and project-local agent files. Then it loads config from a nested working directory and inspects the final agent role map. The result should contain the project version of researcher, the global-only critic, and the project-only writer.

Call relations: The test runner calls this directly. Inside the test, setup is done with temporary directories and file writes, then ConfigBuilder::without_managed_config_for_tests builds the config so the assertions can verify the merge and precedence behavior.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 7 external calls (default, new, assert_eq!, format!, create_dir_all, create_dir_all, write).

async fn higher_precedence_agent_role_can_inherit_description_from_lower_layer() -> std::io::Result<()>

Purpose: Checks that a higher-priority project agent file can still reuse a description from a lower-priority global config entry when the project file does not provide one. This keeps users from having to repeat metadata in every layer.

Data flow: It writes a global role description and a project-local agent file with the same role name but no description. After loading config, the role should point to the project-local file, use the project nickname, and keep the global description.

Call relations: The test runner invokes it as an async config test. It uses ConfigBuilder::without_managed_config_for_tests to load the temporary setup and then checks the resolved role fields.

Call graph: calls 1 internal fn (without_managed_config_for_tests); 7 external calls (default, new, assert_eq!, format!, create_dir_all, create_dir_all, write).

async fn load_config_resolves_agent_interrupt_message() -> std::io::Result<()>

Purpose: Verifies that the agents.interrupt_message setting is read into the final runtime config. This matters because it controls whether agent interruption messages are enabled.

Data flow: It builds an in-memory config where interrupt_message is false. Loading turns that TOML-shaped input into a Config, and the final boolean should be false.

Call relations: The test runner calls this. It hands an in-memory ConfigToml to Config::load_from_base_config_with_overrides, then asserts the loaded field.

Call graph: 5 external calls (default, new, load_from_base_config_with_overrides, assert!, default).

async fn load_config_normalizes_agent_role_nickname_candidates() -> std::io::Result<()>

Purpose: Checks that agent nickname candidates are cleaned up by trimming extra spaces. This lets users write forgiving config while Codex stores tidy values.

Data flow: It passes nickname candidates like Hypatia and Noether into config loading. The loaded role should contain Hypatia and Noether without surrounding whitespace.

Call relations: The test runner calls it. It uses Config::load_from_base_config_with_overrides and then inspects the normalized agent role data.

Call graph: 7 external calls (from, default, new, load_from_base_config_with_overrides, assert_eq!, default, vec!).

async fn load_config_rejects_empty_agent_role_nickname_candidates() -> std::io::Result<()>

Purpose: Makes sure an explicitly empty nickname candidate list is treated as invalid. An empty list would look intentional but provide no usable names.

Data flow: It loads a config with nickname_candidates set to an empty list. Loading should fail with an invalid-input error that names the bad field.

Call relations: The test runner invokes it. The test expects Config::load_from_base_config_with_overrides to return an error instead of a usable config.

Call graph: 8 external calls (from, default, new, new, load_from_base_config_with_overrides, assert!, assert_eq!, default).

async fn load_config_rejects_duplicate_agent_role_nickname_candidates() -> std::io::Result<()>

Purpose: Checks that duplicate nickname candidates are rejected, even when spacing differs. This prevents ambiguous or repeated agent names.

Data flow: It provides Hypatia and Hypatia as candidates. Config loading trims them, sees they match, and returns an invalid-input error.

Call relations: The test runner calls it. It relies on the config loader's validation path and then checks the error kind and message.

Call graph: 8 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default, vec!).

async fn load_config_rejects_unsafe_agent_role_nickname_candidates() -> std::io::Result<()>

Purpose: Verifies that nickname candidates may only contain safe simple characters. This avoids nicknames with symbols that could confuse display, parsing, or prompts.

Data flow: It supplies a nickname containing angle brackets. Config loading rejects it and returns an invalid-input error explaining the allowed characters.

Call relations: The test runner invokes it. The test calls the normal config loader and confirms validation fails in the intended way.

Call graph: 8 external calls (from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default, vec!).

async fn model_catalog_json_loads_from_path() -> std::io::Result<()>

Purpose: Checks that Codex can load a custom model catalog from a JSON file path. This lets users or tests replace the built-in model list with a specific catalog.

Data flow: It writes a small valid catalog JSON file, points config at that file, and loads config. The final config should contain exactly that parsed catalog.

Call relations: The test runner calls it. It uses bundled_models_response to create valid sample data, writes it to disk, and asks Config::load_from_base_config_with_overrides to read it.

Call graph: 8 external calls (default, new, load_from_base_config_with_overrides, assert_eq!, bundled_models_response, default, to_string, write).

async fn model_catalog_json_rejects_empty_catalog() -> std::io::Result<()>

Purpose: Makes sure a custom model catalog cannot be empty. Codex needs at least one model entry to make model selection meaningful.

Data flow: It writes a JSON catalog with an empty models list and points config at it. Loading should fail with an invalid-data error mentioning that at least one model is required.

Call relations: The test runner invokes it. The test exercises the file-reading branch of config loading and checks that bad catalog data is rejected.

Call graph: 7 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default, write).

fn create_test_fixture() -> std::io::Result<PrecedenceTestFixture>

Purpose: Builds a reusable test setup with a sample config, a temporary working directory, and a temporary Codex home. Many later tests use it so they can focus on one setting instead of rebuilding the same base config.

Data flow: It parses a TOML string into ConfigToml, creates a fake current directory, marks it like a Git repo so parent folders are not searched, creates a fake Codex home, and returns all of that in a fixture object.

Call relations: This helper is called by several service-tier, telemetry, and legacy-profile tests. It hands them a known baseline config that they can modify before calling the real config loader.

Call graph: called by 13 (config_toml_legacy_fast_service_tier_uses_priority_request_value, config_toml_priority_service_tier_uses_priority_request_value, config_toml_service_tier_accepts_arbitrary_string, default_service_tier_override_uses_default_request_value, explicit_null_service_tier_override_maps_to_default_service_tier, fast_default_opt_out_notice_config_is_respected, legacy_fast_service_tier_override_uses_priority_request_value, legacy_profile_selection_is_rejected, load_config_applies_otel_trace_metadata, load_config_drops_invalid_otel_trace_metadata_entries (+3 more)); 3 external calls (new, write, from_str).

async fn legacy_profile_selection_is_rejected() -> std::io::Result<()>

Purpose: Checks that the old top-level profile = "..." setting is no longer accepted. This gives users a clear error instead of silently applying obsolete behavior.

Data flow: It starts from the shared fixture, sets the legacy profile field, and tries to load config. Loading should fail with an invalid-data error that explains the legacy setting is unsupported.

Call relations: The test runner calls it. It depends on create_test_fixture for setup and then verifies the config loader rejects the outdated field.

Call graph: calls 1 internal fn (create_test_fixture); 4 external calls (default, load_from_base_config_with_overrides, assert!, assert_eq!).

async fn metrics_exporter_defaults_to_statsig_when_missing() -> std::io::Result<()>

Purpose: Verifies the default metrics exporter when no explicit metrics exporter is configured. The expected default is Statsig, a telemetry backend.

Data flow: It loads the shared fixture config without changing telemetry metrics settings. The final config should set otel.metrics_exporter to Statsig.

Call relations: The test runner invokes it. It uses create_test_fixture, then sends the fixture through Config::load_from_base_config_with_overrides.

Call graph: calls 1 internal fn (create_test_fixture); 3 external calls (default, load_from_base_config_with_overrides, assert_eq!).

async fn trace_exporter_defaults_to_none_when_log_exporter_is_set() -> std::io::Result<()>

Purpose: Checks that setting a log exporter does not automatically enable trace exporting. This avoids sending traces unless they are explicitly configured.

Data flow: It adds an OpenTelemetry log exporter to the fixture config and sets metrics exporting to none. After loading, the log exporter remains configured and the trace exporter is None.

Call relations: The test runner calls this. It builds on create_test_fixture, then checks how the loader fills in related OpenTelemetry defaults.

Call graph: calls 1 internal fn (create_test_fixture); 5 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!).

async fn load_config_applies_otel_trace_metadata() -> std::io::Result<()>

Purpose: Verifies that configured OpenTelemetry trace metadata is loaded. OpenTelemetry is a standard way to record logs, metrics, and traces for observability.

Data flow: It parses TOML containing span attributes and tracestate entries. Loading config should copy those key-value pairs into the final telemetry config.

Call relations: The test runner invokes it. The test uses create_test_fixture for paths and then checks the output of the normal config loader.

Call graph: calls 1 internal fn (create_test_fixture); 4 external calls (default, load_from_base_config_with_overrides, assert_eq!, from_str).

async fn load_config_drops_invalid_otel_trace_metadata_entries() -> std::io::Result<()>

Purpose: Checks that invalid telemetry metadata entries are ignored with warnings rather than poisoning the whole config. Valid entries should still survive.

Data flow: It provides an empty span-attribute key and tracestate values with newlines, alongside valid entries. Loading keeps the valid metadata, drops invalid pieces, and records startup warnings.

Call relations: The test runner calls it. It exercises the config loader's validation and warning collection for OpenTelemetry metadata.

Call graph: calls 1 internal fn (create_test_fixture); 5 external calls (default, load_from_base_config_with_overrides, assert!, assert_eq!, from_str).

async fn explicit_null_service_tier_override_maps_to_default_service_tier() -> std::io::Result<()>

Purpose: Checks how an explicit null service-tier override is interpreted. It should mean the default request value, not an unknown or missing tier.

Data flow: It loads the fixture with an override shaped as Some(None). The final service_tier becomes the default request value and no fast-default opt-out notice is set.

Call relations: The test runner invokes it. It uses create_test_fixture and then sends a specific override into the config loader.

Call graph: calls 1 internal fn (create_test_fixture); 3 external calls (default, load_from_base_config_with_overrides, assert_eq!).

async fn default_service_tier_override_uses_default_request_value() -> std::io::Result<()>

Purpose: Verifies that an override string of default maps to the internal default service-tier request value. This keeps user-facing wording separate from the value sent downstream.

Data flow: It loads the fixture with service_tier override set to default. The resulting config stores the standard default request value.

Call relations: The test runner calls it. It relies on the shared fixture and config loader to test service-tier normalization.

Call graph: calls 1 internal fn (create_test_fixture); 3 external calls (default, load_from_base_config_with_overrides, assert_eq!).

async fn legacy_fast_service_tier_override_uses_priority_request_value() -> std::io::Result<()>

Purpose: Checks backward compatibility for the old fast service-tier override. Codex should translate it to the newer priority request value.

Data flow: It loads the fixture with an override value of fast. The final config should contain the request value for ServiceTier::Fast.

Call relations: The test runner invokes it. It uses create_test_fixture and checks the loader's service-tier migration behavior.

Call graph: calls 1 internal fn (create_test_fixture); 3 external calls (default, load_from_base_config_with_overrides, assert_eq!).

async fn config_toml_priority_service_tier_uses_priority_request_value() -> std::io::Result<()>

Purpose: Verifies that a priority service tier written in config TOML is preserved as the priority request value. This tests file-based configuration rather than an override.

Data flow: It modifies the fixture's TOML config to set the priority service tier. Loading returns a config with that same request value.

Call relations: The test runner calls it. It depends on create_test_fixture, then loads the edited fixture through the normal config path.

Call graph: calls 1 internal fn (create_test_fixture); 3 external calls (default, load_from_base_config_with_overrides, assert_eq!).

async fn config_toml_service_tier_accepts_arbitrary_string() -> std::io::Result<()>

Purpose: Checks that config TOML can contain an unknown service-tier string. This allows future or experimental tier IDs without requiring immediate code changes.

Data flow: It sets service_tier to experimental-tier-id in the fixture config. Loading preserves that exact string in the final config.

Call relations: The test runner invokes it. The test uses the shared fixture and confirms the loader does not over-restrict service-tier values.

Call graph: calls 1 internal fn (create_test_fixture); 3 external calls (default, load_from_base_config_with_overrides, assert_eq!).

async fn config_toml_legacy_fast_service_tier_uses_priority_request_value() -> std::io::Result<()>

Purpose: Checks that the old fast service tier is translated when it appears in the TOML config file. This protects users with older config files.

Data flow: It writes fast into the fixture config's service tier. Loading converts it to the modern priority request value.

Call relations: The test runner calls it. It uses create_test_fixture and checks the service-tier normalization inside config loading.

Call graph: calls 1 internal fn (create_test_fixture); 3 external calls (default, load_from_base_config_with_overrides, assert_eq!).

async fn fast_default_opt_out_notice_config_is_respected() -> std::io::Result<()>

Purpose: Verifies that the notice flag for opting out of a fast default is respected. This controls whether Codex records that notice state instead of choosing a service tier.

Data flow: It adds a notice config with fast_default_opt_out set to true. Loading leaves service_tier unset and stores the notice flag as true.

Call relations: The test runner invokes it. It starts with create_test_fixture, edits the notice section, and checks the loaded config.

Call graph: calls 1 internal fn (create_test_fixture); 3 external calls (default, load_from_base_config_with_overrides, assert_eq!).

async fn test_requirements_web_search_mode_allowlist_does_not_warn_when_unset() -> anyhow::Result<()>

Purpose: Checks that an enterprise web-search allowlist does not create a warning when the user has not configured a conflicting value. Requirements should guide defaults quietly when nothing needs correcting.

Data flow: It builds requirements allowing disabled or cached web search, with cached as the constrained value. Loading config with that layer stack should produce no startup warning about web_search_mode.

Call relations: The test runner calls it. It uses create_test_fixture, constructs a ConfigLayerStack, and hands that stack to Config::load_config_with_layer_stack.

Call graph: calls 4 internal fn (new, new, new, create_test_fixture); 5 external calls (default, new, load_config_with_layer_stack, assert!, vec!).

fn test_set_project_trusted_writes_explicit_tables() -> anyhow::Result<()>

Purpose: Checks that setting a project as trusted writes the project entry as an explicit TOML table. This keeps the saved config clear and structured.

Data flow: It starts with an empty TOML document, asks the helper to mark /some/path trusted, converts the document to text, and compares it with the expected table form.

Call relations: The test runner invokes it. The test directly exercises set_project_trust_level_inner, the lower-level writer used when Codex records project trust.

Call graph: 4 external calls (new, new, assert_eq!, format!).

fn test_set_project_trusted_converts_inline_to_explicit() -> anyhow::Result<()>

Purpose: Verifies that an old inline project entry is converted to an explicit table when trust is updated. This preserves meaning while moving the file toward the preferred layout.

Data flow: It starts with [projects] containing an inline entry marked untrusted. After updating, the output should contain an explicit per-project table marked trusted.

Call relations: The test runner calls it. It directly tests set_project_trust_level_inner against an older TOML shape.

Call graph: 3 external calls (new, assert_eq!, format!).

fn test_set_project_trusted_migrates_top_level_inline_projects_preserving_entries() -> anyhow::Result<()>

Purpose: Checks that a top-level inline projects = { ... } table can be migrated without losing existing project entries or extra fields. This protects users' existing config during automatic updates.

Data flow: It parses a TOML document with top-level settings and inline projects, then adds a new trusted project. The output should keep top-level settings, preserve old project fields, and append the new project table.

Call relations: The test runner invokes it. It uses project_trust_key for the expected key and exercises set_project_trust_level_inner migration behavior.

Call graph: calls 1 internal fn (project_trust_key); 3 external calls (new, assert_eq!, format!).

async fn active_project_does_not_match_configured_alias_for_canonical_cwd() -> anyhow::Result<()>

Purpose: Checks that a project configured through a symlink alias is not treated as matching the real canonical path. This avoids accidentally applying trust to a different path spelling.

Data flow: It creates a real project directory and a symlink alias, stores trust for the alias, then asks for the active project using the real path. The result should be no match.

Call relations: The test runner calls it on Unix-like systems where symlinks are available. It directly exercises ConfigToml::get_active_project.

Call graph: 6 external calls (default, from, assert_eq!, create_dir_all, symlink, tempdir).

fn test_set_default_oss_provider() -> std::io::Result<()>

Purpose: Tests writing and updating the default open-source model provider setting. It also verifies invalid provider names are rejected.

Data flow: It creates a temporary config file, writes ollama, updates to lmstudio while preserving another setting, overwrites back to ollama, and then tries an invalid provider. Valid writes change the file; the invalid write returns an invalid-input error.

Call relations: The test runner invokes it. It directly exercises set_default_oss_provider, which edits the user's config file.

Call graph: 5 external calls (new, assert!, assert_eq!, read_to_string, write).

fn test_set_default_oss_provider_rejects_legacy_ollama_chat_provider() -> std::io::Result<()>

Purpose: Checks that the removed legacy Ollama chat provider cannot be set as the default OSS provider. The error should point users toward the removal message.

Data flow: It calls the setter with the legacy provider ID. The function should return an invalid-input error containing the specific removal notice.

Call relations: The test runner calls it. It directly tests the validation branch in set_default_oss_provider.

Call graph: 3 external calls (new, assert!, assert_eq!).

async fn test_load_config_rejects_legacy_ollama_chat_provider_with_helpful_error() -> std::io::Result<()>

Purpose: Verifies that loading config with the removed Ollama chat provider fails with a helpful error. This protects users from confusing provider-not-found behavior.

Data flow: It builds a config whose model_provider is the legacy provider ID. Loading should fail with a not-found error that includes the removal message.

Call relations: The test runner invokes it. It tests the normal config loading path rather than the config-writing helper.

Call graph: 6 external calls (default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default).

async fn test_untrusted_project_gets_workspace_write_sandbox() -> anyhow::Result<()>

Purpose: Checks the legacy sandbox policy chosen for an untrusted project. On most platforms it should allow workspace writes; on Windows it may be downgraded to read-only.

Data flow: It creates config data marking a project untrusted and passes that active project into the sandbox derivation helper. The returned sandbox policy is checked against the platform-specific expectation.

Call relations: The test runner calls it. It exercises derive_legacy_sandbox_policy_for_test, a test helper around sandbox selection logic.

Call graph: calls 1 internal fn (derive_legacy_sandbox_policy_for_test); 2 external calls (assert!, cfg!).

async fn derive_sandbox_policy_falls_back_to_read_only_for_implicit_defaults() -> anyhow::Result<()>

Purpose: Verifies that when requirements only allow read-only access, implicit default sandbox choices fall back to read-only. This keeps organization rules stronger than default behavior.

Data flow: It sets up a trusted project and a constraint that accepts only the read-only permission profile. Sandbox derivation should return a read-only policy.

Call relations: The test runner invokes it. It uses Constrained::new to model requirements, then calls derive_legacy_sandbox_policy_for_test.

Call graph: calls 3 internal fn (new, derive_legacy_sandbox_policy_for_test, read_only); 4 external calls (default, from, new, assert_eq!).

async fn derive_sandbox_policy_preserves_windows_downgrade_for_unsupported_fallback() -> anyhow::Result<()>

Purpose: Checks that fallback sandbox behavior still respects Windows limitations. If workspace-write is required but unsupported on Windows, the result should be read-only there.

Data flow: It creates a trusted project and a constraint that allows a workspace-write-style profile. Sandbox derivation returns workspace-write on non-Windows platforms and read-only on Windows.

Call relations: The test runner calls it. It combines a permission constraint with derive_legacy_sandbox_policy_for_test and then checks platform-specific output.

Call graph: calls 3 internal fn (new, derive_legacy_sandbox_policy_for_test, workspace_write); 5 external calls (default, from, new, assert_eq!, cfg!).

fn test_resolve_oss_provider_explicit_override()

Purpose: Checks that an explicitly supplied OSS provider is returned when present. Direct user input should win over missing config.

Data flow: It passes custom-provider as the explicit provider and an otherwise default config. The resolver returns custom-provider.

Call relations: The test runner invokes it. It directly tests resolve_oss_provider with the simplest override case.

Call graph: 2 external calls (assert_eq!, default).

fn test_resolve_oss_provider_from_global_config()

Purpose: Checks that the OSS provider can come from global config when there is no explicit override. This supports persistent user defaults.

Data flow: It creates config with oss_provider set to global-provider and passes no explicit provider. The resolver returns the configured value.

Call relations: The test runner calls it. It directly exercises resolve_oss_provider for the global-config path.

Call graph: 2 external calls (default, assert_eq!).

fn test_resolve_oss_provider_none_when_not_configured()

Purpose: Verifies that no OSS provider is selected when neither an override nor a config value exists. This avoids inventing a provider unexpectedly.

Data flow: It passes no explicit provider and a default config. The resolver returns None.

Call relations: The test runner invokes it. It directly checks the empty-input branch of resolve_oss_provider.

Call graph: 2 external calls (assert_eq!, default).

fn test_resolve_oss_provider_explicit_overrides_global()

Purpose: Checks that an explicit OSS provider beats the global config value. This matches normal precedence rules: a direct request wins over a saved default.

Data flow: It creates config with global-provider but passes explicit-provider as the override. The resolver returns explicit-provider.

Call relations: The test runner calls it. It directly tests precedence inside resolve_oss_provider.

Call graph: 2 external calls (default, assert_eq!).

fn config_toml_deserializes_mcp_oauth_callback_port()

Purpose: Checks that the MCP OAuth callback port can be read from TOML. MCP is the Model Context Protocol, and OAuth callback settings support login flows.

Data flow: It parses TOML with mcp_oauth_callback_port = 4321. The resulting ConfigToml should store Some(4321).

Call relations: The test runner invokes it. It tests TOML deserialization before full config loading is involved.

Call graph: 2 external calls (assert_eq!, from_str).

fn config_toml_deserializes_mcp_oauth_callback_url()

Purpose: Checks that the MCP OAuth callback URL can be read from TOML. This lets config specify where OAuth login should return.

Data flow: It parses TOML with a callback URL string. The resulting ConfigToml should contain that URL.

Call relations: The test runner calls it. It directly tests TOML parsing for this field.

Call graph: 2 external calls (assert_eq!, from_str).

async fn config_loads_mcp_oauth_callback_port_from_toml() -> std::io::Result<()>

Purpose: Verifies that the MCP OAuth callback port survives full config loading, not just TOML parsing. This ensures runtime code can use the value.

Data flow: It parses TOML with a port, loads it into Config, and checks that the final config contains Some(5678).

Call relations: The test runner invokes it. It passes parsed ConfigToml into Config::load_from_base_config_with_overrides.

Call graph: 5 external calls (new, load_from_base_config_with_overrides, assert_eq!, default, from_str).