Plugins, extensions, skills, MCP, and tools tests

fn write_file(path: &Path, contents: &str)

Purpose: Writes text to a file for test setup, creating the parent folders first if they do not already exist. This lets tests describe files they need without separately building the directory tree.

Data flow: It receives a file path and the text to put there. It finds the file's parent folder, creates that folder and any missing folders above it, then writes the text into the file. The result is a real file on disk with the requested contents; if something goes wrong, the test stops immediately.

Call relations: The higher-level test helpers rely on this as their basic writing tool. write_curated_plugin, write_curated_marketplace, and write_curated_plugin_sha_with all call it when they need to place plugin metadata, marketplace manifests, or cache marker files on disk.

Call graph: called by 3 (write_curated_marketplace, write_curated_plugin, write_curated_plugin_sha_with); 3 external calls (parent, create_dir_all, write).

fn write_curated_plugin(root: &Path, plugin_name: &str)

Purpose: Creates a complete sample curated plugin folder for tests. The plugin includes a manifest, one skill, one MCP server entry, and one app connector entry so tests can verify all of those plugin features are discovered.

Data flow: It receives a root folder and a plugin name. From those, it builds a plugin directory under plugins/<plugin_name>, then writes several expected files inside it: .codex-plugin/plugin.json, skills/SKILL.md, .mcp.json, and .app.json. After it runs, the test directory looks like it contains an installed plugin with representative content.

Call relations: This function is called by write_curated_marketplace after the marketplace manifest has named the plugins. It uses write_file for each file it creates, so the lower-level folder creation and writing behavior stays in one place.

Call graph: calls 1 internal fn (write_file); called by 1 (write_curated_marketplace); 2 external calls (join, format!).

fn write_openai_curated_marketplace(root: &Path, plugin_names: &[&str])

Purpose: Creates a test version of the regular OpenAI curated marketplace. Tests use it when they need the standard marketplace name and file layout.

Data flow: It receives a root folder and a list of plugin names. It passes those values, along with the regular marketplace filename and marketplace name, into the shared marketplace-writing helper. The result is a marketplace manifest plus matching fake plugin folders.

Call relations: This is a convenience wrapper around write_curated_marketplace. It hides the exact manifest filename and marketplace name so tests can say what they mean at a higher level.

Call graph: calls 1 internal fn (write_curated_marketplace).

fn write_openai_api_curated_marketplace(root: &Path, plugin_names: &[&str])

Purpose: Creates a test version of the API curated marketplace. This is used for tests that need the API marketplace identity and its display name.

Data flow: It receives a root folder and a list of plugin names. It calls the shared marketplace writer with the API marketplace filename, API marketplace name, and display label OpenAI Curated. The result is a correctly shaped API marketplace manifest and fake plugin folders for each listed plugin.

Call relations: This wrapper feeds specific API-curated settings into write_curated_marketplace. Tests such as API fallback and cache refresh scenarios call it when they need that exact marketplace flavor.

Call graph: calls 1 internal fn (write_curated_marketplace); called by 2 (returns_api_curated_fallback_plugins_for_direct_provider_auth, refresh_curated_plugin_cache_reinstalls_missing_api_curated_plugin).

fn write_curated_marketplace(
    root: &Path,
    manifest_name: &str,
    marketplace_name: &str,
    display_name: Option<&str>,
    plugin_names: &[&str],
)

Purpose: Writes a curated marketplace manifest and creates all plugins named in it. A marketplace manifest is the file that tells the plugin system which plugins exist and where to find them.

Data flow: It receives a root folder, manifest filename, marketplace name, optional display name, and a list of plugin names. It turns the plugin list into JSON entries pointing to local plugin folders, optionally adds an interface display name, writes the manifest under .agents/plugins, and then creates each matching plugin folder. Afterward, tests have both the catalog and the plugin contents it refers to.

Call relations: The two public marketplace helpers, write_openai_curated_marketplace and write_openai_api_curated_marketplace, call this shared function with different marketplace identities. It calls write_file to place the manifest and write_curated_plugin to create each listed plugin, keeping the manifest and filesystem in sync.

Call graph: calls 2 internal fn (write_curated_plugin, write_file); called by 2 (write_openai_api_curated_marketplace, write_openai_curated_marketplace); 2 external calls (join, format!).

fn write_curated_plugin_sha_with(codex_home: &Path, sha: &str)

Purpose: Writes a fake curated-plugin SHA marker into the test Codex home. A SHA is a checksum-like identifier often used to say which version of cached content is present.

Data flow: It receives a Codex home folder and a SHA string. It writes that string, followed by a newline, to .tmp/plugins.sha inside the Codex home. The visible result is a cache marker file that tests can use to simulate a known plugin cache version.

Call relations: This helper uses write_file for the actual disk write. Tests can call it when they need the plugin cache to appear up to date, stale, or otherwise tied to a specific recorded SHA.

Call graph: calls 1 internal fn (write_file); 2 external calls (join, format!).

async fn load_plugins_config(codex_home: &Path, cwd: &Path) -> PluginsConfigInput

Purpose: Loads plugin configuration for tests using the real configuration loader, but with test-safe overrides. It produces the PluginsConfigInput object that plugin code expects.

Data flow: It receives a Codex home path and a current working directory path. It first converts both to absolute paths, then asks the config loader to read the configuration layers from the local filesystem while disabling managed config for tests. From the effective combined config, it reads feature flags for plugins and remote_plugin, applies defaults when those flags are missing, and builds a PluginsConfigInput with a fixed backend API URL. The output is a ready-to-use plugin configuration for test code.

Call relations: This function sits between raw test folders and the plugin code under test. It calls the normal load_config_layers_state path so tests stay close to production behavior, uses feature_enabled to interpret feature switches, and then hands the resulting values into PluginsConfigInput::new.

Call graph: calls 5 internal fn (load_config_layers_state, without_managed_config_for_tests, new, feature_enabled, try_from); 1 external calls (as_path).

fn feature_enabled(config: &Value, key: &str, default_enabled: bool) -> bool

Purpose: Reads one boolean feature flag from a TOML configuration value. If the flag is missing or not written as a true/false value, it falls back to a caller-provided default.

Data flow: It receives the full config value, the feature name to look for, and a default boolean. It looks under the features table, checks the requested key, and accepts it only if it is a boolean. It returns either the found boolean or the default value.

Call relations: This is a small helper used by load_plugins_config when building test plugin configuration. It keeps the feature-flag reading rules in one place so load_plugins_config can focus on assembling the final plugin config object.

Call graph: called by 1 (load_plugins_config); 1 external calls (get).

fn absolute(path: impl AsRef<std::path::Path>) -> AbsolutePathBuf

Purpose: This small test helper turns a path into an AbsolutePathBuf, which is this project’s type for paths that must be absolute rather than relative. It keeps the tests concise and makes failures clear if a supposedly absolute test path is not actually absolute.

Data flow: It receives something path-like, reads it as a standard path, and passes it to the checked absolute-path constructor. If the path is valid and absolute, it returns an AbsolutePathBuf; if not, the test stops with the message absolute test path.

Call relations: Both test cases call this helper while building their fake plugin folders and resource paths. It hands clean absolute paths to ResolvedPlugin::from_environment, so the tests focus on plugin resolution behavior rather than path conversion details.

Call graph: calls 1 internal fn (from_absolute_path_checked); called by 2 (environment_descriptor_binds_every_manifest_resource, environment_descriptor_rejects_resources_outside_package_root); 1 external calls (as_ref).

fn resource(environment_id: &str, path: AbsolutePathBuf) -> PluginResourceLocator

Purpose: This helper builds the expected form of a resolved plugin resource: a path labeled with the environment id it belongs to. It makes the test expectations easier to read.

Data flow: It receives an environment id as text and an absolute path. It copies the environment id into an owned string, pairs it with the path, and returns a PluginResourceLocator::Environment value.

Call relations: The main binding test uses this helper when writing the expected resolved manifest. It mirrors what ResolvedPlugin::from_environment is supposed to produce for every manifest resource.

fn environment_descriptor_binds_every_manifest_resource()

Purpose: This test proves that every resource path listed in a plugin manifest gets tied to the environment that provides it. Without this, later code might know a file path but not know which execution environment should be used to access it.

Data flow: It starts by creating absolute paths for a fake plugin root, manifest file, skills folder, server config, app config, hooks file, and interface images. It puts those paths into a PluginManifest, then calls ResolvedPlugin::from_environment with a selected plugin id, an executor environment id, the root path, the manifest path, and the manifest. The result is compared with the expected plugin: the manifest path and every resource inside the manifest should now be wrapped as environment resources using executor-1.

Call relations: During the test, absolute prepares the paths and resource builds the expected environment-labeled resources. The test then relies on ResolvedPlugin::from_environment to do the real resolving work, and uses equality assertions to confirm that the resolver touched every relevant manifest field, including nested hook and interface paths.

Call graph: calls 3 internal fn (default, from_environment, absolute); 5 external calls (new, assert_eq!, Paths, current_dir, vec!).

fn environment_descriptor_rejects_resources_outside_package_root()

Purpose: This test proves that a plugin manifest is not allowed to point at resources outside its own plugin folder. That protects the system from plugins accidentally or deliberately reaching into unrelated parts of the filesystem.

Data flow: It gets the current working directory, builds one absolute path for the plugin root, and another absolute path for a resource outside that root. It creates a manifest whose MCP server config points to the outside file. Then it calls ResolvedPlugin::from_environment and expects failure. The final assertion checks that the returned error is exactly ResourceOutsideRoot, carrying the plugin root and the rejected outside path.

Call relations: This test uses absolute to prepare the root and outside paths, then asks ResolvedPlugin::from_environment to validate the manifest. Instead of checking a resolved plugin, it checks the error path, making sure the resolver stops as soon as it finds a resource that escapes the plugin package boundary.

Call graph: calls 2 internal fn (from_environment, absolute); 3 external calls (new, assert_eq!, current_dir).

fn unsupported() -> FileSystemResult<T>

Purpose: Returns a standard “unsupported operation” error for fake file-system actions that these tests do not expect plugin resolution to use. It keeps the fake file system small and makes any unexpected operation fail clearly.

Data flow: It takes no meaningful input. It creates an input/output error marked as unsupported, with a message explaining that the operation is not used by plugin resolution, and returns that error instead of a value.

Call relations: The fake file-system methods that are outside the test’s focus hand off to this helper. If plugin resolution ever calls one of those unused methods, the test will receive this clear failure rather than silently doing something misleading.

Call graph: 1 external calls (new).

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

Purpose: Rejects path canonicalization in the fake file system. Canonicalization means turning a path into its official cleaned-up form, but these tests do not need that behavior.

Data flow: It receives a path and optional sandbox context, ignores them, and returns an asynchronous failure from SyntheticPluginFileSystem::unsupported. Nothing is recorded or changed.

Call relations: This is part of the executor file-system interface that the fake must implement. It exists so the fake can be passed anywhere an executor file system is required, while still proving that plugin resolution does not rely on this operation in the tested path.

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

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

Purpose: Pretends to read a file from the executor file system, but only succeeds for the plugin manifest. It also records the read so the test can verify exactly what plugin resolution looked at.

Data flow: It receives a path, converts it to an absolute path, and stores a Read record in the fake file system’s shared call log. If the path is the expected manifest path, it returns the manifest text as bytes; otherwise it returns a “not found” error.

Call relations: When resolve_plugin_root is tested with this fake file system, this method is the only way the resolver can obtain manifest contents. Its call log is later checked by plugin_root_resolution_uses_supplied_executor_file_system to confirm the resolver read the executor manifest and nothing else.

Call graph: calls 1 internal fn (to_abs_path); 4 external calls (pin, new, Read, clone).

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

Purpose: Rejects streaming file reads in the fake file system. Streaming means reading a file in chunks, which plugin resolution does not need in these tests.

Data flow: It receives a path and optional sandbox context, ignores them, and returns an asynchronous unsupported-operation error. It does not alter the fake file system’s call log.

Call relations: This fills out the executor file-system interface. If the resolver unexpectedly tried to stream the manifest instead of reading it normally, this method would make the test fail clearly.

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

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

Purpose: Rejects file writes in the fake file system. Plugin resolution should only inspect plugin files, not modify them.

Data flow: It receives a path, file contents, and optional sandbox context, ignores all of them, and returns an asynchronous unsupported-operation error. No files are written and no state changes.

Call relations: This method is present because the fake implements the full executor file-system interface. Its failure protects the test from accidentally allowing plugin resolution to write during what should be a read-only lookup.

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

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

Purpose: Rejects directory creation in the fake file system. Looking up a plugin should not create folders.

Data flow: It receives a path, directory-creation options, and optional sandbox context, ignores them, and returns an asynchronous unsupported-operation error. The fake file system remains unchanged.

Call relations: This unused interface method acts as a guardrail. If plugin resolution ever tried to prepare or repair plugin folders during these tests, this method would expose that unexpected behavior.

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

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

Purpose: Answers the question “does this path exist, and is it a file or folder?” for the fake plugin root and manifest. It records each check so the test can confirm the resolver’s exact sequence of file-system questions.

Data flow: It receives a path, converts it to an absolute path, and appends a Metadata record to the shared call log. If the path is the plugin root, it returns metadata saying it is a directory; if it is the manifest path, it returns metadata saying it is a file; any other path produces a “not found” error.

Call relations: Plugin resolution uses metadata checks before reading the manifest. plugin_root_resolution_uses_supplied_executor_file_system later checks these recorded calls to prove the resolver first recognized the root as a directory, then recognized the manifest as a file, then read it.

Call graph: calls 1 internal fn (to_abs_path); 4 external calls (pin, new, Metadata, clone).

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

Purpose: Rejects directory listing in the fake file system. These tests expect plugin resolution to check known manifest paths, not scan whole folders.

Data flow: It receives a path and optional sandbox context, ignores them, and returns an asynchronous unsupported-operation error. It does not return any directory entries.

Call relations: This method is part of the executor file-system interface. If the resolver changed to discover plugins by listing directories, this fake would fail and draw attention to that changed behavior.

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

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

Purpose: Rejects file or directory removal in the fake file system. Resolving a plugin should never delete anything.

Data flow: It receives a path, removal options, and optional sandbox context, ignores them, and returns an asynchronous unsupported-operation error. No fake or real files are removed.

Call relations: This is a safety-oriented part of the fake interface. It ensures a lookup-only test cannot accidentally permit destructive behavior.

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

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

Purpose: Rejects file copying in the fake file system. Plugin resolution should read metadata and manifest contents, not duplicate files.

Data flow: It receives source and destination paths, copy options, and optional sandbox context, ignores them, and returns an asynchronous unsupported-operation error. No data is copied.

Call relations: This completes the executor file-system interface for the fake. If plugin resolution ever attempted copying as part of lookup, the test would fail immediately through this method.

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

fn write_manifest(plugin_root: &Path, relative_path: &str, contents: &str)

Purpose: Creates a plugin manifest file on the real temporary test disk. Tests use it when they need realistic local files to exist.

Data flow: It receives a plugin root folder, a relative manifest path, and the manifest text. It joins the root and relative path, creates any missing parent directories, then writes the contents to that manifest file. Its output is the side effect of a file existing on disk.

Call relations: The tests for missing environments and malformed preferred manifests call this helper to set up their temporary folders. It keeps setup short so each test can focus on the behavior it is checking.

Call graph: called by 2 (malformed_preferred_manifest_does_not_fall_through_to_alternate, unavailable_environment_does_not_fall_back_to_host_filesystem); 3 external calls (join, create_dir_all, write).

fn selected_root(id: &str, environment_id: &str, path: &Path) -> SelectedCapabilityRoot

Purpose: Builds a SelectedCapabilityRoot, which is the test object saying “this chosen root lives in this environment at this path.” It avoids repeating the same setup code in every test.

Data flow: It receives a root id, an environment id, and a file-system path. It turns the path into text and returns a selected root whose location points to that environment path.

Call relations: Most tests call this helper before asking the plugin provider or resolver to resolve a root. It supplies the common input shape needed by plugin resolution while letting each test vary only the id, environment, or path.

Call graph: called by 4 (malformed_preferred_manifest_does_not_fall_through_to_alternate, plugin_root_resolution_uses_supplied_executor_file_system, standalone_capability_root_is_not_a_plugin, unavailable_environment_does_not_fall_back_to_host_filesystem); 1 external calls (to_string_lossy).

async fn plugin_root_resolution_uses_supplied_executor_file_system()

Purpose: Tests that plugin resolution uses the provided executor file system instead of the host disk. This is important for plugins that exist only inside an execution environment.

Data flow: It creates a temporary path but deliberately does not create that plugin folder on the real disk. It builds a fake executor file system that says the folder and manifest exist, parses the expected manifest for comparison, then calls plugin root resolution. The test expects a resolved plugin and expects the fake file system’s call log to show a metadata check on the root, a metadata check on the manifest, and a read of the manifest.

Call relations: This test calls selected_root to describe the environment root, then sends that and the fake file system into resolve_plugin_root. The fake’s get_metadata and read_file methods provide the only successful file-system answers, and the final assertions prove those methods were used in the intended order.

Call graph: calls 3 internal fn (parse_plugin_manifest, selected_root, from_absolute_path_checked); 6 external calls (new, new, assert!, assert_eq!, resolve_plugin_root, tempdir).

async fn standalone_capability_root_is_not_a_plugin()

Purpose: Tests that an ordinary folder is not mistaken for a plugin. A folder should only become a plugin root when the expected plugin manifest is present.

Data flow: It creates a temporary standalone folder on disk, creates a plugin provider with the default test environment manager, and asks the provider to resolve that folder. The expected result is None, meaning “this is not a plugin,” rather than an error or a fake plugin description.

Call relations: The test builds its selected root with selected_root and calls ExecutorPluginProvider::resolve. It checks the provider’s normal local test environment path, making sure the broader provider flow correctly distinguishes standalone capability roots from plugin roots.

Call graph: calls 3 internal fn (new, selected_root, default_for_tests); 4 external calls (new, assert_eq!, create_dir_all, tempdir).

async fn unavailable_environment_does_not_fall_back_to_host_filesystem()

Purpose: Tests that a selected root pointing at a missing environment fails, even if the same path exists on the host machine. This prevents accidental leakage from the local computer into an environment-specific lookup.

Data flow: It creates a real temporary plugin manifest on the host disk, then creates a provider whose environment manager has no available environments. When it asks the provider to resolve the selected root in a missing environment, the result must be an error saying that environment is unavailable.

Call relations: This test uses write_manifest to make a tempting host-side plugin and selected_root to point at it through a nonexistent environment. It then calls the provider’s resolve path and confirms the provider stops at the environment check instead of reading the host file system.

Call graph: calls 4 internal fn (new, selected_root, write_manifest, without_environments); 3 external calls (new, assert_eq!, tempdir).

async fn malformed_preferred_manifest_does_not_fall_through_to_alternate()

Purpose: Tests that a broken manifest in the preferred location causes a parse error instead of being ignored in favor of an alternate manifest. This keeps configuration mistakes visible.

Data flow: It creates a plugin folder with two manifests: the preferred .codex-plugin/plugin.json contains invalid JSON, while the alternate .claude-plugin/plugin.json is valid. It asks the provider to resolve the root and expects a parse-manifest error tied to the preferred manifest path. The successful alternate file is intentionally not used.

Call relations: The test uses write_manifest twice to set up the competing files and selected_root to feed the root into ExecutorPluginProvider::resolve. After resolution fails, it inspects the specific error shape to make sure the failure came from parsing the preferred manifest.

Call graph: calls 5 internal fn (new, selected_root, write_manifest, default_for_tests, from_absolute_path_checked); 4 external calls (new, assert_eq!, panic!, tempdir).

async fn executor_root_must_be_an_explicit_absolute_path()

Purpose: Tests that executor plugin roots must use absolute paths, not shortcuts such as ~/plugins/demo. This avoids unclear path interpretation inside execution environments.

Data flow: It creates a selected root by hand with an environment location whose path starts with ~. It asks the provider to resolve it and expects an error explaining that executor paths must be absolute.

Call relations: Unlike the other tests, this one constructs the selected root directly so it can use an intentionally invalid path string. It then calls the provider’s resolve path and verifies that validation rejects the path before any plugin lookup proceeds.

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

fn write_plugin_with_version(
    root: &Path,
    dir_name: &str,
    manifest_name: &str,
    manifest_version: Option<&str>,
)

Purpose: Creates a tiny fake plugin on disk for tests, optionally including a version in its manifest. This lets each test build just enough plugin structure to exercise the store without needing real plugin packages.

Data flow: It receives a root folder, a directory name, a manifest plugin name, and an optional version string. It creates the plugin directory, writes a .codex-plugin/plugin.json file with the chosen name and optional version, writes a sample skill file, and writes an empty MCP configuration file. Nothing is returned; the result is a ready-to-install fake plugin folder on disk.

Call relations: Tests that need a specific manifest version call this helper directly. The simpler write_plugin helper also calls it when tests need the same fake plugin but with no version field.

Call graph: called by 4 (install_rejects_blank_manifest_version, install_uses_manifest_version_when_present, install_with_new_version_keeps_existing_plugin_root_and_prunes_old_versions, write_plugin); 4 external calls (join, format!, create_dir_all, write).

fn write_plugin(root: &Path, dir_name: &str, manifest_name: &str)

Purpose: Creates a tiny fake plugin with no explicit version in its manifest. Tests use it when they want the store to fall back to the default local version.

Data flow: It receives a root folder, a directory name, and a manifest plugin name. It passes those values to write_plugin_with_version with no version value, which creates the files and folders. It returns nothing; it leaves a minimal plugin directory behind.

Call relations: Most install and version-selection tests call this helper before asking PluginStore to inspect or install the fake plugin. It is a convenience wrapper around write_plugin_with_version.

Call graph: calls 1 internal fn (write_plugin_with_version); called by 9 (active_plugin_version_compares_semver_versions_semantically, active_plugin_version_prefers_default_local_version_when_multiple_versions_exist, active_plugin_version_reads_version_directory_name, active_plugin_version_returns_latest_version_when_default_is_missing, install_copies_plugin_into_default_marketplace, install_rejects_manifest_names_that_do_not_match_marketplace_plugin_name, install_rejects_manifest_names_with_path_separators, install_uses_manifest_name_for_destination_and_key, install_with_version_uses_requested_cache_version).

fn try_new_rejects_relative_codex_home()

Purpose: Checks that the plugin store refuses to start from a relative Codex home path. This protects later path calculations from being ambiguous or dependent on the current working directory.

Data flow: It gives PluginStore::try_new a relative path named relative. The store creation is expected to fail, and the test turns the error into text. The output is an assertion that the error message clearly says the plugin cache root could not be resolved because the path was not absolute.

Call relations: This test calls the fallible constructor directly, before any plugin installation happens. It verifies an early setup guard that other store operations rely on.

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

fn install_copies_plugin_into_default_marketplace()

Purpose: Checks the basic install path: a valid plugin is copied into the plugin cache under its marketplace, plugin name, and default local version. It also checks that important plugin files are actually copied.

Data flow: It creates a temporary folder, writes a fake plugin named sample-plugin, and builds a PluginId for the debug marketplace. It then installs the source folder through PluginStore. The result should name the same plugin, report version local, point to plugins/cache/debug/sample-plugin/local, and that destination should contain the manifest and skill file.

Call relations: This is a direct exercise of PluginStore::install using a plugin created by write_plugin. It confirms the core behavior that many later tests vary or constrain.

Call graph: calls 4 internal fn (new, write_plugin, new, try_from); 3 external calls (assert!, assert_eq!, tempdir).

fn install_uses_manifest_name_for_destination_and_key()

Purpose: Checks that installation follows the plugin name inside plugin.json, not just the source folder name. This matters because a downloaded or unpacked directory may have a temporary name, while the manifest is the plugin’s identity.

Data flow: It creates a source folder called source-dir whose manifest says manifest-name. It installs that folder with a PluginId for manifest-name in the market marketplace. The expected result points to plugins/cache/market/manifest-name/local and keeps the PluginId for manifest-name.

Call relations: This test uses write_plugin to create a mismatch between folder name and manifest name, then calls PluginStore::install to prove the manifest name is what determines the installed location.

Call graph: calls 4 internal fn (new, write_plugin, new, try_from); 2 external calls (assert_eq!, tempdir).

fn plugin_root_derives_path_from_key_and_version()

Purpose: Checks that PluginStore can compute the installed root folder for a given plugin and version. This is the path other code will use when it needs to load an installed plugin.

Data flow: It creates a store rooted at a temporary directory and a PluginId for sample in the debug marketplace. It asks for the plugin root for version local. The returned path should be plugins/cache/debug/sample/local inside the temporary Codex home.

Call relations: This test calls PluginStore::plugin_root directly. It verifies the path-building rule that install and lookup operations depend on.

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

fn plugin_data_root_derives_path_from_key()

Purpose: Checks where per-plugin data should live. Plugin data is separate from the plugin’s installed code so that cache versions can change without losing runtime data.

Data flow: It creates a store and a PluginId for sample in the debug marketplace. It asks for the plugin data root. The expected path is plugins/data/sample-debug inside the temporary Codex home.

Call relations: This test calls PluginStore::plugin_data_root directly. It documents and protects the naming convention used for plugin-specific data directories.

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

fn install_with_version_uses_requested_cache_version()

Purpose: Checks that callers can force a specific cache version during installation. This is useful for marketplace downloads where the desired version may come from an external package hash or release identifier.

Data flow: It writes a fake plugin with no manifest version, creates a PluginId for the openai-curated marketplace, and chooses a version string. It installs through install_with_version. The result should report that exact version and copy the plugin into plugins/cache/openai-curated/sample-plugin/<that version>.

Call relations: This test uses write_plugin, then calls the explicit-version install path instead of the default install path. It confirms that install_with_version overrides the usual local fallback.

Call graph: calls 4 internal fn (new, write_plugin, new, try_from); 4 external calls (assert!, assert_eq!, format!, tempdir).

fn install_uses_manifest_version_when_present()

Purpose: Checks that a version written in plugin.json becomes the installed cache version. This lets plugins declare their own release version instead of always being installed as local.

Data flow: It creates a fake plugin whose manifest version is 1.2.3-beta+7, then installs it. The install result should report that same version, and the copied plugin should live under plugins/cache/debug/sample-plugin/1.2.3-beta+7.

Call relations: This test calls write_plugin_with_version to prepare a versioned plugin, then calls PluginStore::install. It proves the normal install path reads and honors the manifest version.

Call graph: calls 4 internal fn (new, write_plugin_with_version, new, try_from); 3 external calls (assert!, assert_eq!, tempdir).

fn install_rejects_blank_manifest_version()

Purpose: Checks that a manifest version made only of spaces is not accepted. A blank version would create unclear cache paths and make version selection unreliable.

Data flow: It creates a fake plugin whose version field is whitespace. It tries to install it and expects an error instead of a copied plugin. The final assertion checks that the error says the plugin version in plugin.json must not be blank.

Call relations: This test uses write_plugin_with_version to create an invalid manifest, then calls PluginStore::install to verify that validation stops the install early.

Call graph: calls 4 internal fn (new, write_plugin_with_version, new, try_from); 2 external calls (assert_eq!, tempdir).

fn active_plugin_version_reads_version_directory_name()

Purpose: Checks that the store can discover the active installed version by looking at the version directory name. This is how the store finds an already-installed plugin.

Data flow: It manually creates a fake installed plugin under plugins/cache/debug/sample-plugin/local. It then creates a store and asks for the active version and active root. The answers should be local and the matching local directory.

Call relations: This test uses write_plugin to create a cache-shaped directory by hand, then calls active_plugin_version and active_plugin_root. It verifies lookup behavior without going through install.

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

fn active_plugin_version_prefers_default_local_version_when_multiple_versions_exist()

Purpose: Checks that local is chosen when both local and another version exist. This supports local development or manually installed plugins taking priority over cached release versions.

Data flow: It creates two installed-looking versions of the same plugin: one named with a hash-like version and one named local. It asks the store for the active version. The expected answer is local.

Call relations: This test builds the cache layout with write_plugin and then calls active_plugin_version. It exercises the priority rule used when several installed versions are present.

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

fn active_plugin_version_returns_latest_version_when_default_is_missing()

Purpose: Checks that, when local is not present, the store chooses the newest available version directory. This keeps the plugin active on the most recent cached release.

Data flow: It creates two non-local version directories for the same plugin. It asks for the active version. The expected answer is the later version name, fedcba9876543210.

Call relations: This test prepares multiple cached versions with write_plugin and then calls active_plugin_version. It covers the fallback path after the local-priority rule does not apply.

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

fn active_plugin_version_compares_semver_versions_semantically()

Purpose: Checks that standard release versions are compared by meaning, not just alphabetically. Without this, 9.0.0 could incorrectly sort after 10.0.0 because text sorting can be misleading.

Data flow: It creates installed versions named 9.0.0 and 10.0.0. It asks the store for the active version. The result should be 10.0.0, proving the comparison understands semantic versions, which are dotted release numbers like major.minor.patch.

Call relations: This test uses write_plugin to create version directories and then calls active_plugin_version. It protects the version-ranking logic used when local is absent.

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

fn install_with_new_version_keeps_existing_plugin_root_and_prunes_old_versions()

Purpose: Checks that installing a newer version replaces older cached versions of the same plugin. This avoids stale versions staying active or piling up on disk.

Data flow: It creates a store and installs version 1.0.0 of sample-plugin. Then it creates and installs version 2.0.0 of the same plugin. Afterward, the active version should be 2.0.0, the 2.0.0 directory should exist, and the old 1.0.0 directory should be gone.

Call relations: This test calls write_plugin_with_version twice and installs both fake plugins through PluginStore::install. It ties together version detection, install location, active-version choice, and cleanup of old versions.

Call graph: calls 4 internal fn (new, write_plugin_with_version, new, try_from); 3 external calls (assert!, assert_eq!, tempdir).

fn old_plugin_version_would_stay_active_for_local_or_later_versions()

Purpose: Checks the helper rule that decides whether an old version would still win over a newly installed version. This rule helps the store know when replacing or pruning is needed.

Data flow: It feeds pairs of old and new version names into old_plugin_version_would_stay_active. The assertions expect true when the old version is local or newer than the new one, and false when the new version is newer.

Call relations: This test calls the version-comparison helper directly. It supports the cleanup behavior tested more fully by install_with_new_version_keeps_existing_plugin_root_and_prunes_old_versions.

Call graph: 1 external calls (assert!).

fn plugin_root_rejects_path_separators_in_key_segments()

Purpose: Checks that plugin identifiers cannot contain path traversal text such as ../../etc. This is a security guard: plugin names and marketplace names must not be able to escape the cache directory.

Data flow: It tries to parse one PluginId with a dangerous plugin name and another with a dangerous marketplace name. Both should fail, and each error message should explain which part of the identifier is invalid and what characters are allowed.

Call relations: This test calls PluginId::parse before any store path is built. It verifies that unsafe identifiers are rejected at the identifier layer, which protects later path-building code.

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

fn install_rejects_manifest_names_with_path_separators()

Purpose: Checks that unsafe plugin names inside plugin.json are rejected during installation. Even if the requested PluginId is safe, the manifest itself must not be able to choose a dangerous destination path.

Data flow: It creates a fake plugin whose manifest name is ../../etc. It tries to install that plugin with a safe PluginId. The install should fail, and the error should say the plugin name may only contain allowed characters.

Call relations: This test uses write_plugin to create a malicious manifest, then calls PluginStore::install. It verifies that manifest validation happens before copying into the cache.

Call graph: calls 4 internal fn (new, write_plugin, new, try_from); 2 external calls (assert_eq!, tempdir).

fn install_rejects_marketplace_names_with_path_separators()

Purpose: Checks that marketplace names are validated when a PluginId is created. A marketplace name becomes part of a filesystem path, so it must not contain path separators.

Data flow: It tries to create a PluginId with plugin name sample-plugin and marketplace name ../../etc. The creation should fail, and the error should explain that only safe characters are allowed in marketplace names.

Call relations: This test calls PluginId::new directly. It confirms unsafe marketplace input is stopped before PluginStore ever receives it.

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

fn install_rejects_manifest_names_that_do_not_match_marketplace_plugin_name()

Purpose: Checks that the plugin name in plugin.json must match the plugin name requested by the marketplace identifier. This prevents accidentally or deliberately installing one plugin under another plugin’s identity.

Data flow: It creates a source folder whose manifest says manifest-name, then tries to install it using a PluginId whose plugin name is different-name. The install should fail with an error that names both the manifest value and the expected marketplace value.

Call relations: This test uses write_plugin to create the mismatch and then calls PluginStore::install. It verifies the identity check that sits between reading the manifest and copying the plugin into the cache.

Call graph: calls 4 internal fn (new, write_plugin, new, try_from); 2 external calls (assert_eq!, tempdir).

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

Purpose: Builds an absolute path for a temporary user configuration file used in tests. It saves each test from repeating path setup code.

Data flow: It takes a temporary directory and a file name. It joins them into one filesystem path, checks that the result is absolute, and returns it as the project’s absolute-path type. If the path is somehow not absolute, the test fails immediately.

Call relations: The configuration-layer helper uses this when tests need a pretend user config file. It supplies paths that are then wrapped into config layer entries.

Call graph: calls 1 internal fn (from_absolute_path); 1 external calls (path).

fn user_layer(path: AbsolutePathBuf, config: &str) -> ConfigLayerEntry

Purpose: Creates one fake user configuration layer from a path and a TOML text snippet. TOML is a simple configuration-file format, similar to INI but with clearer structure.

Data flow: It receives the pretend config file path and the config text. It parses the text into structured TOML data, labels the layer as coming from a user file, and returns a config layer entry ready to be put into a stack.

Call relations: Tests call this while building a ConfigLayerStack. That stack is then passed into plugin loading code to see how real user configuration would be interpreted.

Call graph: calls 1 internal fn (new); 1 external calls (from_str).

fn configured_plugins_from_stack_merges_user_layers()

Purpose: Checks that plugin settings from multiple user config layers are combined rather than one layer erasing the other. Without this, plugins from a base config and a profile or work config could disappear unexpectedly.

Data flow: The test creates two temporary config layers: one enabling a plugin named base and another disabling a plugin named profile. It builds a config stack from both, asks the loader for the configured plugins, and compares the result with the exact two plugin settings it expects.

Call relations: This test drives the config-stack path that feeds plugin loading. It relies on the helper functions for temporary user paths and layers, then verifies the public result of configured_plugins_from_stack.

Call graph: calls 1 internal fn (new); 5 external calls (new, default, assert_eq!, default, vec!).

async fn hooks_only_scope_shares_plugin_resolution_without_loading_other_capabilities()

Purpose: Checks that hook-only plugin loading uses the same plugin discovery and validation as full loading, while deliberately skipping non-hook features. This matters because hook startup should be reliable and lightweight.

Data flow: The test creates several fake plugins: a valid one with hooks plus skills, MCP servers, and apps; a disabled one; a malformed one; a missing one; and one with broken hook JSON. It loads the same config twice, once fully and once in hooks-only mode. It compares the validation-related fields from both loads, then confirms that the hooks-only version of the valid plugin did not load manifest name, skills, MCP servers, or apps.

Call relations: This test calls the normal full plugin loading path and the scoped loading path side by side. It shows that PluginLoadScope::HooksOnly shares plugin resolution behavior with the full loader, but stops before handing off to the extra capability loaders.

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

fn curated_plugin_cache_version_shortens_full_git_sha()

Purpose: Checks that a full Git commit identifier is shortened when used as a curated plugin cache version. A Git SHA is a long fingerprint for a commit; shortening it makes cache folder names more readable while still identifying the version well enough for this use.

Data flow: It gives the cache-version helper a 40-character hexadecimal commit string. It expects the result to be just the first eight characters.

Call relations: This test exercises the version-normalizing helper directly. It protects the naming behavior used when marketplace or curated plugins are stored in the local cache.

Call graph: 1 external calls (assert_eq!).

fn curated_plugin_cache_version_preserves_non_git_sha_versions()

Purpose: Checks that version names that are not full Git commit identifiers are left unchanged. This prevents friendly labels like export-backup from being altered.

Data flow: It passes two non-full-SHA strings into the cache-version helper: a named version and a too-short numeric string. It expects each returned value to match the input exactly.

Call relations: This test complements the Git SHA shortening test. Together they define when the cache-version helper should rewrite a version string and when it should not.

Call graph: 1 external calls (assert_eq!).

fn plugin_id() -> PluginId

Purpose: Creates the standard plugin ID used by the hook-loading tests. A plugin ID is the full name that identifies a plugin and its marketplace source.

Data flow: It parses the fixed text demo-plugin@test-marketplace into a PluginId value. If that fixed text ever stops being valid, the test fails immediately.

Call relations: The load_sources helper uses this ID when calling the hook loader, and assert_sources uses the same ID to check that loaded hook sources are attributed to the right plugin.

Call graph: calls 1 internal fn (parse); called by 1 (load_sources).

fn plugin_root() -> (tempfile::TempDir, AbsolutePathBuf)

Purpose: Creates a temporary fake plugin directory with the basic folders that plugin-hook tests need. This gives each test a clean sandbox, like a disposable workbench.

Data flow: It creates a new temporary directory, adds a demo-plugin folder inside it, then creates the .codex-plugin folder for the manifest and the hooks folder for hook files. It returns both the temporary directory, which keeps the files alive, and the absolute plugin root path.

Call relations: Most hook-loading tests start here. After this helper creates the fake plugin skeleton, the tests write a manifest and hook files into it before asking load_sources to run the real loader code.

Call graph: calls 1 internal fn (try_from); called by 6 (load_plugin_hooks_discovers_default_hooks_file, load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_reports_invalid_hook_file, load_plugin_hooks_supports_inline_manifest_hook_list, load_plugin_hooks_supports_inline_manifest_hooks, load_plugin_hooks_supports_manifest_hook_path); 2 external calls (create_dir_all, tempdir).

fn write_manifest(plugin_root: &AbsolutePathBuf, manifest: &str)

Purpose: Writes a plugin manifest file into a fake plugin root. The manifest is the plugin’s description file, including things like its name and where hook definitions live.

Data flow: It takes a plugin root and a JSON string. It writes that JSON into .codex-plugin/plugin.json under the plugin root. Its output is the changed test filesystem; the function itself returns nothing useful.

Call relations: Hook-loading tests call this after creating a fake plugin root. The manifest it writes is later read by load_sources through the real manifest-loading code.

Call graph: calls 1 internal fn (join); called by 6 (load_plugin_hooks_discovers_default_hooks_file, load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_reports_invalid_hook_file, load_plugin_hooks_supports_inline_manifest_hook_list, load_plugin_hooks_supports_inline_manifest_hooks, load_plugin_hooks_supports_manifest_hook_path); 1 external calls (write).

fn write_hook_file(plugin_root: &AbsolutePathBuf, relative_path: &str, event: &str, command: &str)

Purpose: Writes a simple hook configuration file for tests. It hides the repetitive JSON shape so each test can focus on which file path, event, and command matter.

Data flow: It receives a plugin root, a relative file path, a hook event name, and a command string. It formats those values into a small hooks JSON document and writes it at the requested path. The result is a hook file on disk for the loader to discover.

Call relations: Tests that need hook files named by the manifest use this helper. load_sources later reads those files through the real hook-loading path, and assert_sources checks that they were found.

Call graph: calls 1 internal fn (join); called by 2 (load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_supports_manifest_hook_path); 2 external calls (format!, write).

fn load_sources(plugin_root: &AbsolutePathBuf) -> (Vec<PluginHookSource>, Vec<String>)

Purpose: Runs the real hook-loading path against one fake plugin root. It is the bridge between the test setup files and the loader behavior being checked.

Data flow: It reads the plugin manifest from disk, builds a nearby plugin-data directory path, creates the standard test plugin ID, and calls the hook loader. It returns two things: the hook sources that were successfully loaded and any warning messages produced while trying.

Call relations: All hook-discovery tests call this after writing their fake plugin files. It hands control to load_plugin_manifest and load_plugin_hooks, then returns their results for the test assertions.

Call graph: calls 4 internal fn (plugin_id, load_plugin_manifest, as_path, try_from); called by 6 (load_plugin_hooks_discovers_default_hooks_file, load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_reports_invalid_hook_file, load_plugin_hooks_supports_inline_manifest_hook_list, load_plugin_hooks_supports_inline_manifest_hooks, load_plugin_hooks_supports_manifest_hook_path).

fn assert_sources(sources: &[PluginHookSource], expected_relative_paths: &[&str])

Purpose: Checks that loaded hook sources match the expected files or manifest locations. It also checks that each source belongs to the test plugin and contains exactly one hook handler.

Data flow: It receives the loaded hook sources and a list of expected relative paths. It extracts plugin IDs, source paths, and hook counts from the sources, then compares each extracted list with the expected values.

Call relations: Successful hook-loading tests call this after load_sources. It gives those tests a compact way to verify the important shared facts without repeating the same checks every time.

Call graph: called by 5 (load_plugin_hooks_discovers_default_hooks_file, load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_supports_inline_manifest_hook_list, load_plugin_hooks_supports_inline_manifest_hooks, load_plugin_hooks_supports_manifest_hook_path); 1 external calls (assert_eq!).

fn load_plugin_hooks_discovers_default_hooks_file()

Purpose: Checks that, when the manifest does not name any hook paths, the loader looks for the default hooks/hooks.json file. This keeps simple plugins easy to write.

Data flow: The test creates a fake plugin, writes a minimal manifest, and writes a default hook file containing one PreToolUse hook. It loads hook sources and expects no warnings and exactly one source: hooks/hooks.json.

Call relations: This test uses plugin_root and write_manifest for setup, writes the default hook file directly, then calls load_sources and assert_sources to verify the real discovery behavior.

Call graph: calls 4 internal fn (assert_sources, load_sources, plugin_root, write_manifest); 2 external calls (assert_eq!, write).

fn load_plugin_hooks_supports_manifest_hook_path()

Purpose: Checks that a manifest can point to a specific hook file. This lets plugin authors choose a non-default hook file name or location.

Data flow: The test creates a fake plugin whose manifest says its hooks live at ./hooks/one.json. It writes that hook file, loads the sources, and expects no warnings and one source from hooks/one.json.

Call relations: This test uses the shared plugin setup helpers, then exercises the branch where load_plugin_hooks follows a single path from the manifest instead of using the default file.

Call graph: calls 5 internal fn (assert_sources, load_sources, plugin_root, write_hook_file, write_manifest); 1 external calls (assert_eq!).

fn load_plugin_hooks_manifest_paths_replace_default_hooks_file()

Purpose: Checks that manifest-specified hook paths replace the default hooks/hooks.json discovery. If a plugin explicitly lists hook files, the loader should not also pick up an accidental default file.

Data flow: The test writes a manifest listing two hook files, then also writes a default hook file that should be ignored. After loading, it expects only hooks/one.json and hooks/two.json, with no warnings.

Call relations: This test builds on the same helper path as the other hook tests. It specifically verifies the priority rule inside load_plugin_hooks: explicit manifest paths take over from the default convention.

Call graph: calls 5 internal fn (assert_sources, load_sources, plugin_root, write_hook_file, write_manifest); 1 external calls (assert_eq!).

fn load_plugin_hooks_supports_inline_manifest_hooks()

Purpose: Checks that a plugin can put hook definitions directly inside its manifest instead of in a separate file. This supports compact plugins with small hook setups.

Data flow: The test writes a manifest whose hooks field contains a complete hook configuration object. It loads sources and expects one source labeled as coming from plugin.json#hooks[0], with no warnings.

Call relations: This test does not create a separate hook file. It sends the manifest through load_sources and then uses assert_sources to confirm that load_plugin_hooks treated the inline manifest content as a hook source.

Call graph: calls 4 internal fn (assert_sources, load_sources, plugin_root, write_manifest); 1 external calls (assert_eq!).

fn load_plugin_hooks_reports_invalid_hook_file()

Purpose: Checks that an invalid hook file produces a clear warning instead of crashing or silently disappearing. This helps users fix broken plugin hook JSON.

Data flow: The test creates a fake plugin with the default manifest, then writes malformed text into hooks/hooks.json. Loading returns no hook sources and one warning message that includes the file path and parse error.

Call relations: This test uses the same setup and load_sources helper as the successful cases, but it intentionally feeds bad input to the real hook parser. It then checks the warning text directly rather than using assert_sources.

Call graph: calls 3 internal fn (load_sources, plugin_root, write_manifest); 2 external calls (assert_eq!, write).

fn load_plugin_hooks_supports_inline_manifest_hook_list()

Purpose: Checks that a manifest can contain a list of inline hook configurations. This allows one plugin manifest to define multiple separate hook source blocks.

Data flow: The test writes a manifest whose hooks field is a list with two hook objects. After loading, it expects two sources, labeled plugin.json#hooks[0] and plugin.json#hooks[1], and no warnings.

Call relations: This is the list-shaped counterpart to the single inline hook test. It calls load_sources to exercise the real loader and assert_sources to confirm both inline entries were preserved as separate sources.

Call graph: calls 4 internal fn (assert_sources, load_sources, plugin_root, write_manifest); 1 external calls (assert_eq!).

fn materialize_git_subdir_uses_sparse_checkout()

Purpose: Checks that materializing a marketplace plugin from a Git repository can fetch only the requested subdirectory. Sparse checkout means Git checks out selected paths instead of the whole repository, like taking one folder from a filing cabinet rather than copying every drawer.

Data flow: The test creates a temporary Git repository with a desired plugin folder, another plugin folder, and a root file. It commits those files, asks the marketplace materializer to load only plugins/toolkit, and then checks that the resulting materialized path contains the toolkit marker but not the unrelated root or other plugin files.

Call relations: This test prepares a real small Git repository, then calls the marketplace source materialization path with a Git source that names a subdirectory. Its assertions protect the loader’s handoff to Git checkout logic and ensure the cache stays focused on the requested plugin.

Call graph: 5 external calls (assert!, assert_eq!, create_dir_all, write, tempdir).

fn write_alternate_marketplace(repo_root: &Path, contents: &str) -> AbsolutePathBuf

Purpose: Creates a marketplace JSON file in the alternate .claude-plugin/marketplace.json location used by several tests. It keeps those tests short and consistent.

Data flow: It receives a fake repository root and JSON text. It builds the alternate marketplace path, creates the parent folder, writes the JSON there, converts the path into the project's absolute-path type, and returns that absolute path.

Call relations: This is a test helper. Tests for alternate layouts and mixed plugin sources call it when they need a marketplace file without repeating the same folder-creation and file-writing steps.

Call graph: calls 1 internal fn (try_from); called by 5 (find_marketplace_plugin_supports_alternate_layout_and_string_local_source, list_marketplaces_includes_plugins_without_discoverable_manifest, list_marketplaces_keeps_remote_and_local_plugin_sources, list_marketplaces_prefers_first_supported_manifest_layout, list_marketplaces_supports_alternate_manifest_layout); 3 external calls (join, create_dir_all, write).

fn write_alternate_plugin_manifest(plugin_root: &Path, contents: &str)

Purpose: Creates a plugin manifest JSON file in the alternate .claude-plugin/plugin.json location. It is used to check that marketplace listing can read plugin details from that layout.

Data flow: It receives a plugin folder and JSON text. It joins the folder with the alternate manifest path, creates the needed directory, and writes the JSON file; it does not return anything.

Call relations: This helper is used by the alternate-manifest-layout test before the marketplace is listed, so the production listing code has a manifest file to discover.

Call graph: called by 1 (list_marketplaces_supports_alternate_manifest_layout); 3 external calls (join, create_dir_all, write).

fn find_marketplace_plugin_finds_repo_marketplace_plugin()

Purpose: Checks the basic case: a plugin listed in a repository marketplace can be found by name. This proves the normal marketplace path and local plugin path resolution work.

Data flow: The test creates a temporary repository with .git, writes a marketplace containing one local plugin, asks the marketplace lookup code for that plugin, and compares the returned plugin identity, source path, policy, and empty metadata fields to the expected values.

Call relations: The Rust test runner calls this test. Inside it, the production marketplace lookup is exercised directly, and the result is checked with an equality assertion.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn find_marketplace_plugin_supports_alternate_layout_and_string_local_source()

Purpose: Checks that a marketplace in the alternate .claude-plugin layout is accepted, and that a simple string source like ./plugins/name is treated as a local plugin path.

Data flow: The test creates a fake repository, writes an alternate marketplace using the helper, looks up the named plugin, and verifies that the returned source is the absolute path under the repository root with the default install and authentication policy.

Call relations: The test runner calls this test. It relies on write_alternate_marketplace for setup, then hands the resulting path to the production lookup code.

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

fn find_marketplace_plugin_supports_git_subdir_sources()

Purpose: Checks that a plugin can come from a subfolder inside a Git repository. This matters because one remote repository can contain many plugins.

Data flow: The test writes a marketplace entry with a Git-subdirectory source, including a GitHub shorthand URL, subfolder path, branch name, and commit hash. It looks up the plugin and expects a normalized full GitHub URL plus the same subfolder, branch, and hash.

Call relations: The test runner calls this test to exercise the Git source parsing path in the marketplace lookup code.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn find_marketplace_plugin_normalizes_github_shorthand_with_dot_git_suffix()

Purpose: Checks that GitHub shorthand ending in .git is converted into a full GitHub URL without becoming malformed.

Data flow: The test writes a marketplace whose Git source URL is openai/toolkit.git, asks for the plugin, and verifies that the source becomes https://github.com/openai/toolkit.git with the expected subdirectory and no branch or hash.

Call relations: The test runner calls this test. It focuses on the URL-normalization part of the marketplace lookup flow.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn find_marketplace_plugin_normalizes_relative_git_source_urls_to_marketplace_root()

Purpose: Checks that relative Git source URLs are interpreted relative to the marketplace's repository root, not some unpredictable current working directory.

Data flow: For both Unix-style and Windows-style relative paths, the test creates a fake remote Git folder under the repository, writes a marketplace pointing to it, looks up the plugin, and expects the Git URL field to be the absolute path to that local remote folder.

Call relations: The test runner calls this test. It repeatedly drives the production lookup code with two path spellings to make sure cross-platform path handling behaves the same.

Call graph: calls 1 internal fn (try_from); 5 external calls (assert_eq!, format!, create_dir_all, write, tempdir).

fn normalize_relative_git_plugin_source_url_rejects_parent_traversal()

Purpose: Checks that relative Git URLs cannot escape upward out of the marketplace root using ... This is a safety rule that prevents a marketplace from pointing outside its allowed area by path trickery.

Data flow: The test tries several parent-directory path forms. Each one is passed to the URL-normalizing function, and the test expects an error saying the relative Git source must stay within the marketplace root.

Call relations: The test runner calls this test. Unlike many tests here, it calls the lower-level normalization function directly to verify the exact safety check and error text.

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

fn find_marketplace_plugin_skips_root_equivalent_git_subdir_paths()

Purpose: Checks that Git subdirectory sources whose path effectively means “the repository root” are not accepted as valid plugin subdirectories.

Data flow: The test tries path values like ., ./, and plugins/... For each one, it writes a marketplace entry, looks up the plugin, and expects a “not found” error because the invalid entry is skipped.

Call relations: The test runner calls this test. It drives the normal plugin lookup path and confirms invalid Git-subdirectory entries are filtered out before a result is returned.

Call graph: calls 1 internal fn (try_from); 5 external calls (assert_eq!, format!, create_dir_all, write, tempdir).

fn find_marketplace_plugin_reports_missing_plugin()

Purpose: Checks the error message when a marketplace exists but does not contain the requested plugin.

Data flow: The test writes an empty marketplace, asks for a plugin named missing, and verifies that the returned error names both the missing plugin and the marketplace.

Call relations: The test runner calls this test. It exercises the normal lookup failure path in the marketplace code.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_supports_alternate_manifest_layout()

Purpose: Checks that marketplace listing can read an alternate marketplace file and also read a plugin's alternate manifest file for display metadata.

Data flow: The test creates a plugin folder, writes an alternate plugin manifest containing a display name, writes an alternate marketplace pointing to that plugin, lists marketplaces for the repository, and expects one marketplace with one plugin whose interface metadata includes that display name.

Call relations: The test runner calls this test. It uses both file-writing helpers, then exercises the production marketplace-listing flow.

Call graph: calls 3 internal fn (write_alternate_marketplace, write_alternate_plugin_manifest, try_from); 3 external calls (assert_eq!, create_dir_all, tempdir).

fn list_marketplaces_includes_plugins_without_discoverable_manifest()

Purpose: Checks that a plugin is still listed even if its local manifest file cannot be found. This keeps a marketplace entry visible instead of disappearing just because optional details are missing.

Data flow: The test writes an alternate marketplace pointing to a local plugin folder that has no manifest. It lists marketplaces and expects the plugin to appear with no interface metadata.

Call relations: The test runner calls this test. It uses write_alternate_marketplace for setup and then checks that listing is tolerant of missing plugin manifests.

Call graph: calls 2 internal fn (write_alternate_marketplace, try_from); 3 external calls (assert_eq!, create_dir_all, tempdir).

fn list_marketplaces_prefers_first_supported_manifest_layout()

Purpose: Checks that when both supported marketplace layouts exist in a repository, the normal .agents/plugins/marketplace.json layout wins.

Data flow: The test writes a normal marketplace and an alternate marketplace in the same fake repository. It lists marketplaces and verifies that only the normal marketplace is returned.

Call relations: The test runner calls this test. It uses the alternate-marketplace helper plus direct file writing to compare the layout-selection order in the production listing code.

Call graph: calls 2 internal fn (write_alternate_marketplace, try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_supports_explicit_api_marketplace_manifest_path()

Purpose: Checks that callers can pass the path to a specific marketplace JSON file instead of only passing a repository root.

Data flow: The test writes an api_marketplace.json file under .agents/plugins, passes that exact file path as the search input, lists marketplaces, and expects the marketplace and its local plugin to be returned.

Call relations: The test runner calls this test. It exercises the listing path used when an API or caller already knows the marketplace file it wants read.

Call graph: calls 1 internal fn (try_from); 5 external calls (assert_eq!, create_dir_all, write, from_ref, tempdir).

fn list_marketplaces_returns_home_and_repo_marketplaces()

Purpose: Checks that marketplace listing includes both a user's home marketplace and a repository marketplace. This lets personal and project-specific plugin catalogs coexist.

Data flow: The test creates separate fake home and repository roots, writes one marketplace in each with overlapping and unique plugin names, lists with both locations available, and expects two marketplace entries in order: home first, repository second.

Call relations: The test runner calls this test. It drives the listing flow with an optional home directory so the code must combine home-level and repo-level discoveries.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_keeps_distinct_entries_for_same_name()

Purpose: Checks that two marketplace files with the same marketplace name are still treated as separate entries when they live at different paths.

Data flow: The test writes home and repository marketplaces with the same name and same plugin name but different local paths. Listing returns both marketplaces separately, and a direct lookup in the repository marketplace resolves to the repository plugin path.

Call relations: The test runner calls this test. It first exercises marketplace listing, then calls the plugin lookup code to confirm that the chosen marketplace file controls which duplicate plugin entry is used.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_dedupes_multiple_roots_in_same_repo()

Purpose: Checks that passing both a repository root and a nested folder inside the same repository does not produce duplicate marketplace entries.

Data flow: The test creates a repository with a nested project folder, writes one marketplace at the repository root, passes both paths as inputs, and expects a single marketplace result.

Call relations: The test runner calls this test. It exercises the repository-root discovery and de-duplication part of marketplace listing.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_reads_marketplace_display_name()

Purpose: Checks that display metadata on the marketplace itself is read correctly. This is the name a user interface may show instead of the internal marketplace name.

Data flow: The test writes a marketplace with an interface.displayName value, lists marketplaces, and verifies that the returned marketplace interface contains that display name.

Call relations: The test runner calls this test. It focuses on the marketplace-level metadata path inside the listing code.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_skips_invalid_plugins_but_keeps_marketplace()

Purpose: Checks that one bad plugin entry does not make the entire marketplace disappear. This keeps valid marketplace information available even when a plugin source is malformed.

Data flow: The test writes one valid marketplace and one marketplace whose plugin has an invalid local path. Listing returns both marketplaces, but the invalid marketplace has an empty plugin list.

Call relations: The test runner calls this test. It verifies that the production listing flow filters bad plugin entries while preserving the surrounding marketplace.

Call graph: calls 1 internal fn (try_from); 5 external calls (assert!, assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_skips_plugins_with_invalid_names_but_keeps_marketplace()

Purpose: Checks that plugins with invalid names are skipped while valid plugins in the same marketplace remain listed.

Data flow: The test writes a marketplace containing one valid plugin name and one invalid name with a dot. It lists marketplaces and expects only the valid plugin to appear.

Call relations: The test runner calls this test. It exercises the validation step that turns raw marketplace JSON entries into safe plugin records.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_reports_marketplace_load_errors()

Purpose: Checks that a broken marketplace file is reported as an error while other valid marketplaces are still returned.

Data flow: The test writes one valid marketplace and one invalid JSON file. It lists marketplaces, then verifies that the valid marketplace is present and that the outcome also contains one load error tied to the broken file path.

Call relations: The test runner calls this test. It checks the listing function's combined outcome: successful marketplace results plus recoverable errors.

Call graph: calls 1 internal fn (try_from); 5 external calls (assert!, assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_keeps_remote_and_local_plugin_sources()

Purpose: Checks that listing preserves different kinds of plugin sources: local folders, full remote URLs, and Git subdirectories.

Data flow: The test writes an alternate marketplace containing three plugins with different source forms. It lists marketplaces and expects the local path to become absolute, the remote URL to become a Git URL ending in .git, and the Git subdirectory source to include its path, branch, and hash.

Call relations: The test runner calls this test. It uses write_alternate_marketplace for setup and then exercises source normalization during marketplace listing.

Call graph: calls 2 internal fn (write_alternate_marketplace, try_from); 3 external calls (assert_eq!, create_dir_all, tempdir).

fn list_marketplaces_resolves_plugin_interface_paths_to_absolute()

Purpose: Checks that relative asset paths inside a plugin manifest, such as icons and screenshots, become absolute paths based on the plugin folder.

Data flow: The test writes a local plugin manifest with interface metadata and asset paths beginning with ./. It lists marketplaces and expects those asset paths to be converted to absolute paths, while policy products and category override values are also reflected correctly.

Call relations: The test runner calls this test. It exercises marketplace listing, plugin manifest reading, policy parsing, and the path-resolution rules for user-interface assets.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_ignores_legacy_top_level_policy_fields()

Purpose: Checks that old top-level policy fields are ignored in favor of the current policy format. This prevents outdated fields from silently changing install behavior.

Data flow: The test writes a plugin entry with legacy installPolicy and authPolicy fields but no current policy object. After listing, it expects the default policy values rather than the legacy values.

Call relations: The test runner calls this test. It focuses on compatibility behavior in the listing code's policy parsing.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn list_marketplaces_ignores_plugin_interface_assets_without_dot_slash()

Purpose: Checks that plugin interface asset paths are only accepted when they are clearly relative paths beginning with ./. This avoids treating arbitrary or absolute paths as trusted plugin assets.

Data flow: The test writes a plugin manifest with an icon path missing ./, an absolute logo path, and a screenshot path missing ./. Listing still reads safe text metadata, but drops those unsafe asset paths and leaves default policy values intact.

Call relations: The test runner calls this test. It exercises the asset-path validation part of plugin manifest processing during marketplace listing.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn find_marketplace_plugin_skips_invalid_local_paths()

Purpose: Checks that local plugin paths using parent-directory traversal are not accepted by plugin lookup.

Data flow: The test writes a marketplace entry whose local path is ../plugin-1, asks for that plugin, and expects a “not found” error because the unsafe entry is skipped.

Call relations: The test runner calls this test. It drives the production lookup path and confirms invalid local sources are filtered out rather than returned.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn find_marketplace_plugin_uses_first_duplicate_entry()

Purpose: Checks the rule for duplicate plugin names inside one marketplace: the first matching entry wins.

Data flow: The test writes two entries with the same plugin name but different local paths. It looks up that plugin and expects the source path from the first entry.

Call relations: The test runner calls this test. It exercises the marketplace lookup loop and confirms it stops on the first valid matching plugin.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn find_installable_marketplace_plugin_rejects_disallowed_product()

Purpose: Checks that install lookup rejects a plugin when its policy allows only a different product. A product here means the application surface, such as ChatGPT, Codex, or Atlas.

Data flow: The test writes a plugin whose policy lists only CHATGPT, then asks whether it is installable for Atlas. It expects an error saying the plugin is not available for install in that marketplace.

Call relations: The test runner calls this test. It exercises the stricter installability lookup, which builds on normal marketplace lookup and then applies product-availability rules.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn find_marketplace_plugin_allows_missing_products_field()

Purpose: Checks that a missing products policy field does not block normal plugin lookup.

Data flow: The test writes a plugin with an empty policy object, looks it up, and verifies that the returned plugin identity key combines the plugin and marketplace names as expected.

Call relations: The test runner calls this test. It verifies the normal lookup path, not the stricter installability filter, when product restrictions are absent.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn find_installable_marketplace_plugin_rejects_explicit_empty_products()

Purpose: Checks that an explicitly empty product list means the plugin is installable for no products.

Data flow: The test writes a plugin whose policy has products: [], asks whether it is installable for Codex, and expects an unavailable-for-install error.

Call relations: The test runner calls this test. It exercises the installability lookup path and confirms that an empty allow-list is treated differently from a missing products field.

Call graph: calls 1 internal fn (try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

fn build_remote_marketplace_preserves_directory_order_and_appends_installed_only_plugins()

Purpose: This test checks that building a remote marketplace keeps directory plugins in the same order the directory supplied, then adds installed-only plugins at the end when requested. This protects the user-facing marketplace from surprising reordering.

Data flow: It starts with two fake directory plugins and one fake installed plugin that is not in the directory list. It passes those into the marketplace-building logic with the “include installed-only” option turned on. It then reads the resulting plugin IDs and compares them with the expected order: the two directory plugins first, followed by the installed-only plugin.

Call relations: During the test, it uses ordinary test helpers to build sample vectors and compare the final result. It exercises the marketplace-building code from the surrounding module and verifies the returned marketplace instead of handing work off to another local helper.

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

fn directory_plugin(id: &str, name: &str) -> RemotePluginDirectoryItem

Purpose: This helper builds a realistic fake remote directory plugin record for tests. It lets the tests focus on the behavior being checked instead of repeating a large plugin structure every time.

Data flow: It receives a plugin ID and a display name as short text. It fills in a remote plugin directory item with those values and many safe default fields, such as global scope, available installation policy, and an empty release description. It returns the completed fake directory item for a test to use.

Call relations: This helper supports the marketplace test by producing sample remote plugins with predictable IDs and names. It does not call other project logic; it mainly constructs data in the shape expected by the plugin marketplace code.

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

fn item(name: &str, display_name: &str) -> RecommendedPluginItem

Purpose: This helper builds a fake recommended-plugin entry with a given internal name and display name. It keeps the recommendation tests short and readable when they need many sample plugins.

Data flow: It takes a plugin name and a display name. It creates an ID by prefixing the name, sets optional status and installation policy fields to empty, and puts the display name into a small release record. It returns this recommended-plugin item for later validation by the recommendation logic.

Call relations: The large validation test calls this helper repeatedly to make many fake recommendation records. After the helper returns those records, the test passes them into the recommended-plugin mode logic to see how they are filtered, sorted, deduplicated, and capped.

Call graph: called by 1 (recommended_plugins_are_validated_deduplicated_sorted_and_capped); 2 external calls (new, format!).

fn recommended_plugins_enabled_flag_selects_endpoint_or_legacy_mode()

Purpose: This test checks the switch that decides whether recommended plugins come from the new server endpoint or from older legacy behavior. It makes sure only an explicit enabled value of true turns on endpoint mode.

Data flow: It creates several fake JSON server responses: one with enabled set to false, some with enabled missing or null, and one with enabled set to true. Each response is decoded into the expected response type, then passed into the mode-selection logic. The outputs are compared with the expected mode: legacy for false, missing, or null, and endpoint mode for true.

Call relations: The test uses JSON decoding to mimic what a real server response would look like before the plugin code sees it. It then calls the recommended-plugin mode function and checks that the rest of the system would be sent down the correct path.

Call graph: 3 external calls (assert_eq!, from_value, json!).

fn recommended_plugins_require_remote_install_identity()

Purpose: This test makes sure a recommended plugin response must include the remote plugin identity needed for installation. Without that identity, the app would not know which remote plugin to install.

Data flow: It builds a JSON response that enables endpoint mode but includes a plugin missing its required ID. It attempts to decode that JSON into the recommendation response type. The expected result is an error, showing that malformed remote data is rejected before it can be used.

Call relations: This test focuses on deserialization, meaning the step where raw JSON is turned into typed Rust data. It verifies that bad data is stopped at the boundary instead of being passed deeper into recommendation processing.

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

fn recommended_plugins_are_validated_deduplicated_sorted_and_capped()

Purpose: This test checks the main cleanup rules for endpoint-provided recommended plugins. It confirms that the final recommendation list is valid, unique, sorted, and no larger than the configured maximum.

Data flow: It creates more than the maximum number of fake plugins, in reverse order, then adds a duplicate, an invalid plugin ID, a disabled plugin, and a plugin that is not available for installation. It passes all of that into the recommended-plugin mode logic. The result is expected to be endpoint mode with exactly the maximum allowed number of cleaned plugins, beginning with plugin 00 and ending with plugin 49.

Call relations: This test relies on the item helper to create many sample recommendation records. It then exercises the recommendation-cleaning path and verifies the final output that the rest of the app would receive.

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

fn recommended_plugins_bound_model_visible_fields()

Purpose: This test checks that text fields visible to the product model or user interface are kept within safe length limits. This avoids oversized names from remote data leaking into later parts of the system.

Data flow: It creates one recommendation with a name that is too long and another with a display name that is too long. It sends both through the recommendation logic. The overlong internal name is rejected, while the overlong display name is shortened to the allowed maximum length in the final endpoint result.

Call relations: This test feeds carefully chosen boundary-breaking data into the same recommendation mode function used by the other recommendation tests. It checks that the function both drops unsafe identifiers and trims user-visible text where appropriate.

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

fn recommended_plugins_preserve_install_identity_and_normalize_app_ids()

Purpose: This test checks that recommended plugins keep the remote plugin ID needed for installation while cleaning up related connector IDs. Connector IDs are links to app connectors, and the final list should not contain blanks or duplicates.

Data flow: It builds one recommended plugin with a valid remote plugin ID, a short name, a display name, and a connector list containing two real connector IDs, an empty string, and a duplicate. After processing, the output keeps the same remote plugin ID, creates the expected config ID, keeps the display name, and returns only the two unique non-empty connector IDs in order.

Call relations: The test sends a single detailed recommendation into the endpoint-mode processing path. It verifies that the recommendation logic preserves the identity used for installation while cleaning the extra app connector information before other code consumes it.

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

fn recommended_plugins_ignore_invalid_remote_plugin_ids()

Purpose: This test checks that recommendations with invalid remote plugin IDs are silently left out of the endpoint result. This protects the app from trying to show or install a plugin whose identity does not match the expected format.

Data flow: It creates an enabled recommendation response containing one plugin whose ID has an invalid shape. It passes that response into the recommendation mode logic. The output is endpoint mode with an empty plugin list, meaning the bad item was filtered away.

Call relations: This test exercises the same recommendation-cleaning path as the other endpoint-mode tests, but with the focus narrowed to remote plugin ID validation. It confirms that invalid identity data does not travel onward to the rest of the plugin system.

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

fn write_file(path: &Path, contents: &str)

Purpose: Writes a text file for a test, creating its parent folders first. Tests use it to build fake plugin repositories without repeating setup code.

Data flow: It receives a file path and text contents. It makes sure the folder containing that file exists, then writes the text to disk. The result is a real file ready for the sync code or assertions to read.

Call relations: This is the small file-writing helper behind the repository fixtures. The marketplace and plugin fixture builders call it whenever they need to lay down JSON files in a temporary test directory.

Call graph: called by 3 (write_curated_plugin, write_curated_plugin_sha, write_openai_curated_marketplace); 3 external calls (parent, create_dir_all, write).

fn write_curated_plugin(root: &Path, plugin_name: &str)

Purpose: Creates the minimal files for one fake curated plugin. It gives tests a plugin folder with a plugin manifest, which is enough for validation to recognize it.

Data flow: It takes a root folder and a plugin name. From those it builds a path like plugins/<name>/.codex-plugin/plugin.json and writes a tiny JSON manifest naming the plugin. The output is a small on-disk plugin fixture.

Call relations: This helper is used by write_openai_curated_marketplace after that function writes the marketplace list. Together they create a consistent fake curated plugin repository.

Call graph: calls 1 internal fn (write_file); called by 1 (write_openai_curated_marketplace); 2 external calls (join, format!).

fn write_openai_curated_marketplace(root: &Path, plugin_names: &[&str])

Purpose: Creates a fake OpenAI curated marketplace and all plugin folders named in it. Tests use this to represent an already-synced or newly-created local plugin snapshot.

Data flow: It receives a root folder and a list of plugin names. It writes .agents/plugins/marketplace.json with entries pointing to local plugin paths, then creates each plugin’s manifest. The result is a repository-shaped directory that should pass curated plugin validation.

Call relations: Several tests call this when they need a known-good snapshot before running sync logic. It delegates the per-plugin file creation to write_curated_plugin.

Call graph: calls 2 internal fn (write_curated_plugin, write_file); called by 3 (sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists, sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure, sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote); 2 external calls (join, format!).

fn write_curated_plugin_sha(codex_home: &Path)

Purpose: Writes the saved commit SHA for the curated plugin snapshot. This simulates Codex remembering which plugin version it last synced.

Data flow: It receives the Codex home folder. It writes the test SHA into .tmp/plugins.sha, including a newline just like a normal text file. Later checks read this file to decide whether a sync is current.

Call relations: Tests that start with an existing snapshot call this before running failure or fallback scenarios. It relies on write_file to create the needed .tmp folder.

Call graph: calls 1 internal fn (write_file); called by 2 (sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists, sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure); 2 external calls (join, format!).

fn has_plugins_clone_dirs(codex_home: &Path) -> bool

Purpose: Checks whether temporary plugin clone directories are still lying around. Tests use it to confirm failed syncs clean up after themselves.

Data flow: It looks inside the Codex home .tmp directory. If that directory cannot be read, it returns false. Otherwise it scans for directories whose names begin with plugins-clone- and returns true if it finds any.

Call relations: This helper is used by assertions throughout the file after Git or HTTP sync attempts. It verifies that staging directories were removed once the sync either succeeded or failed.

Call graph: 2 external calls (join, read_dir).

fn write_executable_script(path: &Path, contents: &str)

Purpose: Writes a shell script and marks it executable on Unix systems. Tests use this to create fake Git commands with predictable behavior.

Data flow: It receives a script path and script text. It writes the text to disk, reads the file permissions, changes them so the file can be run, and saves those permissions. The result is a runnable test program.

Call relations: Unix-only tests call this to replace the real git command with a controlled script. Those fake scripts simulate success, failure, slow remote checks, and invalid checkouts.

Call graph: called by 5 (concurrent_syncs_serialize_fetches_without_skipping_remote_checks, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_via_git_cleans_up_staged_dir_on_fetch_failure, sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure, sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote); 3 external calls (metadata, set_permissions, write).

fn run_git(repo: &Path, args: &[&str]) -> std::process::Output

Purpose: Runs a real Git command in a given repository and fails the test if Git reports an error. It keeps the larger Git integration test readable.

Data flow: It receives a repository path and command arguments. It executes git -C <repo> with those arguments, checks that the exit status was successful, and returns Git’s captured output. If Git fails, the test stops with Git’s error text.

Call relations: The local rewritten remote test uses this helper to create commits, read SHAs, find the current branch, and push updates. It is the bridge between the test setup and the real Git program.

Call graph: called by 1 (sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote); 2 external calls (assert!, new).

async fn mount_github_repo_and_ref(server: &MockServer, sha: &str)

Purpose: Programs the mock server to answer the two GitHub API requests needed to discover the current curated plugin SHA. This lets HTTP sync tests run without contacting GitHub.

Data flow: It receives a mock server and a SHA. It registers one response for the repository metadata endpoint and another for the main branch reference endpoint. Afterward, sync code that calls those URLs receives the supplied SHA.

Call relations: HTTP fallback and skip-download tests call this before running sync. It sets up the remote-check part of the story, while mount_github_zipball supplies the archive content when needed.

Call graph: called by 4 (sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_skips_archive_download_when_sha_matches, sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure); 5 external calls (given, new, format!, method, path).

async fn mount_github_zipball(server: &MockServer, sha: &str, bytes: Vec<u8>)

Purpose: Programs the mock server to return a zip archive for a specific plugin repository SHA. Tests use it to simulate downloading GitHub’s zipball.

Data flow: It receives a mock server, a SHA, and raw zip bytes. It registers a GET response at the matching zipball URL with a zip content type and those bytes as the body. The output is mock server behavior, not a returned value.

Call relations: Fallback-to-HTTP tests call this after mounting the GitHub ref response. The sync code then downloads these bytes and tries to extract them as the curated plugins repository.

Call graph: called by 3 (sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure); 5 external calls (given, new, format!, method, path).

async fn mount_export_archive(server: &MockServer, bytes: Vec<u8>) -> String

Purpose: Programs the mock server to mimic the backup export service. This backup path is used when normal GitHub-based sync cannot start and no local snapshot exists.

Data flow: It receives a mock server and archive bytes. It registers one endpoint that returns a JSON download URL, then registers that download URL to return the zip bytes. It returns the export API URL that the sync function should call.

Call relations: The export fallback tests call this before running sync with transport overrides. It supplies the backup archive path when the mocked GitHub request is made to fail.

Call graph: called by 2 (sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists, sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists); 5 external calls (given, new, format!, method, path).

async fn run_sync_with_transport_overrides(
    codex_home: PathBuf,
    git_binary: impl Into<String>,
    api_base_url: impl Into<String>,
    backup_archive_api_url: impl Into<String>,
) -> Result<

Purpose: Runs the full plugin sync with test-controlled transport settings. It lets tests choose a fake Git binary, a fake GitHub base URL, and a fake backup export URL.

Data flow: It receives the Codex home path and three transport strings. It moves those values into a blocking background task, calls the real sync function with them, waits for completion, and returns either the synced SHA or an error string.

Call relations: Async tests call this because the real sync work is blocking disk and process work. It connects mock servers and fake Git commands to the production sync entry point with overrideable URLs.

Call graph: called by 5 (sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists, sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_skips_archive_download_when_sha_matches, sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists); 2 external calls (into, spawn_blocking).

async fn run_http_sync(
    codex_home: PathBuf,
    api_base_url: impl Into<String>,
) -> Result<String, String>

Purpose: Runs the HTTP-only curated plugin sync from an async test. It is used when the test wants to focus on zip download and extraction behavior.

Data flow: It receives a Codex home path and API base URL. It runs the HTTP sync function in a blocking background task, waits for it to finish, and returns the resulting SHA or error text.

Call relations: The bad-zip extraction test calls this after preparing mock GitHub responses. It isolates the HTTP path instead of going through the broader Git-then-HTTP fallback wrapper.

Call graph: called by 1 (sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure); 2 external calls (into, spawn_blocking).

fn assert_curated_gmail_repo(repo_path: &Path)

Purpose: Checks that a synced repository contains the expected marketplace file and Gmail plugin manifest. It is a shared assertion for successful sync tests.

Data flow: It receives a repository path. It checks for .agents/plugins/marketplace.json and plugins/gmail/.codex-plugin/plugin.json. It does not return data; it fails the test if either file is missing.

Call relations: Many success-oriented tests call this after a sync completes. It gives a simple proof that the resulting folder is not just present, but shaped like a usable curated plugin repository.

Call graph: called by 6 (concurrent_syncs_serialize_fetches_without_skipping_remote_checks, sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists, sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure, sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote); 1 external calls (assert!).

fn curated_plugins_repo_path_uses_codex_home_tmp_dir()

Purpose: Verifies that the curated plugins repository is stored under the Codex home .tmp/plugins directory. This protects the expected on-disk layout.

Data flow: It creates a temporary Codex home path, asks the production path helper for the curated repo location, and compares the answer to <home>/.tmp/plugins. The output is a pass or failed assertion.

Call relations: This standalone unit test checks the basic path convention that the rest of the sync tests assume when they inspect files.

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

fn read_curated_plugins_sha_reads_trimmed_sha_file()

Purpose: Verifies that the saved plugin SHA is read without its trailing newline. This matters because SHA comparisons should not fail just because the file is line-based.

Data flow: It creates .tmp/plugins.sha containing abc123 followed by a newline, calls the production reader, and expects to receive abc123. The test changes only temporary files.

Call relations: This test covers the SHA-reading helper used by sync decisions. Other tests rely on the same behavior when checking whether the stored snapshot version matches the remote one.

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

fn remove_stale_curated_repo_temp_dirs_removes_only_matching_directories()

Purpose: Verifies that old temporary plugin clone folders are deleted, while fresh clone folders and unrelated folders are kept. This prevents cleanup from being too aggressive.

Data flow: It creates three directories: an old plugins-clone directory, a fresh plugins-clone directory, and an unrelated cache directory. It changes their modification times, runs the cleanup function, then checks that only the old matching directory disappeared.

Call relations: This Unix-only test exercises the cleanup behavior used before or during sync. It protects against both disk clutter from stale staging folders and accidental deletion of unrelated data.

Call graph: 4 external calls (from_secs, assert!, create_dir_all, tempdir).

fn concurrent_syncs_serialize_fetches_without_skipping_remote_checks()

Purpose: Verifies that two syncs running at the same time do not both fetch into the repository, but both still check the remote version. This prevents races while keeping update checks accurate.

Data flow: It creates a fake Git script that logs every invocation and simulates a slow remote SHA check. Two threads start sync at the same time. After both finish, the test checks the synced files, saved SHA, and invocation log: two remote checks happened, only one fetch happened, and no Git clone command was used.

Call relations: This test uses write_executable_script to build the fake Git command and assert_curated_gmail_repo to verify the final snapshot. It directly exercises the production sync wrapper under concurrent pressure.

Call graph: calls 2 internal fn (assert_curated_gmail_repo, write_executable_script); 8 external calls (new, assert!, assert_eq!, format!, read_to_string, scope, new, tempdir).

fn sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote()

Purpose: Tests the normal Git-based sync path using a local repository that pretends to be GitHub. It also checks incremental updates and the no-change fast path.

Data flow: It builds a real Git repository containing a Gmail plugin, clones it as a bare remote, and uses a Git config rewrite so https://github.com/openai/plugins.git points to that local remote. It runs the sync, checks the saved SHA and files, commits a new Linear plugin, syncs again, and finally syncs once more with no changes. The expected outcome is correct files, correct SHAs, no leftover temporary clone directories, and efficient Git commands.

Call relations: This is the broadest Git integration test in the file. It uses run_git for real repository operations, write_executable_script to wrap Git and log calls, write_openai_curated_marketplace to update fixture content, and assert_curated_gmail_repo to confirm the synced checkout.

Call graph: calls 4 internal fn (assert_curated_gmail_repo, run_git, write_executable_script, write_openai_curated_marketplace); 10 external calls (from_utf8_lossy, assert!, assert_eq!, new, format!, create_dir_all, read_to_string, write, new, tempdir).

async fn sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable()

Purpose: Verifies that sync still works when the Git executable cannot be found. In that case, the system should download the curated plugins as a zip over HTTP.

Data flow: It starts a mock server, teaches it the remote SHA and zipball content, then runs sync with a deliberately missing Git binary. The result should be the expected SHA, a usable Gmail plugin repository, and a saved plugins.sha file.

Call relations: This async test combines mount_github_repo_and_ref, mount_github_zipball, curated_repo_zipball_bytes, and run_sync_with_transport_overrides. It proves the fallback path takes over when Git cannot even start.

Call graph: calls 5 internal fn (assert_curated_gmail_repo, curated_repo_zipball_bytes, mount_github_repo_and_ref, mount_github_zipball, run_sync_with_transport_overrides); 3 external calls (start, assert_eq!, tempdir).

async fn sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails()

Purpose: Verifies that HTTP sync is used when Git exists but returns an error. This covers machines where Git is installed but broken or blocked.

Data flow: It writes a fake Git script that always exits with failure, prepares mock GitHub responses with a valid zipball, and runs sync. The expected output is a successful SHA and a valid local curated plugin snapshot despite the Git failure.

Call relations: This Unix-only async test uses write_executable_script for the failing Git command, the mock-mount helpers for the HTTP path, and assert_curated_gmail_repo to confirm fallback success.

Call graph: calls 6 internal fn (assert_curated_gmail_repo, curated_repo_zipball_bytes, mount_github_repo_and_ref, mount_github_zipball, run_sync_with_transport_overrides, write_executable_script); 4 external calls (start, assert_eq!, new, tempdir).

fn sync_openai_plugins_repo_via_git_cleans_up_staged_dir_on_fetch_failure()

Purpose: Verifies that a failed Git fetch does not leave temporary clone directories behind. This keeps the user’s .tmp folder from collecting broken partial checkouts.

Data flow: It creates a fake Git script that reports a remote SHA, initializes a staged repository, then fails during fetch with an error message. The test runs Git sync, expects that error, and checks that no plugins-clone-* directories remain.

Call relations: This Unix-only test uses write_executable_script to simulate a partial Git failure and has_plugins_clone_dirs to verify cleanup. It focuses on failure hygiene rather than successful plugin content.

Call graph: calls 1 internal fn (write_executable_script); 4 external calls (assert!, format!, new, tempdir).

fn sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure()

Purpose: Verifies that a bad newly-fetched snapshot does not replace a good existing snapshot. This protects users from losing working plugins because a remote archive is malformed.

Data flow: It first creates a valid existing Gmail snapshot and saved SHA. Then it uses a fake Git script to stage an update that contains a plugin file but no marketplace manifest, which should fail validation. The test expects an error, confirms the old Gmail snapshot is still present, confirms the bad Linear folder was not installed, and checks the old SHA remains saved.

Call relations: This test combines fixture writers, fake Git scripting, assert_curated_gmail_repo, and clone-directory cleanup checks. It exercises the staged-update safety rule: validate first, replace only after success.

Call graph: calls 4 internal fn (assert_curated_gmail_repo, write_curated_plugin_sha, write_executable_script, write_openai_curated_marketplace); 6 external calls (assert!, assert_eq!, format!, create_dir_all, new, tempdir).

async fn sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure()

Purpose: Verifies that the HTTP sync path cleans up its temporary directory when the downloaded file is not a valid zip archive.

Data flow: It prepares mock GitHub responses where the SHA lookup succeeds but the zipball body is plain invalid bytes. It runs HTTP sync, expects an archive-opening error, and checks that no temporary plugin clone directories remain.

Call relations: This async test uses mount_github_repo_and_ref, mount_github_zipball, and run_http_sync. It mirrors the Git cleanup test for the zip extraction path.

Call graph: calls 3 internal fn (mount_github_repo_and_ref, mount_github_zipball, run_http_sync); 3 external calls (start, assert!, tempdir).

async fn sync_openai_plugins_repo_skips_archive_download_when_sha_matches()

Purpose: Verifies that the sync process does not download a zip archive when the locally saved SHA already matches the remote SHA. This avoids unnecessary network and disk work.

Data flow: It creates an existing local repository and writes a matching plugins.sha file. The mock server only needs to answer the remote SHA lookup. After sync runs with Git unavailable, the test confirms the saved SHA and existing marketplace file are still there.

Call relations: This test uses mount_github_repo_and_ref and run_sync_with_transport_overrides. Because no zipball mock is registered, the test would fail if the sync incorrectly tried to download an archive.

Call graph: calls 2 internal fn (mount_github_repo_and_ref, run_sync_with_transport_overrides); 7 external calls (start, assert!, assert_eq!, format!, create_dir_all, write, tempdir).

async fn sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists()

Purpose: Verifies the last-resort backup archive path. If GitHub lookup fails and there is no local snapshot, sync should be able to use an export archive instead.

Data flow: It makes the mock GitHub repository lookup return an error, then mounts a backup export archive containing a Git SHA and Gmail plugin files. Sync runs with Git unavailable and the backup URL supplied. The expected result is the backup SHA, valid plugin files, and a saved SHA file.

Call relations: This async test uses mount_export_archive, curated_repo_backup_archive_zip_bytes, run_sync_with_transport_overrides, and assert_curated_gmail_repo. It covers the emergency path used when the normal remote source is unavailable.

Call graph: calls 4 internal fn (assert_curated_gmail_repo, curated_repo_backup_archive_zip_bytes, mount_export_archive, run_sync_with_transport_overrides); 7 external calls (given, start, new, assert_eq!, tempdir, method, path).

async fn sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists()

Purpose: Verifies that the backup export archive is not used when a local snapshot already exists. This avoids replacing a known local copy with a fallback source after a temporary GitHub failure.

Data flow: It creates an existing Linear plugin snapshot and saved SHA, then makes the GitHub lookup fail while also offering a backup archive with different content. Sync is expected to return an error saying export fallback was skipped. The test confirms the original plugin manifest and saved SHA did not change.

Call relations: This test uses write_openai_curated_marketplace and write_curated_plugin_sha to create the starting snapshot, then mount_export_archive and run_sync_with_transport_overrides to simulate the failed remote plus available backup. It checks the policy decision around when fallback is allowed.

Call graph: calls 5 internal fn (curated_repo_backup_archive_zip_bytes, mount_export_archive, run_sync_with_transport_overrides, write_curated_plugin_sha, write_openai_curated_marketplace); 9 external calls (given, start, new, assert!, assert_eq!, read_to_string, tempdir, method, path).

fn read_extracted_backup_archive_git_sha_reads_head_ref_from_extracted_repo()

Purpose: Verifies that the backup archive SHA reader can follow a normal Git HEAD reference. Backup archives include a .git directory, and this function must recover the commit SHA from it.

Data flow: It creates .git/HEAD pointing to refs/heads/main and writes a SHA into that ref file. It calls the production reader and expects that SHA back without the newline.

Call relations: This standalone unit test supports the export archive tests. It checks the helper that identifies which commit an extracted backup archive represents.

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

fn read_extracted_backup_archive_git_sha_rejects_non_refs_head_target()

Purpose: Verifies that the backup archive SHA reader rejects a HEAD reference that does not stay under refs/. This is a safety check against unexpected or unsafe Git metadata.

Data flow: It writes .git/HEAD containing ref: HEAD rather than a refs/... path. It calls the SHA reader, expects an error, and checks that the error explains the ref must stay under refs/.

Call relations: This test focuses on defensive validation in the backup archive reader. It pairs with the path traversal test to make sure extracted Git metadata cannot point wherever it wants.

Call graph: 4 external calls (assert!, create_dir_all, write, tempdir).

fn read_extracted_backup_archive_git_sha_rejects_path_traversal_ref()

Purpose: Verifies that the backup archive SHA reader rejects references containing path traversal, such as ../. This prevents archive metadata from escaping the intended .git/refs area.

Data flow: It writes .git/HEAD pointing to refs/heads/../../evil. It calls the SHA reader, expects an error, and checks that the error mentions invalid path components.

Call relations: This unit test protects the same backup archive SHA-reading path used by export fallback. It specifically checks that suspicious reference paths are blocked before any ref file is read.

Call graph: 4 external calls (assert!, create_dir_all, write, tempdir).

fn curated_repo_zipball_bytes(sha: &str) -> Vec<u8>

Purpose: Builds an in-memory zip file shaped like GitHub’s repository zipball for the curated plugins repo. Tests use it as mock download content.

Data flow: It receives a SHA, creates a zip archive in memory with a top-level folder named like openai-plugins-<sha>, and writes a marketplace file plus a Gmail plugin manifest inside. It returns the zip bytes.

Call relations: HTTP fallback tests pass these bytes to mount_github_zipball. The sync code then downloads and extracts the generated archive as if it came from GitHub.

Call graph: calls 1 internal fn (new); called by 2 (sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails); 4 external calls (default, new, new, format!).

fn curated_repo_backup_archive_zip_bytes(sha: &str) -> Vec<u8>

Purpose: Builds an in-memory backup export archive containing both plugin files and minimal Git metadata. Tests use it to simulate the export fallback service.

Data flow: It receives a SHA, creates a zip archive in memory, writes .git/HEAD and refs/heads/main carrying that SHA, then writes the marketplace and Gmail plugin manifest under the plugins folder. It returns the zip bytes.

Call relations: Export fallback tests pass these bytes to mount_export_archive. The production sync code extracts the archive, reads the embedded Git SHA, validates the plugin repository, and installs it if allowed.

Call graph: calls 1 internal fn (new); called by 2 (sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists, sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists); 4 external calls (default, new, new, format!).

fn test_config(server: &MockServer) -> RemotePluginServiceConfig

Purpose: Builds a test-only remote service configuration that points at the fake HTTP server instead of the real ChatGPT service. Tests use it so all network calls stay local and predictable.

Data flow: It receives a running fake server. It reads the server's base URL, appends the backend API path, and returns a RemotePluginServiceConfig containing that test URL.

Call relations: The main async tests call this after starting a MockServer. The resulting config is then passed into remote sharing functions such as saving, listing, updating, and deleting shares, so those functions talk to the fake server prepared by the test.

Call graph: called by 5 (delete_remote_plugin_share_deletes_workspace_plugin, list_remote_plugin_shares_fetches_created_workspace_plugins, save_remote_plugin_share_creates_workspace_plugin, save_remote_plugin_share_updates_existing_workspace_plugin, update_remote_plugin_share_targets_updates_targets); 1 external calls (format!).

fn test_auth() -> CodexAuth

Purpose: Creates fake ChatGPT authentication data for tests. This lets the code send realistic authorization headers without requiring a real user login.

Data flow: It takes no input. It asks the authentication library for a dummy test credential and returns that credential to the caller.

Call relations: The network-facing tests call this before invoking remote sharing functions. Those functions use the returned credential to add the expected bearer token and account ID headers, which the fake server checks.

Call graph: calls 1 internal fn (create_dummy_chatgpt_auth_for_testing); called by 5 (delete_remote_plugin_share_deletes_workspace_plugin, list_remote_plugin_shares_fetches_created_workspace_plugins, save_remote_plugin_share_creates_workspace_plugin, save_remote_plugin_share_updates_existing_workspace_plugin, update_remote_plugin_share_targets_updates_targets).

fn write_file(path: &Path, contents: &str)

Purpose: Writes a file during a test, creating parent folders first if needed. It is a small helper for building fake plugin directories and local metadata files.

Data flow: It receives a file path and text contents. It makes sure the containing directory exists, then writes the text to the file. It returns nothing, but changes the temporary test filesystem.

Call relations: Higher-level helpers call this when constructing plugins and saved local-path mappings. A few archive tests also call it directly to add special files, such as an intentionally large file or a file with a long path.

Call graph: called by 4 (archive_plugin_for_upload_rejects_archives_over_limit, archive_plugin_for_upload_round_trips_through_plugin_bundle_archive_with_long_paths, write_plugin_share_local_path_mapping, write_test_plugin); 3 external calls (parent, create_dir_all, write).

fn write_test_plugin(root: &Path, plugin_name: &str) -> PathBuf

Purpose: Creates a minimal fake plugin folder for tests. The plugin has just enough structure to look like a real Codex plugin: a manifest and one skill file.

Data flow: It receives a root directory and a plugin name. It creates a subdirectory with that name, writes .codex-plugin/plugin.json, writes a sample skill markdown file, and returns the path to the plugin folder.

Call relations: Most archive and upload tests call this first to get a realistic local plugin. It relies on write_file for the actual disk writes, then hands the resulting path to packaging and remote-sharing functions.

Call graph: calls 1 internal fn (write_file); called by 5 (archive_plugin_for_upload_places_manifest_at_archive_root, archive_plugin_for_upload_rejects_archives_over_limit, archive_plugin_for_upload_round_trips_through_plugin_bundle_archive_with_long_paths, save_remote_plugin_share_creates_workspace_plugin, save_remote_plugin_share_updates_existing_workspace_plugin); 2 external calls (join, format!).

fn write_plugin_share_local_path_mapping(
    codex_home: &Path,
    remote_plugin_id: &str,
    plugin_path: &AbsolutePathBuf,
)

Purpose: Creates the local bookkeeping file that remembers which local plugin path belongs to a remote plugin ID. Tests use this to simulate a user who has already shared a plugin before.

Data flow: It receives the Codex home directory, a remote plugin ID, and an absolute local plugin path. It writes a JSON file under the temporary Codex home that maps the remote ID to the local path.

Call relations: The list and delete tests call this before running the code under test. Listing should read this saved mapping and include the local path in its result; deleting should remove the mapping afterward.

Call graph: calls 1 internal fn (write_file); called by 2 (delete_remote_plugin_share_deletes_workspace_plugin, list_remote_plugin_shares_fetches_created_workspace_plugins); 2 external calls (join, format!).

fn archive_file_entries(archive_bytes: &[u8]) -> BTreeMap<String, Vec<u8>>

Purpose: Opens a compressed plugin archive and returns the regular files inside it. Tests use this to inspect what was actually uploaded or produced by the archive builder.

Data flow: It receives bytes for a gzip-compressed tar archive. It decompresses the bytes, walks through the archive entries, skips anything that is not a file, reads each file's contents, and returns a sorted map from archive path to file bytes.

Call relations: Archive tests call this after creating an upload archive. The create-share test also uses it on the body of the fake upload request, proving that the remote upload contained the expected plugin files.

Call graph: called by 2 (archive_plugin_for_upload_places_manifest_at_archive_root, save_remote_plugin_share_creates_workspace_plugin); 2 external calls (new, new).

fn remote_plugin_json(plugin_id: &str) -> serde_json::Value

Purpose: Builds a standard fake JSON description of a remote plugin. This keeps the mock backend responses consistent across tests.

Data flow: It receives a plugin ID. It returns a JSON object with that ID, a demo plugin name, workspace scope, policies, version, description, interface details, and an empty skill list.

Call relations: Other JSON helper functions build on this base object. Tests use those helpers in fake server responses so the production parsing code sees data shaped like the real backend would send.

Call graph: called by 2 (installed_remote_plugin_json, remote_plugin_json_with_share_url_and_principals); 1 external calls (json!).

fn remote_plugin_json_with_share_url_and_principals(
    plugin_id: &str,
    share_url: Option<&str>,
    share_principals: serde_json::Value,
) -> serde_json::Value

Purpose: Builds fake remote plugin JSON that includes sharing information, such as a share link and the people or groups the plugin is shared with.

Data flow: It receives a plugin ID, an optional share URL, and JSON describing share principals. It starts with the standard remote plugin JSON, adds or overrides the sharing-related fields, and returns the enriched JSON object.

Call relations: The list-shares test uses this helper when preparing paginated fake backend responses. It depends on remote_plugin_json for the common plugin fields, then adds the fields needed to test share-specific parsing.

Call graph: calls 1 internal fn (remote_plugin_json); 2 external calls (json!, unreachable!).

fn installed_remote_plugin_json(plugin_id: &str) -> serde_json::Value

Purpose: Builds fake JSON for a remote plugin that is already installed and enabled. This lets list tests check that installed status is merged into share results.

Data flow: It receives a plugin ID. It starts with the standard remote plugin JSON, adds enabled status and an empty list of disabled skills, and returns the JSON object.

Call relations: The list-shares test uses this in the fake response for installed workspace plugins. It depends on remote_plugin_json for the common fields and adds the installation state that the code under test should recognize.

Call graph: calls 1 internal fn (remote_plugin_json); 2 external calls (json!, unreachable!).

fn empty_pagination_json() -> serde_json::Value

Purpose: Creates the small JSON object that means there are no more pages of results. Tests use it to end a fake paginated backend response.

Data flow: It takes no input. It returns JSON with next_page_token set to null.

Call relations: The list-shares test uses this in mock responses for the final page of created plugins and for installed plugins. This tells the code under test to stop asking the fake backend for more pages.

Call graph: 1 external calls (json!).

fn expected_plugin_interface() -> PluginInterface

Purpose: Builds the Rust data structure that should result from parsing the fake plugin interface JSON. It gives the list test a clear expected value to compare against.

Data flow: It takes no input. It returns a PluginInterface with the demo display name, short description, capabilities, and all unrelated optional fields left empty.

Call relations: The list-shares test calls this while building its expected RemotePluginSummary values. It mirrors the interface fields produced by remote_plugin_json, so the assertion checks that JSON parsing preserved the important display information.

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

async fn save_remote_plugin_share_creates_workspace_plugin()

Purpose: Tests the happy path for sharing a local plugin for the first time. It proves that the code archives the plugin, uploads it, creates a remote workspace plugin, records the local path, and returns the new share details.

Data flow: The test creates temporary folders, writes a fake plugin, calculates the archive size, starts a fake server, and defines expected HTTP calls. It then calls save_remote_plugin_share with no existing remote plugin ID. The result should contain the new remote plugin ID and share URL, the local mapping file should be updated, and the uploaded archive body should contain the plugin manifest and skill file.

Call relations: This test ties together many helpers: write_test_plugin creates the local input, test_config and test_auth prepare the remote call setup, and archive_file_entries inspects the upload. It drives the production save_remote_plugin_share function through the same sequence a real first-time share would use.

Call graph: calls 5 internal fn (archive_file_entries, test_auth, test_config, write_test_plugin, try_from); 11 external calls (given, start, new, new, assert_eq!, json!, vec!, body_json, header, method (+1 more)).

fn archive_plugin_for_upload_rejects_archives_over_limit()

Purpose: Checks that the archive builder refuses to produce an archive when the compressed plugin package is larger than an allowed limit. This protects the upload flow from sending files that are too big.

Data flow: The test creates a fake plugin, adds a large extra file, and asks the archive builder to use a very small maximum size. The expected output is an ArchiveTooLarge error instead of archive bytes.

Call relations: It uses write_test_plugin and write_file to create the oversized input. Then it directly exercises archive_plugin_for_upload_with_limit, confirming the size guard that save flows rely on before upload.

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

fn archive_plugin_for_upload_places_manifest_at_archive_root()

Purpose: Checks that plugin archives have the right internal layout. In particular, the manifest must appear at .codex-plugin/plugin.json at the archive root, not nested under the temporary directory name.

Data flow: The test writes a fake plugin, creates an archive, reads the archive back into a path-to-bytes map, and compares the paths and contents against the expected manifest and skill file.

Call relations: It uses write_test_plugin to make the input and archive_file_entries to inspect the output. This directly tests archive_plugin_for_upload, whose output is later uploaded by the remote sharing flow.

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

fn archive_plugin_for_upload_round_trips_through_plugin_bundle_archive_with_long_paths()

Purpose: Checks that archives with very long file paths can still be unpacked by the plugin bundle extractor. This matters because some archive formats need special handling for long names.

Data flow: The test creates a fake plugin, adds a skill file deeply nested under many repeated path segments, archives the plugin, unpacks it into a new temporary directory, and reads the unpacked files back. The final checks confirm both the manifest and long-path skill survived unchanged.

Call relations: It uses write_test_plugin and write_file to create a challenging plugin folder. Then it sends the archive produced by archive_plugin_for_upload into unpack_plugin_bundle_tar_gz, proving that the sharing archive format works with the normal bundle unpacking code.

Call graph: calls 3 internal fn (unpack_plugin_bundle_tar_gz, write_file, write_test_plugin); 3 external calls (new, new, assert_eq!).

async fn save_remote_plugin_share_updates_existing_workspace_plugin()

Purpose: Tests updating an already shared workspace plugin. Instead of creating a new remote plugin, the code should upload a new archive and send it to the existing plugin ID.

Data flow: The test creates a fake plugin and fake server responses. It calls save_remote_plugin_share with an existing remote plugin ID. The expected result keeps the same remote plugin ID and has no new share URL, because this is an update rather than a new share creation.

Call relations: Like the create-share test, it uses write_test_plugin, test_config, and test_auth to set up the scenario. The mocked requests verify that save_remote_plugin_share includes the existing plugin ID when asking for an upload URL and posts the uploaded file to the existing plugin endpoint.

Call graph: calls 4 internal fn (test_auth, test_config, write_test_plugin, try_from); 10 external calls (given, start, new, new, assert_eq!, default, json!, body_json, method, path).

async fn update_remote_plugin_share_targets_updates_targets()

Purpose: Tests changing who can access a shared plugin. It verifies that users, groups, roles, and discoverability are sent to the backend in the expected shape and parsed back correctly.

Data flow: The test starts a fake server expecting a PUT request with two explicit share targets plus the workspace target. It calls update_remote_plugin_share_targets with user and group targets and an unlisted discoverability setting. The returned value should contain the principals and discoverability reported by the fake backend.

Call relations: It uses test_config and test_auth to route the request to the fake server with test credentials. It drives the production update_remote_plugin_share_targets function and checks both the outgoing request body and the returned Rust result.

Call graph: calls 2 internal fn (test_auth, test_config); 10 external calls (given, start, new, assert_eq!, json!, vec!, body_json, header, method, path).

async fn list_remote_plugin_shares_fetches_created_workspace_plugins()

Purpose: Tests listing plugins the user has created and shared in the workspace. It also checks pagination, installed status, share principals, share URLs, and saved local plugin paths.

Data flow: The test writes a local mapping for one plugin, sets up fake server responses for two pages of created plugins, and sets up another response for installed workspace plugins. It calls list_remote_plugin_shares. The returned list should include both shared plugins, mark one as installed and enabled, attach the local path to the mapped plugin, and preserve interface and sharing details.

Call relations: This is the broadest listing test. It uses write_plugin_share_local_path_mapping to simulate local bookkeeping, test_config and test_auth for backend access, remote_plugin_json_with_share_url_and_principals for created-plugin responses, installed_remote_plugin_json for installed status, empty_pagination_json to stop pagination, and expected_plugin_interface in the final assertion.

Call graph: calls 4 internal fn (test_auth, test_config, write_plugin_share_local_path_mapping, try_from); 11 external calls (given, start, new, new, assert_eq!, json!, header, method, path, query_param (+1 more)).

async fn delete_remote_plugin_share_deletes_workspace_plugin()

Purpose: Tests deleting a shared workspace plugin. It verifies that the backend delete call is made and that the local remote-ID-to-path mapping is removed afterward.

Data flow: The test creates a temporary Codex home, writes a saved local path mapping for a remote plugin ID, and prepares a fake server to accept a DELETE request. It calls delete_remote_plugin_share. Afterward, loading the local mapping should return an empty map.

Call relations: It uses write_plugin_share_local_path_mapping to set up existing local state, and test_config and test_auth to route the delete request through the fake server. It drives delete_remote_plugin_share and confirms that remote deletion and local cleanup happen together.

Call graph: calls 4 internal fn (test_auth, test_config, write_plugin_share_local_path_mapping, try_from); 8 external calls (given, start, new, new, assert_eq!, header, method, path).

fn plugins_manager_tracks_auth_mode()

Purpose: Checks that a plugin manager remembers the current authentication mode and reports whether changing it actually changed anything.

Data flow: It creates managers in temporary homes, reads their starting auth mode, sets several auth modes, and compares the reported values before and after. The result is only test assertions; no lasting files are kept.

Call relations: This is a standalone test. It calls the manager constructors and auth-mode methods directly to verify the basic state that later plugin-loading tests depend on.

Call graph: calls 2 internal fn (new, new_with_options); 3 external calls (new, assert!, assert_eq!).

fn write_auth_projection_plugin(codex_home: &Path, name: &str, include_app: bool)

Purpose: Creates a small fake plugin used by authentication-projection tests. The plugin always has an MCP server, and can optionally also declare an app connector.

Data flow: It receives a Codex home path, a plugin name, and a flag. It writes plugin manifest and MCP JSON files under the test plugin cache, and, if requested, asks the app helper to write an app declaration too.

Call relations: Several auth-projection tests call this helper before loading plugins. It delegates app creation to write_auth_projection_app so those tests can build matching or non-matching MCP/app combinations.

Call graph: calls 1 internal fn (write_auth_projection_app); called by 5 (plugin_auth_projection_hides_apps_without_chatgpt_auth, plugin_auth_projection_hides_dual_surface_mcp_with_agent_identity_apps_route, plugin_auth_projection_hides_matching_mcp_with_chatgpt_apps_route, plugin_auth_projection_keeps_non_conflicting_mcp_with_chatgpt_apps_route, plugin_auth_projection_reprojects_cached_plugins_when_auth_changes); 3 external calls (join, write_file, format!).

fn write_auth_projection_app(codex_home: &Path, plugin_name: &str, app_name: &str)

Purpose: Writes a fake app connector declaration for a test plugin.

Data flow: It receives the Codex home, plugin name, and app name. It writes a .app.json file that maps that app name to a connector id based on the plugin name.

Call relations: It is called both directly by one test and indirectly through write_auth_projection_plugin. The resulting file is later read by the real plugin loader.

Call graph: called by 2 (plugin_auth_projection_keeps_non_conflicting_mcp_with_chatgpt_apps_route, write_auth_projection_plugin); 3 external calls (join, write_file, format!).

fn app_declaration(name: &str, connector_id: &str) -> AppDeclaration

Purpose: Builds the AppDeclaration value expected in assertions.

Data flow: It takes an app name and connector id string, wraps them in the correct struct types, and leaves optional category information empty.

Call relations: Tests use this small builder when comparing loaded app declarations, so the expected values are easy to read.

async fn auth_projection_config(codex_home: &Path) -> PluginsConfigInput

Purpose: Creates the standard config used by tests that compare app and MCP visibility under different auth modes.

Data flow: It writes a config.toml with plugins enabled and two test plugins turned on, then loads that config into the form the plugin manager expects.

Call relations: The auth-projection tests call this after writing plugin files and before asking PluginsManager to load them.

Call graph: calls 1 internal fn (load_config); called by 5 (plugin_auth_projection_hides_apps_without_chatgpt_auth, plugin_auth_projection_hides_dual_surface_mcp_with_agent_identity_apps_route, plugin_auth_projection_hides_matching_mcp_with_chatgpt_apps_route, plugin_auth_projection_keeps_non_conflicting_mcp_with_chatgpt_apps_route, plugin_auth_projection_reprojects_cached_plugins_when_auth_changes); 2 external calls (join, write_file).

fn sorted_effective_mcp_server_names(outcome: &PluginLoadOutcome) -> Vec<String>

Purpose: Returns MCP server names from a load result in a stable order, so tests can compare them reliably.

Data flow: It reads the effective MCP server map from a PluginLoadOutcome, copies the keys, sorts them, and returns the sorted list.

Call relations: Auth-projection tests use this helper because maps do not promise a human-friendly order.

Call graph: calls 1 internal fn (effective_mcp_servers).

async fn plugin_auth_projection_hides_apps_without_chatgpt_auth()

Purpose: Verifies that app connectors are hidden when the manager is using API-key auth instead of ChatGPT-style auth.

Data flow: It creates two fake plugins, loads config, runs the manager with API-key auth, and checks that apps disappear while MCP servers remain visible.

Call relations: It relies on the auth projection helpers to build the fake plugin cache, then exercises plugins_for_config on the real manager.

Call graph: calls 3 internal fn (new_with_options, auth_projection_config, write_auth_projection_plugin); 3 external calls (new, assert!, assert_eq!).

async fn plugin_auth_projection_hides_matching_mcp_with_chatgpt_apps_route()

Purpose: Checks that with ChatGPT auth, a plugin app can replace an MCP server with the same declaration name.

Data flow: It writes one plugin with both an app and matching MCP server plus another MCP-only plugin. After loading, it expects the app connector to appear and the matching MCP server to be removed.

Call relations: This test continues the auth-projection story by proving the manager avoids showing duplicate routes to the same capability.

Call graph: calls 3 internal fn (new_with_options, auth_projection_config, write_auth_projection_plugin); 3 external calls (new, assert!, assert_eq!).

async fn plugin_auth_projection_hides_dual_surface_mcp_with_agent_identity_apps_route()

Purpose: Checks that Agent Identity auth behaves like ChatGPT auth for plugins that expose both app and MCP surfaces.

Data flow: It creates the same fake plugin setup as the ChatGPT route test, loads with Agent Identity auth, and expects the app to remain while the overlapping MCP server is hidden.

Call relations: It reuses the shared auth projection setup and calls the real manager to confirm another auth mode follows the same projection rule.

Call graph: calls 3 internal fn (new_with_options, auth_projection_config, write_auth_projection_plugin); 2 external calls (new, assert_eq!).

async fn plugin_auth_projection_keeps_non_conflicting_mcp_with_chatgpt_apps_route()

Purpose: Ensures ChatGPT auth does not hide an MCP server unless it conflicts with an app declaration name.

Data flow: It writes a plugin whose MCP server and app use different names, loads it with ChatGPT auth, and expects both the app connector and MCP server to remain.

Call relations: It uses both plugin-writing helpers to create a deliberately non-conflicting case for the projection logic.

Call graph: calls 4 internal fn (new_with_options, auth_projection_config, write_auth_projection_app, write_auth_projection_plugin); 2 external calls (new, assert_eq!).

async fn plugin_auth_projection_preserves_duplicate_connector_declaration_names()

Purpose: Checks that multiple app declarations pointing to the same connector are deduplicated without losing unrelated MCP servers.

Data flow: It writes one plugin with two app names sharing one connector id and three MCP servers. After loading with ChatGPT auth, it expects one connector id and only the non-overlapping MCP server.

Call relations: This test builds the files inline instead of using the helper because it needs duplicate app connector declarations.

Call graph: calls 2 internal fn (new_with_options, load_config); 3 external calls (new, assert_eq!, write_file).

async fn plugin_auth_projection_reprojects_cached_plugins_when_auth_changes()

Purpose: Verifies that changing auth mode updates the visible plugin capabilities even when the underlying loaded plugin data is cached.

Data flow: It loads plugins once with ChatGPT auth, checks apps are projected in, changes the manager to API-key auth, loads again, and checks the view switches to MCP-only.

Call relations: It combines the auth-mode state tested earlier with plugin caching behavior to ensure cached loads are reinterpreted for the current auth mode.

Call graph: calls 3 internal fn (new_with_options, auth_projection_config, write_auth_projection_plugin); 3 external calls (new, assert!, assert_eq!).

fn write_plugin_with_version(
    root: &Path,
    dir_name: &str,
    manifest_name: &str,
    manifest_version: Option<&str>,
)

Purpose: Creates a minimal fake plugin folder, optionally with a version in its manifest.

Data flow: It receives a root path, directory name, manifest name, and optional version. It creates manifest and skills folders, writes plugin.json, a sample skill file, and an empty MCP config.

Call relations: Many installation and cache-refresh tests use this as their basic fake plugin factory. write_plugin is its simpler wrapper.

Call graph: called by 8 (install_plugin_uses_manifest_version_for_non_curated_plugins, refresh_non_curated_plugin_cache_ignores_invalid_unconfigured_plugin_versions, refresh_non_curated_plugin_cache_refreshes_configured_git_source, refresh_non_curated_plugin_cache_reinstalls_missing_configured_plugin_with_manifest_version, refresh_non_curated_plugin_cache_replaces_existing_local_version_with_manifest_version, refresh_non_curated_plugin_cache_returns_false_when_configured_plugins_are_current, write_cached_plugin, write_plugin); 4 external calls (join, format!, create_dir_all, write).

fn write_plugin(root: &Path, dir_name: &str, manifest_name: &str)

Purpose: Creates a minimal fake plugin without specifying a manifest version.

Data flow: It passes the root, directory name, and manifest name to write_plugin_with_version with no version value.

Call relations: Tests call this when version details are not important, while still getting the same standard plugin layout.

Call graph: calls 1 internal fn (write_plugin_with_version); called by 13 (install_plugin_supports_git_subdir_marketplace_sources, install_plugin_supports_relative_git_subdir_marketplace_sources, install_plugin_updates_config_with_relative_path_and_plugin_key, list_marketplaces_includes_enabled_state, plugin_cache_ignores_unrelated_session_overrides, plugin_hooks_for_layer_stack_loads_configured_plugin_hooks, refresh_curated_plugin_cache_migrates_full_sha_cache_version_to_short_version, refresh_curated_plugin_cache_removes_cache_for_plugin_removed_from_marketplace, refresh_curated_plugin_cache_replaces_existing_local_version_with_short_sha_version, refresh_curated_plugin_cache_returns_false_when_configured_plugins_are_current (+3 more)).

fn init_git_repo(repo: &Path)

Purpose: Turns a test directory into a small Git repository so tests can exercise Git-based plugin sources.

Data flow: It runs git init, configures a test author, stages files, and creates an initial commit.

Call relations: Git-subdir installation and refresh tests call this before asking the plugin manager to copy from a repository source.

Call graph: calls 1 internal fn (run_git); called by 3 (install_plugin_supports_git_subdir_marketplace_sources, install_plugin_supports_relative_git_subdir_marketplace_sources, refresh_non_curated_plugin_cache_refreshes_configured_git_source).

fn run_git(repo: &Path, args: &[&str])

Purpose: Runs a Git command in a test repository and fails the test with useful output if Git fails.

Data flow: It receives a repository path and argument list, starts the git process, captures output, and asserts success.

Call relations: init_git_repo uses this for each Git step, keeping command failure messages readable.

Call graph: called by 1 (init_git_repo); 2 external calls (assert!, new).

fn plugin_config_toml(enabled: bool, plugins_feature_enabled: bool) -> String

Purpose: Builds a simple config.toml string for tests with one plugin and a plugins feature flag.

Data flow: It receives whether the plugin is enabled and whether the plugin feature is enabled, constructs a TOML table, and serializes it to text.

Call relations: Many load tests call this so they can focus on plugin files instead of repeating config boilerplate.

Call graph: called by 12 (capability_summary_sanitizes_plugin_descriptions_to_one_line, capability_summary_truncates_overlong_plugin_descriptions, effective_apps_preserves_app_config_order, load_plugins_ignores_invalid_manifest_skills_shape, load_plugins_ignores_manifest_component_paths_without_dot_slash, load_plugins_ignores_project_config_files, load_plugins_loads_default_skills_and_mcp_servers, load_plugins_preserves_disabled_plugins_without_effective_contributions, load_plugins_returns_empty_when_feature_disabled, load_plugins_uses_manifest_configured_component_paths (+2 more)); 4 external calls (Boolean, Table, new, to_string).

async fn load_plugins_from_config(
    config_toml: &str,
    codex_home: &Path,
    auth_mode: Option<AuthMode>,
) -> PluginLoadOutcome

Purpose: Writes a config string, loads it, and returns the plugin manager’s load outcome.

Data flow: It writes config.toml into the temporary Codex home, loads the config, creates a manager with the requested auth mode, and awaits plugins_for_config.

Call relations: Most plugin-loading tests use this helper as the standard path from fake config to PluginLoadOutcome.

Call graph: calls 2 internal fn (new_with_options, load_config); called by 13 (capability_summary_sanitizes_plugin_descriptions_to_one_line, capability_summary_truncates_overlong_plugin_descriptions, effective_apps_dedupes_connector_ids_across_plugins, effective_apps_preserves_app_config_order, load_plugins_applies_plugin_mcp_server_policy, load_plugins_ignores_invalid_manifest_skills_shape, load_plugins_ignores_manifest_component_paths_without_dot_slash, load_plugins_ignores_unknown_disabled_skill_names, load_plugins_loads_default_skills_and_mcp_servers, load_plugins_preserves_disabled_plugins_without_effective_contributions (+3 more)); 3 external calls (join, to_path_buf, write_file).

async fn load_config(codex_home: &Path, cwd: &Path) -> PluginsConfigInput

Purpose: Loads plugin-related configuration for tests through the project’s normal config-loading helper.

Data flow: It receives a Codex home and current working directory, passes them to test support config loading, and returns the parsed plugin config input.

Call relations: Marketplace, remote, read, and load tests call this before invoking manager methods that need configuration.

Call graph: called by 32 (auth_projection_config, featured_plugin_ids_for_config_defaults_query_param_to_codex, featured_plugin_ids_for_config_uses_restriction_product_query_param, list_marketplaces_can_skip_openai_curated_before_loading, list_marketplaces_excludes_plugins_with_explicit_empty_products, list_marketplaces_ignores_installed_roots_missing_from_config, list_marketplaces_includes_curated_repo_marketplace, list_marketplaces_includes_enabled_state, list_marketplaces_includes_installed_marketplace_roots, list_marketplaces_installed_git_source_reads_metadata_from_cache_without_cloning (+15 more)); 1 external calls (load_plugins_config).

fn remote_installed_linear_plugin() -> RemoteInstalledPlugin

Purpose: Creates a standard fake remote-installed plugin named linear.

Data flow: It supplies the name linear to the general remote plugin builder and returns the resulting remote plugin record.

Call relations: Remote marketplace metadata tests use this as a readable shortcut.

Call graph: calls 1 internal fn (remote_installed_plugin); called by 1 (build_remote_installed_plugin_marketplaces_from_cache_uses_remote_metadata).

fn remote_installed_plugin(name: &str) -> RemoteInstalledPlugin

Purpose: Creates a fake remote-installed plugin in the default global remote marketplace.

Data flow: It receives a plugin name and passes it with the global marketplace name to the marketplace-specific builder.

Call relations: Remote cache tests use this when they do not care about workspace-specific marketplace names.

Call graph: calls 1 internal fn (remote_installed_plugin_in_marketplace); called by 1 (remote_installed_linear_plugin).

fn remote_installed_plugin_in_marketplace(
    name: &str,
    marketplace_name: &str,
) -> RemoteInstalledPlugin

Purpose: Builds a fake remote-installed plugin record for a named remote marketplace.

Data flow: It receives a plugin name and marketplace name, fills in id, enabled state, policies, availability, and empty optional metadata, then returns the record.

Call relations: The two higher-level remote plugin helpers delegate to this, and marketplace-filtering tests call it directly for non-global marketplaces.

Call graph: called by 1 (remote_installed_plugin); 2 external calls (new, format!).

fn write_cached_plugin(codex_home: &Path, marketplace_name: &str, plugin_name: &str)

Purpose: Places a fake installed plugin into the plugin cache under a given marketplace and plugin name.

Data flow: It builds the cache path and writes a versioned fake plugin whose manifest version is local.

Call relations: Remote curated conflict and curated cache tests use this to simulate already-installed plugins.

Call graph: calls 1 internal fn (write_plugin_with_version); called by 3 (refresh_curated_plugin_cache_leaves_api_curated_plugin_when_api_manifest_missing, remote_installed_cache_prefers_local_curated_conflicts_when_remote_plugin_disabled, remote_installed_cache_prefers_remote_curated_conflicts_when_remote_plugin_enabled); 1 external calls (join).

async fn load_plugins_loads_default_skills_and_mcp_servers()

Purpose: Checks that a normal enabled plugin contributes its manifest, skills, MCP server, app, and capability summary.

Data flow: It writes a realistic plugin with manifest, skill, MCP config, and app config, loads it, and compares the full LoadedPlugin plus effective capability views.

Call relations: This is the baseline loading test that proves the standard file layout is recognized by load_plugins_from_config.

Call graph: calls 2 internal fn (load_plugins_from_config, plugin_config_toml); 3 external calls (new, assert_eq!, write_file).

async fn load_plugins_applies_plugin_mcp_server_policy()

Purpose: Verifies that user config can override MCP server settings declared by a plugin.

Data flow: It writes a plugin MCP server with default tool settings, writes config overrides that disable the server and adjust tool approval settings, loads the plugin, and checks the merged server config.

Call relations: It exercises the manager’s policy-application path after load_plugins_from_config reads both plugin files and config.

Call graph: calls 1 internal fn (load_plugins_from_config); 4 external calls (new, assert!, assert_eq!, write_file).

async fn remote_installed_cache_ignores_plugins_missing_local_cache()

Purpose: Checks that a remote-installed plugin record alone is not enough to load a plugin if its local cached files are missing.

Data flow: It enables remote plugins, writes a remote installed cache entry, but does not create plugin files. The expected load result is empty.

Call relations: It calls the manager’s remote installed cache writer, then plugins_for_config, proving local cache material is required.

Call graph: calls 2 internal fn (new, load_config); 4 external calls (new, assert_eq!, write_file, vec!).

async fn remote_installed_cache_prefers_local_curated_conflicts_when_remote_plugin_disabled()

Purpose: Ensures local curated plugins win name conflicts when the remote plugin feature is disabled.

Data flow: It creates local curated and remote-curated cache folders with overlapping names, disables remote plugins, and checks which config names are loaded.

Call relations: It combines cached plugin setup, remote installed cache records, and manager loading to test conflict resolution.

Call graph: calls 3 internal fn (new, load_config, write_cached_plugin); 4 external calls (new, assert_eq!, write_file, vec!).

async fn remote_installed_cache_prefers_remote_curated_conflicts_when_remote_plugin_enabled()

Purpose: Ensures remote curated plugins win name conflicts when the remote plugin feature is enabled.

Data flow: It creates overlapping local curated, API curated, and remote-curated cached plugins, enables remote plugins, and checks that the remote curated version is chosen for conflicts.

Call relations: It mirrors the disabled-remote test but flips the feature flag to verify the opposite preference.

Call graph: calls 3 internal fn (new, load_config, write_cached_plugin); 4 external calls (new, assert_eq!, write_file, vec!).

async fn build_remote_installed_plugin_marketplaces_from_cache_uses_remote_metadata()

Purpose: Checks that remote-installed plugin cache entries become marketplace entries with their remote metadata intact.

Data flow: It writes a remote cache entry with install policy, auth policy, keywords, and interface details, then builds marketplaces from the cache and compares the resulting plugin fields.

Call relations: This directly tests the manager’s cache-to-marketplace conversion without loading plugin files.

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

async fn build_remote_installed_plugin_marketplaces_from_cache_filters_by_marketplace_name()

Purpose: Verifies that remote marketplace building only includes requested remote marketplace names.

Data flow: It writes remote installed cache entries for two workspace-related marketplaces, requests one marketplace, and checks that only its plugin appears.

Call relations: It uses remote_installed_plugin_in_marketplace data and the manager’s remote cache marketplace builder.

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

async fn load_plugins_resolves_disabled_skill_names_against_loaded_plugin_skills()

Purpose: Checks that a user can disable a plugin skill by its plugin-qualified skill name.

Data flow: It writes one skill, configures that skill as disabled, loads the plugin, canonicalizes the skill path, and expects it in disabled_skill_paths with no enabled skills left.

Call relations: It tests the bridge between config skill rules and the actual skill files discovered during plugin loading.

Call graph: calls 1 internal fn (load_plugins_from_config); 5 external calls (new, assert!, assert_eq!, write_file, canonicalize).

async fn load_plugins_ignores_unknown_disabled_skill_names()

Purpose: Ensures disabling a non-existent skill does not accidentally disable real skills.

Data flow: It writes one skill, configures a different missing skill as disabled, loads the plugin, and expects the real skill to remain enabled.

Call relations: It complements the previous disabled-skill test by proving unmatched config rules are harmless.

Call graph: calls 1 internal fn (load_plugins_from_config); 4 external calls (new, assert!, assert_eq!, write_file).

async fn plugin_telemetry_metadata_uses_default_mcp_config_path()

Purpose: Verifies telemetry metadata can find a plugin’s default .mcp.json file.

Data flow: It writes a plugin manifest and MCP config, asks for telemetry metadata from the plugin root, and checks the generated capability summary.

Call relations: It calls plugin_telemetry_metadata_from_root directly instead of going through the whole manager load path.

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

async fn capability_summary_sanitizes_plugin_descriptions_to_one_line()

Purpose: Checks that capability summaries clean plugin descriptions for display without changing the raw manifest description.

Data flow: It writes a manifest description with newlines, multiple spaces, and a tab, loads the plugin, and expects the summary description to be a single normalized line.

Call relations: It uses the standard load helper and verifies summary formatting in PluginLoadOutcome.

Call graph: calls 2 internal fn (load_plugins_from_config, plugin_config_toml); 3 external calls (new, assert_eq!, write_file).

async fn capability_summary_truncates_overlong_plugin_descriptions()

Purpose: Checks that very long plugin descriptions are shortened in capability summaries.

Data flow: It writes a description one character longer than the maximum, loads the plugin, and expects the raw manifest to stay long while the summary is truncated.

Call relations: It protects the user-facing capability index from oversized plugin metadata.

Call graph: calls 2 internal fn (load_plugins_from_config, plugin_config_toml); 4 external calls (new, assert_eq!, write_file, format!).

async fn load_plugins_uses_manifest_configured_component_paths()

Purpose: Verifies that manifest paths beginning with ./ can override default locations for skills, MCP servers, and apps.

Data flow: It writes both default and custom component files, points the manifest to custom paths, loads the plugin, and expects custom components to be used.

Call relations: It tests how the loader interprets component path fields in plugin.json.

Call graph: calls 2 internal fn (load_plugins_from_config, plugin_config_toml); 3 external calls (new, assert_eq!, write_file).

async fn load_plugins_ignores_manifest_component_paths_without_dot_slash()

Purpose: Ensures manifest component paths are ignored unless they explicitly start with ./.

Data flow: It writes custom paths without the required prefix, plus default component files, loads the plugin, and expects the defaults to be used.

Call relations: It complements the custom-path test by enforcing the safe relative-path rule.

Call graph: calls 2 internal fn (load_plugins_from_config, plugin_config_toml); 3 external calls (new, assert_eq!, write_file).

async fn load_plugins_ignores_invalid_manifest_skills_shape()

Purpose: Checks that an invalid skills field shape in plugin.json does not break plugin loading.

Data flow: It writes a manifest where skills is an array instead of the expected string, loads the plugin, and expects no error and the default skills folder.

Call relations: It tests loader resilience against malformed optional manifest fields.

Call graph: calls 2 internal fn (load_plugins_from_config, plugin_config_toml); 3 external calls (new, assert_eq!, write_file).

async fn load_plugins_preserves_disabled_plugins_without_effective_contributions()

Purpose: Verifies that disabled configured plugins are still reported but do not contribute skills, MCP servers, or apps.

Data flow: It writes a plugin with an MCP server, configures it as disabled, loads it, and checks that the LoadedPlugin exists with enabled false and empty capability lists.

Call relations: It tests the distinction between configured plugin records and effective capabilities.

Call graph: calls 2 internal fn (load_plugins_from_config, plugin_config_toml); 4 external calls (new, assert!, assert_eq!, write_file).

async fn effective_apps_dedupes_connector_ids_across_plugins()

Purpose: Checks that effective app connector ids are unique even when multiple plugins declare the same connector.

Data flow: It writes two plugins with overlapping app connector ids, enables both, loads with ChatGPT auth, and expects each connector id once.

Call relations: It exercises PluginLoadOutcome’s effective app projection across multiple loaded plugins.

Call graph: calls 1 internal fn (load_plugins_from_config); 7 external calls (new, Boolean, Table, assert_eq!, write_file, new, to_string).

async fn effective_apps_preserves_app_config_order()

Purpose: Ensures app connector ids keep their declaration order while duplicates are removed.

Data flow: It writes one app config with Slack, GitHub, then a duplicate Slack entry, loads it, and expects Slack followed by GitHub.

Call relations: It focuses on ordering behavior in the same effective app list tested for deduplication.

Call graph: calls 2 internal fn (load_plugins_from_config, plugin_config_toml); 3 external calls (new, assert_eq!, write_file).

fn capability_index_filters_inactive_and_zero_capability_plugins()

Purpose: Checks that capability summaries only include active plugins with at least one useful capability.

Data flow: It constructs LoadedPlugin values directly with different combinations of skills, MCP servers, apps, disabled state, and errors, then asks PluginLoadOutcome to summarize them.

Call relations: Unlike file-based load tests, this directly tests summary creation from in-memory loaded plugins.

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

async fn load_plugins_returns_empty_when_feature_disabled()

Purpose: Verifies that the global plugins feature flag turns plugin loading off entirely.

Data flow: It writes a valid plugin and config with the plugin enabled but features.plugins set false, loads through the manager, and expects the default empty outcome.

Call relations: It confirms the manager checks the feature flag before using cached plugin files.

Call graph: calls 3 internal fn (new, load_config, plugin_config_toml); 3 external calls (new, assert_eq!, write_file).

async fn plugin_cache_ignores_unrelated_session_overrides()

Purpose: Checks that plugin load caching is not invalidated by unrelated session settings like model choice.

Data flow: It loads a plugin with one session override, deletes the MCP file, loads again with a different model override, and expects the second result to come from cache.

Call relations: It builds a custom config layer stack to make sure only plugin-relevant config affects the cache key.

Call graph: calls 3 internal fn (new, plugin_config_toml, write_plugin); 5 external calls (new, assert_eq!, write_file, remove_file, from_str).

fn loaded_plugins_cache_invalidation_rejects_stale_load_completion()

Purpose: Ensures an old asynchronous plugin load cannot write stale data into the cache after the cache was cleared.

Data flow: It records a cache generation, clears the cache to advance the generation, tries to cache data using the stale generation, and confirms no cached data appears.

Call relations: It tests the manager’s generation guard directly, without file I/O.

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

async fn load_plugins_rejects_invalid_plugin_keys()

Purpose: Verifies that plugin config keys must use the form plugin@marketplace.

Data flow: It writes config with an invalid key, loads plugins, and expects a LoadedPlugin entry containing a clear error and no effective capabilities.

Call relations: It tests validation at the boundary between user config and plugin loading.

Call graph: calls 1 internal fn (load_plugins_from_config); 8 external calls (new, Boolean, Table, assert!, assert_eq!, write_file, new, to_string).

async fn install_plugin_updates_config_with_relative_path_and_plugin_key()

Purpose: Checks that installing a local marketplace plugin copies it into cache and enables the correct plugin key in config.

Data flow: It creates a fake marketplace and plugin, calls install_plugin, compares the install outcome, then reads config.toml to ensure the plugin was enabled.

Call relations: This begins the install tests by exercising the normal local-source install path.

Call graph: calls 3 internal fn (new, write_plugin, try_from); 6 external calls (assert!, assert_eq!, create_dir_all, read_to_string, write, tempdir).

async fn install_openai_curated_plugin_uses_short_sha_cache_version()

Purpose: Ensures OpenAI curated plugin installs use the short curated repository SHA as the cache version.

Data flow: It writes a curated marketplace and SHA file, installs a curated plugin, and expects the installed path and reported version to use the short cache version.

Call relations: It tests the special versioning rule for curated plugins.

Call graph: calls 3 internal fn (new, curated_plugins_repo_path, try_from); 5 external calls (assert_eq!, write_curated_plugin_sha_with, write_openai_curated_marketplace, format!, tempdir).

async fn install_plugin_uses_manifest_version_for_non_curated_plugins()

Purpose: Verifies non-curated plugins use their manifest version as the cache version.

Data flow: It writes a plugin manifest with version 1.2.3-beta+7, installs it from a local marketplace, and checks that version appears in the outcome and cache path.

Call relations: It contrasts with curated install behavior by testing marketplace plugins outside the OpenAI curated set.

Call graph: calls 3 internal fn (new, write_plugin_with_version, try_from); 4 external calls (assert_eq!, create_dir_all, write, tempdir).

async fn install_plugin_supports_git_subdir_marketplace_sources()

Purpose: Checks that a marketplace can install a plugin from a subdirectory of a Git repository.

Data flow: It creates a committed Git repo containing a plugin, writes marketplace metadata pointing to that repo and subdir, installs the plugin, and verifies files landed in cache.

Call relations: It uses init_git_repo to prepare a real Git source for install_plugin.

Call graph: calls 4 internal fn (new, init_git_repo, write_plugin, try_from); 7 external calls (assert!, assert_eq!, format!, create_dir_all, write, tempdir, from_directory_path).

async fn install_plugin_supports_relative_git_subdir_marketplace_sources()

Purpose: Checks that Git subdirectory sources can use URLs relative to the marketplace file.

Data flow: It creates a marketplace repo with a nested remote plugin repo, writes a relative Git URL, installs the plugin, and verifies the cached manifest exists.

Call relations: It extends the Git-subdir install test to cover relative source paths.

Call graph: calls 4 internal fn (new, init_git_repo, write_plugin, try_from); 5 external calls (assert!, assert_eq!, create_dir_all, write, tempdir).

async fn uninstall_plugin_removes_cache_and_config_entry()

Purpose: Verifies uninstalling a plugin removes its cached files and deletes its config entry, even if called twice.

Data flow: It writes a cached plugin and enabled config entry, calls uninstall_plugin twice, then checks the cache folder is gone and config no longer contains the plugin table.

Call relations: It tests cleanup behavior and idempotency for the manager’s uninstall path.

Call graph: calls 2 internal fn (new, write_plugin); 4 external calls (assert!, write_file, read_to_string, tempdir).

async fn list_marketplaces_includes_enabled_state()

Purpose: Checks marketplace listing reports whether installed plugins are enabled or disabled in config.

Data flow: It creates a marketplace with two plugins, caches both, configures one enabled and one disabled, lists marketplaces, and compares the full marketplace entry.

Call relations: It exercises list_marketplaces_for_config using loaded config and fake installed plugins.

Call graph: calls 4 internal fn (new, load_config, write_plugin, try_from); 5 external calls (assert_eq!, write_file, create_dir_all, write, tempdir).

async fn list_marketplaces_returns_empty_when_feature_disabled()

Purpose: Verifies marketplace listing is empty when the plugins feature is disabled.

Data flow: It writes a marketplace and config with features.plugins false, lists marketplaces, and expects an empty list.

Call relations: It confirms the same global feature switch used by plugin loading also gates marketplace listing.

Call graph: calls 3 internal fn (new, load_config, try_from); 5 external calls (assert_eq!, write_file, create_dir_all, write, tempdir).

async fn list_marketplaces_excludes_plugins_with_explicit_empty_products()

Purpose: Ensures marketplace plugins explicitly restricted to no products are not shown.

Data flow: It writes a marketplace with one plugin whose products list is empty and one normal plugin, lists marketplaces, and expects only the normal plugin.

Call relations: It tests product filtering in marketplace presentation.

Call graph: calls 3 internal fn (new, load_config, try_from); 5 external calls (assert_eq!, write_file, create_dir_all, write, tempdir).

async fn read_plugin_for_config_returns_plugins_disabled_when_feature_disabled()

Purpose: Checks that reading one plugin’s details fails with a clear PluginsDisabled error when the feature is off.

Data flow: It writes a marketplace and disabled global feature config, calls read_plugin_for_config, and asserts the returned error kind.

Call relations: It tests the single-plugin details endpoint’s feature-gate behavior.

Call graph: calls 3 internal fn (new, load_config, try_from); 5 external calls (assert!, write_file, create_dir_all, write, tempdir).

async fn read_plugin_for_config_filters_mcp_servers_for_codex_backend_auth()

Purpose: Verifies plugin detail reading uses the same auth-based app/MCP projection as plugin loading.

Data flow: It writes a plugin with one app and two MCP servers, reads details once with ChatGPT auth and once with API-key auth, and compares visible apps and MCP server names.

Call relations: It applies the earlier auth-projection behavior to read_plugin_for_config instead of plugins_for_config.

Call graph: calls 3 internal fn (new_with_options, load_config, try_from); 5 external calls (assert!, assert_eq!, write_file, create_dir_all, tempdir).

async fn read_plugin_for_config_uses_user_layer_skill_settings_only()

Purpose: Checks that reading marketplace plugin details ignores project-level skill disable rules.

Data flow: It writes a user config enabling a plugin and a project config disabling its skill, reads plugin details, and expects no disabled skill paths.

Call relations: It protects plugin detail views from being affected by project config layers that should not apply there.

Call graph: calls 3 internal fn (new, load_config, try_from); 4 external calls (assert!, write_file, create_dir_all, tempdir).

async fn read_plugin_for_config_uninstalled_git_source_requires_install_without_cloning()

Purpose: Ensures reading an uninstalled Git-source plugin does not clone it just to show details.

Data flow: It writes a marketplace pointing to a missing Git repo, reads the plugin, and expects an install-required reason, a helpful description, no capabilities, and no staging folder.

Call relations: It tests a safe, no-network/no-clone path for unavailable remote source details.

Call graph: calls 3 internal fn (new, load_config, try_from); 7 external calls (assert!, assert_eq!, write_file, format!, create_dir_all, tempdir, from_directory_path).

async fn read_plugin_for_config_installed_git_source_reads_from_cache_without_cloning()

Purpose: Checks that an installed Git-source plugin’s details come from the cached copy, not from cloning the source again.

Data flow: It writes a marketplace pointing to a missing repo but also writes a cached plugin with manifest, skill, apps, MCP, and hooks. Reading details should return cached metadata and leave no staging folder.

Call relations: It complements the uninstalled Git-source test by proving cache is enough when present.

Call graph: calls 3 internal fn (new, load_config, try_from); 7 external calls (assert!, assert_eq!, write_file, format!, create_dir_all, tempdir, from_directory_path).

async fn list_marketplaces_installed_git_source_reads_metadata_from_cache_without_cloning()

Purpose: Verifies marketplace listing enriches an installed Git-source plugin with manifest interface metadata from cache.

Data flow: It writes a Git-source marketplace whose remote is missing, creates a cached manifest with interface assets, lists marketplaces, and expects cached metadata and absolute asset paths.

Call relations: It tests list_marketplaces_for_config’s cache metadata path for installed Git plugins.

Call graph: calls 3 internal fn (new, load_config, try_from); 7 external calls (assert!, assert_eq!, write_file, format!, create_dir_all, tempdir, from_directory_path).

async fn list_marketplaces_includes_curated_repo_marketplace()

Purpose: Checks that the OpenAI curated marketplace repository is included when requested.

Data flow: It writes a curated marketplace file and plugin manifest under the curated repo path, lists marketplaces with curated inclusion enabled, and compares the resulting marketplace.

Call relations: It exercises the built-in curated marketplace discovery path.

Call graph: calls 3 internal fn (new, load_config, curated_plugins_repo_path); 5 external calls (assert_eq!, write_file, create_dir_all, write, tempdir).

async fn list_marketplaces_can_skip_openai_curated_before_loading()

Purpose: Ensures callers can skip loading OpenAI curated marketplace files entirely.

Data flow: It writes an invalid curated marketplace file, calls listing with include_openai_curated false, and expects no errors and no curated marketplace entry.

Call relations: It proves the skip flag prevents even malformed curated files from affecting marketplace listing.

Call graph: calls 3 internal fn (new, load_config, curated_plugins_repo_path); 3 external calls (assert_eq!, write_file, tempdir).

async fn list_marketplaces_uses_api_curated_manifest_when_selected()

Purpose: Checks that API-key-style auth selects the API curated marketplace manifest instead of the normal curated manifest.

Data flow: It writes both curated manifest files, sets auth mode to API key, lists marketplaces, and expects the API curated marketplace and plugin.

Call relations: It links manager auth mode to curated marketplace selection.

Call graph: calls 3 internal fn (new, load_config, curated_plugins_repo_path); 3 external calls (assert_eq!, write_file, tempdir).

async fn list_marketplaces_skips_missing_api_curated_manifest()

Purpose: Ensures missing API curated marketplace files are skipped without reporting errors for API-like auth modes.

Data flow: It writes only a malformed normal curated manifest, sets API-related auth, lists marketplaces, and expects no API curated entry and no errors.

Call relations: It tests graceful behavior when the auth-selected curated manifest is absent.

Call graph: calls 3 internal fn (new, load_config, curated_plugins_repo_path); 3 external calls (assert_eq!, write_file, tempdir).

async fn list_marketplaces_includes_installed_marketplace_roots()

Purpose: Checks that marketplaces installed into the user’s marketplace root are listed when also recorded in config.

Data flow: It writes config metadata for an installed marketplace, creates its marketplace file and plugin, lists marketplaces, and verifies the installed root appears.

Call relations: It tests discovery of marketplace roots outside the current repository.

Call graph: calls 3 internal fn (marketplace_install_root, new, load_config); 5 external calls (assert_eq!, write_file, create_dir_all, write, tempdir).

async fn list_marketplaces_uses_config_when_known_registry_is_malformed()

Purpose: Verifies configured installed marketplaces are still discovered even if the known-marketplaces registry file is malformed.

Data flow: It writes valid marketplace config and files plus an invalid known_marketplaces.json, lists marketplaces, and expects the configured marketplace plugin.

Call relations: It protects marketplace discovery from an unrelated broken registry cache.

Call graph: calls 3 internal fn (marketplace_install_root, new, load_config); 5 external calls (assert_eq!, write_file, create_dir_all, write, tempdir).

async fn list_marketplaces_ignores_installed_roots_missing_from_config()

Purpose: Ensures installed marketplace folders are not listed unless the user config knows about them.

Data flow: It creates an installed marketplace folder but no matching config entry, lists marketplaces, and asserts that root is absent.

Call relations: It complements the installed-root inclusion test by confirming config is required.

Call graph: calls 3 internal fn (marketplace_install_root, new, load_config); 5 external calls (assert!, write_file, create_dir_all, write, tempdir).

async fn list_marketplaces_uses_first_duplicate_plugin_entry()

Purpose: Checks that duplicate plugin names across marketplaces are resolved by keeping the first discovered entry.

Data flow: It creates two repository marketplaces with the same marketplace name and a duplicate plugin, lists both roots, and expects only the first duplicate plus the unique second plugin.

Call relations: It tests duplicate filtering across the marketplace list produced by list_marketplaces_for_config.

Call graph: calls 3 internal fn (new, load_config, try_from); 5 external calls (assert_eq!, write_file, create_dir_all, write, tempdir).

async fn list_marketplaces_marks_configured_plugin_uninstalled_when_cache_is_missing()

Purpose: Verifies an enabled plugin in config is shown as enabled but not installed if its cache folder is missing.

Data flow: It writes marketplace metadata and config enabling a plugin, does not create cache files, lists marketplaces, and expects installed false with enabled true.

Call relations: It checks marketplace UI state when config and local cache disagree.

Call graph: calls 3 internal fn (new, load_config, try_from); 5 external calls (assert_eq!, write_file, create_dir_all, write, tempdir).

async fn featured_plugin_ids_for_config_uses_restriction_product_query_param()

Purpose: Checks that featured plugin lookup sends the manager’s product restriction as a platform query parameter.

Data flow: It starts a mock server expecting platform=chat and auth headers, points config at it, calls featured_plugin_ids_for_config, and expects the returned plugin id.

Call relations: It tests the network-facing featured-plugin helper with Product::Chatgpt.

Call graph: calls 3 internal fn (new_with_options, load_config, create_dummy_chatgpt_auth_for_testing); 11 external calls (given, start, new, assert_eq!, write_file, format!, tempdir, header, method, path (+1 more)).

async fn featured_plugin_ids_for_config_defaults_query_param_to_codex()

Purpose: Verifies featured plugin lookup defaults its platform query to codex when no product restriction is set.

Data flow: It starts a mock server expecting platform=codex, calls featured_plugin_ids_for_config without auth, and checks the returned id.

Call relations: It complements the product-restriction test by covering the default path.

Call graph: calls 2 internal fn (new_with_options, load_config); 10 external calls (given, start, new, assert_eq!, write_file, format!, tempdir, method, path, query_param).

async fn remote_plugin_caches_refresh_warms_recommended_plugins_cache()

Purpose: Checks that starting a remote plugin cache refresh also warms the recommended plugins cache in the background.

Data flow: It starts a mock suggested-plugins endpoint, calls maybe_start_remote_plugin_caches_refresh, waits until the cache is populated, then verifies cached and direct recommended modes match and can be cleared.

Call relations: It exercises asynchronous background refresh behavior on an Arc-wrapped PluginsManager.

Call graph: calls 3 internal fn (new, load_config, create_dummy_chatgpt_auth_for_testing); 15 external calls (from_millis, from_secs, given, start, new, assert_eq!, write_file, json!, new, tempdir (+5 more)).

async fn recommended_plugins_mode_deduplicates_concurrent_cache_misses()

Purpose: Ensures two simultaneous recommended-plugin requests share one network fetch.

Data flow: It sets up a delayed mock endpoint expected once, launches two concurrent requests, and checks both receive the same sorted endpoint result. A later request should come from cache.

Call relations: It tests cache miss deduplication for recommended_plugins_mode_for_config.

Call graph: calls 3 internal fn (new, load_config, create_dummy_chatgpt_auth_for_testing); 14 external calls (from_millis, given, start, new, assert_eq!, write_file, json!, tempdir, join!, vec! (+4 more)).

async fn recommended_plugins_mode_caches_explicit_false()

Purpose: Checks that an endpoint response saying recommendations are disabled is cached as legacy mode.

Data flow: It mock-returns enabled false, calls recommended_plugins_mode_for_config twice, and expects Legacy both times with only one endpoint expectation.

Call relations: It tests caching of a valid negative response.

Call graph: calls 3 internal fn (new, load_config, create_dummy_chatgpt_auth_for_testing); 9 external calls (given, start, new, assert_eq!, write_file, json!, tempdir, method, path).

async fn recommended_plugins_mode_retries_after_fetch_failure()

Purpose: Verifies a failed recommended-plugin fetch does not poison the cache forever.

Data flow: It first mock-returns a server error and expects Legacy, then replaces the mock with a successful response and expects Endpoint mode on the next call.

Call relations: It tests retry behavior after network failure.

Call graph: calls 3 internal fn (new, load_config, create_dummy_chatgpt_auth_for_testing); 9 external calls (given, start, new, assert_eq!, write_file, json!, tempdir, method, path).

fn refresh_curated_plugin_cache_replaces_existing_local_version_with_short_sha_version()

Purpose: Checks curated cache refresh replaces an old local cache version with the current short SHA version.

Data flow: It writes a curated marketplace, SHA file, and old local cached plugin, refreshes the cache, then checks the old folder is gone and the short-SHA folder exists.

Call relations: It directly tests refresh_curated_plugin_cache for an outdated installed curated plugin.

Call graph: calls 3 internal fn (write_plugin, curated_plugins_repo_path, new); 4 external calls (assert!, write_curated_plugin_sha_with, write_openai_curated_marketplace, tempdir).

fn refresh_curated_plugin_cache_reinstalls_missing_configured_plugin_with_current_short_version()

Purpose: Ensures a configured curated plugin missing from cache is reinstalled during refresh.

Data flow: It writes curated marketplace data and SHA, gives refresh a configured plugin id, and expects the current short-version cache folder to be created.

Call relations: It tests recovery from a missing curated plugin cache.

Call graph: calls 2 internal fn (curated_plugins_repo_path, new); 4 external calls (assert!, write_curated_plugin_sha_with, write_openai_curated_marketplace, tempdir).

fn refresh_curated_plugin_cache_reinstalls_missing_api_curated_plugin()

Purpose: Checks the same missing-cache reinstall behavior for API curated plugins.

Data flow: It writes both curated marketplace files with the target only in the API curated file, refreshes for that plugin id, and expects an API curated cache folder.

Call relations: It extends curated refresh coverage to the API curated marketplace name.

Call graph: calls 3 internal fn (curated_plugins_repo_path, write_openai_api_curated_marketplace, new); 4 external calls (assert!, write_curated_plugin_sha_with, write_openai_curated_marketplace, tempdir).

fn refresh_curated_plugin_cache_leaves_api_curated_plugin_when_api_manifest_missing()

Purpose: Ensures an existing API curated cached plugin is not removed if the API curated manifest is missing.

Data flow: It writes only the normal curated marketplace, creates an API curated cached plugin, refreshes, and expects no changes plus the cache folder still present.

Call relations: It protects users from losing API curated plugins when the API manifest is unavailable.

Call graph: calls 3 internal fn (write_cached_plugin, curated_plugins_repo_path, new); 3 external calls (assert!, write_openai_curated_marketplace, tempdir).

fn refresh_curated_plugin_cache_removes_cache_for_plugin_removed_from_marketplace()

Purpose: Checks that curated refresh deletes a configured plugin cache if the plugin no longer exists in the curated marketplace.

Data flow: It writes an empty curated marketplace, creates a cached plugin folder for a removed plugin, refreshes, and expects the plugin cache root to be gone.

Call relations: It tests stale curated plugin cleanup.

Call graph: calls 3 internal fn (write_plugin, curated_plugins_repo_path, new); 4 external calls (assert!, write_openai_curated_marketplace, format!, tempdir).

fn curated_plugin_ids_from_config_keys_reads_latest_codex_home_user_config()

Purpose: Verifies configured curated plugin ids are read from the current user config file each time.

Data flow: It writes config containing curated, API curated, and non-curated plugin keys, checks only curated ids are returned, then rewrites config without them and expects an empty list.

Call relations: It tests the config-reading helper used by curated cache refresh startup work.

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

fn refresh_curated_plugin_cache_returns_false_when_configured_plugins_are_current()

Purpose: Checks curated refresh reports no change when the cache already has the current version.

Data flow: It writes a curated marketplace and a cache folder using the expected short version, refreshes, and expects a false return value.

Call relations: It verifies the no-op path for refresh_curated_plugin_cache.

Call graph: calls 3 internal fn (write_plugin, curated_plugins_repo_path, new); 4 external calls (assert!, write_openai_curated_marketplace, format!, tempdir).

fn refresh_curated_plugin_cache_migrates_full_sha_cache_version_to_short_version()

Purpose: Ensures old curated cache folders named with the full SHA are migrated to the short SHA version.

Data flow: It writes a plugin cache folder using the full SHA, refreshes, and checks the full-SHA folder is removed and the short-version folder exists.

Call relations: It tests backward compatibility for an older curated cache naming scheme.

Call graph: calls 3 internal fn (write_plugin, curated_plugins_repo_path, new); 4 external calls (assert!, write_openai_curated_marketplace, format!, tempdir).

fn refresh_non_curated_plugin_cache_replaces_existing_local_version_with_manifest_version()

Purpose: Checks non-curated cache refresh replaces a local cache folder with the plugin’s manifest version.

Data flow: It writes a marketplace plugin with version 1.2.3, creates an old local cache, refreshes, and expects the local folder gone and the versioned folder present.

Call relations: It directly tests refresh_non_curated_plugin_cache for local marketplace sources.

Call graph: calls 2 internal fn (write_plugin, write_plugin_with_version); 4 external calls (assert!, write_file, create_dir_all, tempdir).

fn refresh_non_curated_plugin_cache_reinstalls_missing_configured_plugin_with_manifest_version()

Purpose: Ensures non-curated refresh recreates a missing configured plugin cache using the manifest version.

Data flow: It writes a versioned marketplace plugin and config enabling it but no cache, refreshes, and expects the versioned cache folder.

Call relations: It tests missing-cache recovery for non-curated plugins.

Call graph: calls 1 internal fn (write_plugin_with_version); 4 external calls (assert!, write_file, create_dir_all, tempdir).

fn refresh_non_curated_plugin_cache_refreshes_configured_git_source()

Purpose: Checks non-curated refresh can materialize a configured plugin from a Git subdirectory source.

Data flow: It creates a Git repo with a versioned plugin, writes a marketplace pointing to that repo, enables the plugin in config, refreshes, and expects the versioned cache folder.

Call relations: It combines init_git_repo with refresh_non_curated_plugin_cache to cover Git-backed marketplace entries.

Call graph: calls 2 internal fn (init_git_repo, write_plugin_with_version); 6 external calls (assert!, write_file, format!, create_dir_all, tempdir, from_directory_path).

fn refresh_non_curated_plugin_cache_returns_false_when_configured_plugins_are_current()

Purpose: Verifies non-curated refresh reports no change when configured plugin caches already match their manifest version.

Data flow: It writes a marketplace plugin and an already-current cache folder, refreshes, and expects a false return value.

Call relations: It tests the no-op path for non-curated refresh.

Call graph: calls 1 internal fn (write_plugin_with_version); 4 external calls (assert!, write_file, create_dir_all, tempdir).

fn refresh_non_curated_plugin_cache_force_reinstalls_current_local_version()

Purpose: Checks the force-refresh path reinstalls even when the version name has not changed.

Data flow: It writes a source plugin with new skill contents and an existing cache with old contents, force-refreshes, and expects the cached skill file to contain the new text.

Call relations: It tests refresh_non_curated_plugin_cache_force_reinstall, which is stricter than the normal no-op refresh.

Call graph: calls 1 internal fn (write_plugin); 6 external calls (assert!, assert_eq!, write_file, create_dir_all, write, tempdir).

fn refresh_non_curated_plugin_cache_ignores_invalid_unconfigured_plugin_versions()

Purpose: Ensures a malformed version in an unrelated, unconfigured plugin does not block refreshing a valid configured plugin.

Data flow: It writes one valid configured plugin and one broken unconfigured plugin in the same marketplace, refreshes, and expects the valid plugin cache to be created.

Call relations: It protects cache refresh from failing on marketplace entries the user has not configured.

Call graph: calls 1 internal fn (write_plugin_with_version); 4 external calls (assert!, write_file, create_dir_all, tempdir).

async fn load_plugins_ignores_project_config_files()

Purpose: Checks that project-level config files do not enable plugins during low-level layer-stack loading.

Data flow: It writes a plugin cache and constructs a config layer stack containing only a project config enabling the plugin, then calls load_plugins_from_layer_stack and expects no plugins.

Call relations: It tests that plugin loading uses the intended config layers and ignores project config for plugin enablement.

Call graph: calls 4 internal fn (new, load_plugins_from_layer_stack, plugin_config_toml, new); 7 external calls (new, default, assert_eq!, default, write_file, new, vec!).

async fn plugin_hooks_for_layer_stack_loads_configured_plugin_hooks()

Purpose: Verifies configured plugin hook files are loaded through the manager’s hook-loading path.

Data flow: It writes a plugin with hooks/hooks.json, enables the plugin, loads config, calls plugin_hooks_for_layer_stack, and checks one hook source and no warnings.

Call relations: It exercises hook discovery after normal config loading and plugin cache setup.

Call graph: calls 4 internal fn (new, load_config, plugin_config_toml, write_plugin); 3 external calls (new, assert_eq!, write_file).

async fn returns_fallback_plugins_without_installed_apps()

Purpose: Checks the default fallback suggestions when the user has no installed app connectors. It verifies that Codex suggests the expected OpenAI-curated plugins and leaves out plugins that should not appear in this fallback list.

Data flow: The test starts with an empty temporary Codex home, writes a fake curated marketplace containing several plugins, and loads that configuration. It asks the plugin manager for discoverable plugins with no configured, disabled, or loaded app connector IDs. The result is turned into plugin IDs and compared with the expected curated suggestions.

Call relations: This test uses the shared setup helper discovery_input to shape the request and list_discoverable_plugins to call the real discovery path. It relies on the test support helpers to create the fake marketplace before the plugin manager reads it.

Call graph: calls 4 internal fn (discovery_input, list_discoverable_plugins, new, curated_plugins_repo_path); 4 external calls (assert_eq!, load_plugins_config, write_openai_curated_marketplace, tempdir).

async fn returns_api_curated_fallback_plugins_for_direct_provider_auth()

Purpose: Checks that API-key authentication changes which curated fallback marketplace is used. In this case, Codex should suggest plugins from the OpenAI API curated marketplace rather than the normal curated marketplace.

Data flow: The test creates a temporary home, writes an API-specific curated marketplace, creates a fake API-key authentication object, and loads the plugin configuration. It sends those inputs to discovery and receives a list of suggested plugins. The plugin IDs are compared with the API-curated IDs.

Call relations: Like the other discovery tests, it goes through discovery_input and list_discoverable_plugins. The important difference is that it passes authentication, so the underlying plugin manager can choose the auth-specific source.

Call graph: calls 6 internal fn (discovery_input, list_discoverable_plugins, new, curated_plugins_repo_path, write_openai_api_curated_marketplace, from_api_key); 3 external calls (assert_eq!, load_plugins_config, tempdir).

async fn returns_microsoft_fallback_plugins()

Purpose: Checks the fallback suggestions for a group of Microsoft-related plugins. It confirms that once one plugin in that group is installed, Codex suggests the remaining related plugins instead of the installed one.

Data flow: The test writes a curated marketplace with Teams, SharePoint, Outlook email, and Outlook calendar plugins. It installs Teams, loads configuration, and asks for discoverable plugins with no extra app information. The output IDs should be the other Microsoft-related plugins.

Call relations: This test uses install_marketplace_plugin to put one marketplace plugin into the installed state. It then uses the same discovery helper path as the rest of the file to verify the manager’s filtering behavior.

Call graph: calls 5 internal fn (discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path); 4 external calls (assert_eq!, load_plugins_config, write_openai_curated_marketplace, tempdir).

async fn includes_openai_curated_when_remote_enabled()

Purpose: Checks that turning on remote plugin support does not hide locally curated OpenAI plugins. Codex should still show curated suggestions alongside bundled marketplace plugins.

Data flow: The test creates a curated marketplace with Slack and a bundled marketplace with Chrome, then writes a configuration file enabling both plugins and remote plugins. After loading the configuration, it asks for discoverable plugins. The returned IDs should include both the bundled Chrome plugin and the curated Slack plugin.

Call relations: The test prepares files directly with the test support writers, then sends the loaded configuration through discovery_input and list_discoverable_plugins. It proves that the remote-enabled path still consults local curated sources.

Call graph: calls 4 internal fn (discovery_input, list_discoverable_plugins, new, curated_plugins_repo_path); 7 external calls (assert_eq!, load_plugins_config, write_curated_plugin, write_file, write_openai_curated_marketplace, format!, tempdir).

async fn deduplicates_configured_marketplace_plugin()

Purpose: Checks that a plugin does not appear twice when it is both present in a marketplace and already listed as configured. This prevents duplicate suggestions in the user interface.

Data flow: The test writes a fake bundled marketplace containing one plugin and marks that same plugin ID as already configured in the discovery input. Discovery returns a list, and the test checks that the list contains exactly one entry with that plugin ID.

Call relations: This test feeds a configured plugin ID through discovery_input. The actual duplicate-removal behavior is exercised inside list_discoverable_plugins, which calls the real plugin manager method.

Call graph: calls 3 internal fn (discovery_input, list_discoverable_plugins, new); 6 external calls (assert_eq!, load_plugins_config, write_curated_plugin, write_file, format!, tempdir).

async fn ignores_missing_marketplace_plugin()

Purpose: Checks that a marketplace entry is ignored if the plugin files are missing from disk. This matters because a marketplace catalog can mention a plugin whose folder is absent or incomplete.

Data flow: The test writes a curated marketplace with installed and Slack plugins, plus a separate bundled marketplace entry for Sample without writing Sample’s plugin files. It installs the curated Installed plugin, loads configuration, and asks for suggestions. The only returned plugin should be Slack from the curated marketplace.

Call relations: The setup combines direct file writing with install_marketplace_plugin. The discovery call goes through list_discoverable_plugins, which is expected to skip the broken marketplace entry rather than fail or show it.

Call graph: calls 5 internal fn (discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path); 6 external calls (assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, format!, tempdir).

async fn normalizes_description()

Purpose: Checks that plugin descriptions are cleaned up before being shown. Extra spaces and newlines in the plugin metadata should become a readable one-line description.

Data flow: The test writes a Slack plugin metadata file whose description has leading spaces, a newline, and repeated spacing. It installs another plugin so Slack remains discoverable, then asks for suggestions. The returned Slack record should contain the normalized description and its other expected metadata.

Call relations: This test uses install_marketplace_plugin to create the installed-plugin context and list_discoverable_plugins to exercise the real metadata reading path. It verifies the final user-facing record, not just the ID.

Call graph: calls 5 internal fn (discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path); 5 external calls (assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, tempdir).

async fn omits_installed_curated_plugins()

Purpose: Checks that Codex does not suggest a curated plugin that is already installed. A suggestion list should help users discover new options, not repeat what they already have.

Data flow: The test writes a curated marketplace containing Slack, installs Slack, loads the configuration, and asks for discoverable plugins. The expected result is an empty list.

Call relations: The installed state is created with install_marketplace_plugin. The discovery request is built by discovery_input and sent through list_discoverable_plugins, which should filter out the installed plugin.

Call graph: calls 5 internal fn (discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path); 4 external calls (assert_eq!, load_plugins_config, write_openai_curated_marketplace, tempdir).

async fn omits_not_available_curated_plugins()

Purpose: Checks that curated plugins marked as not available are not suggested. This protects users from seeing options they cannot install.

Data flow: The test writes a custom marketplace file with Installed, Slack, and Gmail, where Gmail has an installation policy saying it is not available. It writes plugin folders, installs the Installed plugin, and asks for suggestions. The output should include Slack only.

Call relations: This test creates a more detailed marketplace file by hand, then uses install_marketplace_plugin and the common discovery helpers. It confirms that policy information in the marketplace affects the final suggestion list.

Call graph: calls 5 internal fn (discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path); 5 external calls (assert_eq!, load_plugins_config, write_curated_plugin, write_file, tempdir).

async fn does_not_reload_marketplace_per_plugin()

Purpose: Checks that the marketplace is not reread from scratch for every plugin. This is a performance and log-noise test: repeated loading would produce repeated warnings and waste work.

Data flow: The test creates a curated marketplace with several plugins, installs one, and gives the remaining plugins metadata that triggers warning logs because a prompt is too long. It captures warning logs while running discovery. The returned plugin IDs and the number of warning messages are compared with the expected counts.

Call relations: This test uses install_marketplace_plugin, discovery_input, and list_discoverable_plugins, but also installs a temporary tracing subscriber, which is a log collector. The log counts reveal whether the underlying discovery code reused marketplace data or loaded it repeatedly.

Call graph: calls 5 internal fn (discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path); 14 external calls (leak, new, new, from_utf8, new, assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, format! (+4 more)).

async fn does_not_expand_local_plugins_by_installed_apps()

Purpose: Checks that local marketplace plugins are not suggested merely because their app metadata mentions an installed app. This keeps local plugin discovery from becoming too broad.

Data flow: The test writes a curated marketplace with Sample, Slack, and HubSpot, adds app connector metadata to Sample, and installs Slack. It runs discovery with no loaded app connector IDs. The expected result is an empty list.

Call relations: The app metadata is written through write_plugin_app, and the installed plugin state is created through install_marketplace_plugin. Discovery is then called normally to confirm that local app metadata does not expand suggestions in this scenario.

Call graph: calls 6 internal fn (discovery_input, install_marketplace_plugin, list_discoverable_plugins, write_plugin_app, new, curated_plugins_repo_path); 4 external calls (assert_eq!, load_plugins_config, write_openai_curated_marketplace, tempdir).

async fn does_not_read_local_plugins_for_loaded_apps()

Purpose: Checks that discovery does not scan local plugin app files when deciding suggestions for already loaded app connectors. This avoids unnecessary file reads and avoids warnings from unrelated bad files.

Data flow: The test writes app metadata for HubSpot and Granola, then writes invalid JSON into Sample’s app metadata file. It captures warning logs and runs discovery with the HubSpot app connector marked as already loaded. The result should be empty, and the logs should not mention the invalid Sample app file.

Call relations: This test uses write_plugin_app for valid app files and direct file writing for the invalid one. It then goes through discovery_input and list_discoverable_plugins; the absence of log messages proves the discovery path did not read the unrelated local app file.

Call graph: calls 5 internal fn (discovery_input, list_discoverable_plugins, write_plugin_app, new, curated_plugins_repo_path); 13 external calls (leak, new, new, from_utf8, new, assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, new (+3 more)).

async fn does_not_expand_local_sales_apps()

Purpose: Checks that an installed local “sales” style plugin does not cause related local app plugins to be suggested. This prevents local marketplace app relationships from accidentally expanding the suggestion list.

Data flow: The test writes curated plugins with app IDs, creates a separate sales marketplace whose installed plugin mentions HubSpot and Granola app IDs, installs that sales plugin, and loads configuration. It then asks for discoverable plugins. The expected result is an empty list.

Call relations: This test combines write_plugin_app for app metadata, manual marketplace setup, and install_marketplace_plugin for installation. It then uses the shared discovery helpers to show that installed local app relationships are not used as suggestion triggers.

Call graph: calls 6 internal fn (discovery_input, install_marketplace_plugin, list_discoverable_plugins, write_plugin_app, new, curated_plugins_repo_path); 7 external calls (assert_eq!, load_plugins_config, write_curated_plugin, write_file, write_openai_curated_marketplace, format!, tempdir).

async fn expands_cached_remote_plugins_by_loaded_apps()

Purpose: Checks that cached remote plugins can be suggested when the user already has a related app connector loaded. Unlike local plugins, remote catalog data is allowed to expand suggestions in this way.

Data flow: The test enables remote plugins, starts a fake HTTP server, and makes that server return one global remote plugin with an app ID. It fetches and caches the remote global catalog, also caches the empty remote installed-plugin lists, then runs discovery with that app ID marked as loaded. The result should be one discoverable remote plugin with its remote ID, display name, short description, skills flag, and app connector ID.

Call relations: This is the broadest test in the file. It uses the fake server to stand in for the real remote plugin service, calls fetch_and_cache_global_remote_plugin_catalog to create the cache, asks PluginsManager to cache installed remote marketplaces, and finally uses list_discoverable_plugins to verify the suggestion produced from cached remote data.

Call graph: calls 5 internal fn (discovery_input, list_discoverable_plugins, new, fetch_and_cache_global_remote_plugin_catalog, create_dummy_chatgpt_auth_for_testing); 12 external calls (given, start, new, assert_eq!, load_plugins_config, write_file, format!, json!, tempdir, method (+2 more)).

fn discovery_input(
    plugins: PluginsConfigInput,
    configured_plugin_ids: &[&str],
    disabled_plugin_ids: &[&str],
    loaded_plugin_app_connector_ids: &[&str],
) -> ToolSuggestPluginDiscovery

Purpose: Builds the request object used by the tests when asking for discoverable plugins. It keeps each test from repeating the same conversion work.

Data flow: It receives a loaded plugin configuration plus three lists of string IDs: configured plugins, disabled plugins, and loaded app connectors. It converts those lists into sets, which are collections that make membership checks easy, and returns a ToolSuggestPluginDiscoveryInput containing all of that information.

Call relations: Nearly every test calls this helper just before discovery. It delegates the string-list conversion to string_set, then hands the finished input to list_discoverable_plugins.

Call graph: calls 1 internal fn (string_set); called by 14 (deduplicates_configured_marketplace_plugin, does_not_expand_local_plugins_by_installed_apps, does_not_expand_local_sales_apps, does_not_read_local_plugins_for_loaded_apps, does_not_reload_marketplace_per_plugin, expands_cached_remote_plugins_by_loaded_apps, ignores_missing_marketplace_plugin, includes_openai_curated_when_remote_enabled, normalizes_description, omits_installed_curated_plugins (+4 more)).

async fn list_discoverable_plugins(
    plugins_manager: &PluginsManager,
    input: ToolSuggestPluginDiscoveryInput,
    auth: Option<&CodexAuth>,
) -> Vec<ToolSuggestDiscoverablePlugin>

Purpose: Calls the real plugin manager method that the tests are exercising. It also unwraps the result so a failed discovery causes the test to fail immediately with a clear message.

Data flow: It receives a plugin manager, a discovery input object, and optional authentication. It asks the manager to list tool-suggestion discoverable plugins, waits for the asynchronous work to finish, and returns the plugin list. If the manager reports an error, the test stops.

Call relations: All the scenario tests use this helper as the final step after setting up fake files and configuration. It is the bridge between the test setup and the production discovery code under test.

Call graph: called by 14 (deduplicates_configured_marketplace_plugin, does_not_expand_local_plugins_by_installed_apps, does_not_expand_local_sales_apps, does_not_read_local_plugins_for_loaded_apps, does_not_reload_marketplace_per_plugin, expands_cached_remote_plugins_by_loaded_apps, ignores_missing_marketplace_plugin, includes_openai_curated_when_remote_enabled, normalizes_description, omits_installed_curated_plugins (+4 more)); 1 external calls (list_tool_suggest_discoverable_plugins).

fn string_set(values: &[&str]) -> HashSet<String>

Purpose: Turns a small list of string slices into a set of owned strings. The tests use sets because discovery input needs quick “is this ID present?” checks.

Data flow: It receives borrowed string values, copies each one into a new String, and collects them into a HashSet. The returned set is then stored in the discovery input.

Call relations: discovery_input calls this helper for configured plugin IDs, disabled plugin IDs, and loaded app connector IDs. It is a small convenience function that keeps the discovery-input builder tidy.

Call graph: called by 1 (discovery_input).

async fn install_marketplace_plugin(codex_home: &Path, marketplace_root: &Path, plugin_name: &str)

Purpose: Installs a fake marketplace plugin into the temporary Codex home used by a test. This lets tests check how discovery behaves when some plugins are already installed.

Data flow: It receives the temporary Codex home path, the root of a fake marketplace, and a plugin name. It writes the expected curated plugin SHA marker, builds the path to the marketplace JSON file, creates a plugin manager for that home, and asks it to install the named plugin. If installation fails, the test fails.

Call relations: Several tests call this before discovery to create an installed-plugin state. It uses the real PluginsManager::install_plugin path, so the later discovery call sees the same kind of installation data it would see in normal use.

Call graph: calls 2 internal fn (new, try_from); called by 8 (does_not_expand_local_plugins_by_installed_apps, does_not_expand_local_sales_apps, does_not_reload_marketplace_per_plugin, ignores_missing_marketplace_plugin, normalizes_description, omits_installed_curated_plugins, omits_not_available_curated_plugins, returns_microsoft_fallback_plugins); 3 external calls (join, to_path_buf, write_curated_plugin_sha_with).

fn write_plugin_app(root: &Path, plugin_name: &str, app_name: &str, app_id: &str)

Purpose: Writes a small .app.json metadata file for a fake plugin. The metadata links an app name to an app connector ID so tests can explore app-related discovery behavior.

Data flow: It receives a marketplace root, plugin name, app name, and app ID. It formats those values into a JSON file and writes that file under the plugin’s folder. The filesystem is changed; nothing is returned.

Call relations: Tests that need app connector metadata call this during setup. The discovery code may later see these files depending on the scenario, which lets the tests prove when local app metadata should or should not influence suggestions.

Call graph: called by 3 (does_not_expand_local_plugins_by_installed_apps, does_not_expand_local_sales_apps, does_not_read_local_plugins_for_loaded_apps); 3 external calls (join, write_file, format!).

fn app(name: &str) -> AppDeclaration

Purpose: Creates a small fake app declaration for use in tests. This lets each test say “make an app named linear” without repeating all the struct fields every time.

Data flow: It takes an app name as text. It builds an AppDeclaration with that name, makes a connector id by prefixing the name with connector_, leaves the category empty, and returns the completed test app object.

Call relations: This helper supports the test setup in this file. While building the fake connector id, it uses string formatting and constructs an AppConnectorId so the test app looks like a real app declaration.

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

fn mcp_servers(mcp_servers: impl IntoIterator<Item = (&'static str, i32)>) -> HashMap<String, i32>

Purpose: Builds a fake collection of MCP servers for tests. Each server is represented by a name and a simple integer value, so the tests can focus on which server names remain after routing rules run.

Data flow: It receives pairs like ("linear", 1). It turns each borrowed text name into an owned string, keeps the integer value, collects everything into a HashMap, and returns that map.

Call relations: The routing tests call this when they need a starting set of MCP servers. It uses iteration to turn the compact test input into the map shape expected by the routing policy.

Call graph: called by 3 (app_mcp_routing_clears_apps_when_apps_route_is_unavailable, app_mcp_routing_preserves_apps_and_removes_conflicting_mcp_with_apps_route, app_mcp_routing_preserves_mcp_conflicts_when_plugin_is_inactive); 1 external calls (into_iter).

fn sorted_app_names(apps: &[AppDeclaration]) -> Vec<String>

Purpose: Pulls app names out of a list and sorts them so tests can compare results reliably. This avoids false failures caused only by ordering.

Data flow: It reads a slice of app declarations. It copies each app’s name into a new list, sorts that list alphabetically, and returns the sorted names.

Call relations: The tests use this after the routing policy has changed the app list. It gives assertions a clean, predictable view of just the names that matter.

Call graph: 1 external calls (iter).

fn sorted_mcp_server_names(mcp_servers: &HashMap<String, i32>) -> Vec<String>

Purpose: Pulls MCP server names out of a map and sorts them for stable test comparisons. This is needed because a HashMap does not keep names in a predictable order.

Data flow: It reads the keys from the MCP server map, copies them into a list, sorts that list alphabetically, and returns the sorted server names.

Call relations: The tests use this after routing decisions have been applied. It turns the remaining MCP server map into an easy-to-compare list of names.

fn apps_route_available_tracks_auth_mode()

Purpose: Checks that app routing is enabled only for the intended authentication modes. In plain terms, it verifies that the system only offers app-based routing when the user is signed in in a way that supports it.

Data flow: It tries apps_route_available with ChatGPT, Agent Identity, API key, and no authentication. It expects true for ChatGPT and Agent Identity, and false for API key or missing authentication.

Call relations: This test directly exercises the availability check before the broader routing policy is tested. Its assertions act as a guardrail: if authentication rules change unexpectedly, this test points to the cause.

Call graph: 1 external calls (assert!).

fn app_mcp_routing_clears_apps_when_apps_route_is_unavailable()

Purpose: Verifies that when app routing is not allowed, app declarations are removed from consideration. MCP servers are left untouched because they are still valid routes.

Data flow: It starts with one app named linear and two MCP servers named linear and docs. It runs the routing policy with API key authentication, where app routing is unavailable, and with the plugin marked active. Afterward, it expects the app list to be empty and both MCP servers to still be present.

Call relations: This test uses the MCP server helper to build its starting map, then calls the routing policy under an unavailable-authentication scenario. It finishes by checking both sides of the outcome: apps were cleared, but MCP server names were preserved.

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

fn app_mcp_routing_preserves_apps_and_removes_conflicting_mcp_with_apps_route()

Purpose: Verifies the preferred path when app routing is available and the plugin is active. If an app and an MCP server have the same name, the app route wins and the duplicate MCP server is removed.

Data flow: It starts with apps named linear and notion, and MCP servers named linear, docs, and notion. It runs the routing policy with ChatGPT authentication and an active plugin. Afterward, it expects both apps to remain, but only the non-conflicting MCP server docs to remain.

Call relations: This test creates a deliberate name conflict, then asks the routing policy to resolve it in the normal app-routing path. It uses sorted name helpers in the assertions so the test checks the routing decision, not collection ordering.

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

fn app_mcp_routing_preserves_mcp_conflicts_when_plugin_is_inactive()

Purpose: Checks that the routing policy does not remove conflicting MCP servers when the plugin is inactive. Even if app routing would otherwise be available, the inactive plugin means the policy should not clean up those overlaps.

Data flow: It starts with one app named linear and MCP servers named linear and docs. It runs the routing policy with ChatGPT authentication but marks the plugin inactive. Afterward, it expects the app to remain and both MCP servers to remain as well.

Call relations: This test covers the plugin-active switch in the routing decision. It calls the same policy as the other routing tests but changes only the plugin activity flag, proving that conflict removal depends on that flag being true.

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

fn write_file(path: &Path, contents: &str)

Purpose: Writes text to a file during test setup, creating the parent folder first if needed. Tests use it so they can place config and plugin files anywhere in a temporary directory without separately making each folder.

Data flow: It takes a file path and some text. It looks up the file’s parent directory, creates that directory tree, then writes the text into the file. The result is a real file on disk, and the test stops with an error if the directory or file cannot be created.

Call relations: This is the low-level helper that the other setup helpers rely on. The plugin, marketplace, SHA, and feature-config writers all call it when they need to put one concrete file in place.

Call graph: called by 4 (write_curated_plugin, write_curated_plugin_sha_with, write_openai_curated_marketplace, write_plugins_feature_config); 3 external calls (parent, create_dir_all, write).

fn write_curated_plugin(root: &Path, plugin_name: &str)

Purpose: Creates a fake curated plugin folder with the files the plugin system expects to find. It is used when a test needs something that looks like an installable or readable plugin.

Data flow: It receives a root test directory and a plugin name. From those, it builds a plugin folder path, then writes a plugin manifest, one sample skill file, an MCP server JSON file, and an app connector JSON file. After it runs, the test root contains a complete sample plugin layout.

Call relations: This helper builds one plugin at a time. The marketplace helper calls it after writing the marketplace list, so every plugin named in that marketplace also exists on disk.

Call graph: calls 1 internal fn (write_file); called by 1 (write_openai_curated_marketplace); 2 external calls (join, format!).

fn write_openai_curated_marketplace(root: &Path, plugin_names: &[&str])

Purpose: Creates a fake OpenAI curated marketplace file that lists local test plugins. This lets tests exercise marketplace-based plugin discovery without contacting a real marketplace service.

Data flow: It takes a root test directory and a list of plugin names. It turns those names into JSON entries that point to local plugin folders, writes the marketplace JSON file under .agents/plugins, and then creates each named plugin folder and its contents. The result is a self-contained local marketplace plus the plugins it advertises.

Call relations: This is a higher-level setup helper. It uses write_file to create the marketplace listing and write_curated_plugin to make sure each listed plugin is actually present.

Call graph: calls 2 internal fn (write_curated_plugin, write_file); 2 external calls (join, format!).

fn write_curated_plugin_sha(codex_home: &Path)

Purpose: Writes the standard fake curated-plugin SHA used by tests. A SHA is a fingerprint-like string often used to identify an exact downloaded or installed version.

Data flow: It takes the test Codex home directory and passes it, along with the file’s built-in test SHA value, to the more flexible SHA-writing helper. The visible result is a .tmp/plugins.sha file containing the default test fingerprint.

Call relations: This is a convenience wrapper for tests that do not care which SHA is used. The verified plugin install test calls it, and it delegates the actual file writing to write_curated_plugin_sha_with.

Call graph: calls 1 internal fn (write_curated_plugin_sha_with); called by 1 (verified_plugin_install_completed_requires_installed_plugin).

fn write_curated_plugin_sha_with(codex_home: &Path, sha: &str)

Purpose: Writes a chosen plugin SHA value into the test home directory. Tests use this when they need to simulate a specific installed plugin fingerprint.

Data flow: It receives a Codex home path and a SHA string. It formats the SHA with a trailing newline and writes it to .tmp/plugins.sha under that home directory. Afterward, code that checks the installed plugin SHA can read that test value from disk.

Call relations: The default SHA helper calls this with the shared test SHA. Internally it relies on write_file, so the .tmp folder is created automatically if it does not exist.

Call graph: calls 1 internal fn (write_file); called by 1 (write_curated_plugin_sha); 2 external calls (join, format!).

fn write_plugins_feature_config(codex_home: &Path)

Purpose: Creates a test config file that turns the plugins feature on. This is needed for tests where plugin behavior should be enabled through the same configuration path used by the real application.

Data flow: It takes a Codex home directory, writes the project’s config TOML file there, and fills it with a [features] section where plugins = true. After that, loading config from this home directory will see plugins as enabled.

Call relations: Plugin-install verification tests call this before loading or running plugin logic. It uses write_file to create the config file in the right location.

Call graph: calls 1 internal fn (write_file); called by 1 (verified_plugin_install_completed_requires_installed_plugin); 1 external calls (join).

async fn load_plugins_config(codex_home: &Path) -> crate::config::Config

Purpose: Loads a Codex configuration from a test home directory. Tests use it after writing setup files so they can get a real Config object built from that temporary environment.

Data flow: It receives a Codex home path, creates a ConfigBuilder, points both the Codex home and fallback current working directory at that path, then asynchronously builds the config. It returns the loaded config, or fails the test if the config cannot be loaded.

Call relations: This helper is used after test files have been written. It hands the prepared directory to the normal configuration builder so plugin tests exercise the real config-loading path rather than a mock shortcut.

Call graph: 2 external calls (to_path_buf, default).

async fn list_discoverable_plugins(
    config: &crate::config::Config,
    loaded_plugin_app_connector_ids: &[String],
) -> anyhow::Result<Vec<DiscoverablePluginInfo>>

Purpose: This small helper asks the plugin suggestion system for discoverable plugins when no login information is needed. The tests use it to keep simple cases short and readable.

Data flow: It receives a Codex configuration and a list of plugin app connector IDs that are already loaded. It passes those along with no authentication information, then returns the list of discoverable plugin descriptions or an error.

Call relations: The simpler tests call this helper when they only care about local config and curated plugins. It immediately hands the real work to list_discoverable_plugins_with_auth, using no auth because those cases do not need a remote account.

Call graph: calls 1 internal fn (list_discoverable_plugins_with_auth); called by 3 (list_tool_suggest_discoverable_plugins_includes_configured_plugin_ids, list_tool_suggest_discoverable_plugins_omits_disabled_tool_suggestions, list_tool_suggest_discoverable_plugins_returns_empty_when_plugins_feature_disabled).

async fn list_discoverable_plugins_with_auth(
    config: &crate::config::Config,
    auth: Option<&codex_login::CodexAuth>,
    loaded_plugin_app_connector_ids: &[String],
) -> anyhow::Result<Vec<Dis

Purpose: This helper prepares a PluginsManager before asking for discoverable plugin suggestions. A PluginsManager is the object that knows where plugin data lives and how plugin marketplaces should be read.

Data flow: It receives the config, optional login/authentication information, and already-loaded app connector IDs. It builds a PluginsManager using the Codex home folder, the Codex product name, and the auth mode if one exists. It then returns whatever the next helper finds.

Call relations: list_discoverable_plugins calls this when tests do not provide auth directly. After creating the manager, it passes control to list_discoverable_plugins_with_manager_and_auth so the actual suggestion call is made in one shared place.

Call graph: calls 2 internal fn (new_with_options, list_discoverable_plugins_with_manager_and_auth); called by 1 (list_discoverable_plugins).

async fn list_discoverable_plugins_with_manager_and_auth(
    config: &crate::config::Config,
    plugins_manager: &PluginsManager,
    auth: Option<&codex_login::CodexAuth>,
    loaded_plugin_app_con

Purpose: This helper is the direct bridge from the tests into the real plugin suggestion function. It exists so tests can either use a freshly created manager or pass in a manager whose caches have already been prepared.

Data flow: It receives the config, a PluginsManager, optional auth, and loaded app connector IDs. It forwards them to the production function that lists tool-suggest discoverable plugins, then returns the resulting plugin list or error.

Call relations: The auth helper uses this after creating a manager. The remote-plugin test also calls it directly because that test needs to reuse a specific PluginsManager after filling its remote plugin caches.

Call graph: called by 2 (list_discoverable_plugins_with_auth, list_tool_suggest_discoverable_plugins_includes_cached_remote_global_plugins); 1 external calls (list_tool_suggest_discoverable_plugins).

async fn list_tool_suggest_discoverable_plugins_includes_cached_remote_global_plugins()

Purpose: This test proves that a valid remote global plugin can appear as a discoverable suggestion, but only after the remote plugin marketplace cache is properly built. It also proves that a user-disabled remote suggestion is hidden.

Data flow: It creates a temporary Codex home, writes config that enables plugins and remote plugins, and starts a fake HTTP server that returns several remote plugin records. Some records are intentionally unusable, such as unavailable or admin-disabled plugins. The test fetches and caches the global remote catalog, asks for discoverable plugins, then confirms the remote GitHub plugin is not shown too early. It then mocks installed-plugin responses, builds the remote installed-plugin marketplace cache, asks again, and confirms only the expected GitHub remote plugin appears with the right fields. Finally it rewrites config to disable that suggestion and confirms it disappears.

Call relations: This test drives the most complete flow in the file. It creates auth, uses remote fetching and cache-building functions, then calls list_discoverable_plugins_with_manager_and_auth to enter the real suggestion logic at each checkpoint.

Call graph: calls 4 internal fn (new, fetch_and_cache_global_remote_plugin_catalog, list_discoverable_plugins_with_manager_and_auth, create_dummy_chatgpt_auth_for_testing); 10 external calls (given, start, new, assert!, assert_eq!, load_plugins_config, write_file, format!, json!, tempdir).

async fn list_tool_suggest_discoverable_plugins_returns_empty_when_plugins_feature_disabled()

Purpose: This test checks the safety switch: if the plugins feature is disabled, Codex should not suggest plugins at all. This prevents plugin suggestions from appearing when the user or environment has turned the feature off.

Data flow: It creates a temporary Codex home, writes a fake curated marketplace containing Slack, and writes config with plugins set to false. It loads that config, asks for discoverable plugins, and expects an empty list.

Call relations: This is one of the simple local tests. It prepares files with the test-support helpers, then calls list_discoverable_plugins, which routes through the helper chain into the real suggestion function.

Call graph: calls 2 internal fn (curated_plugins_repo_path, list_discoverable_plugins); 5 external calls (assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, tempdir).

async fn list_tool_suggest_discoverable_plugins_omits_disabled_tool_suggestions()

Purpose: This test confirms that a plugin explicitly listed as disabled in the tool suggestion settings is not shown. It protects the user’s preference to hide a suggested tool.

Data flow: It creates a temporary Codex home, writes a curated marketplace with Slack, and writes config that enables plugins but disables the Slack plugin suggestion. It loads the config, asks for discoverable plugins, and expects no results.

Call relations: Like the other local tests, it builds a small fake filesystem setup, then calls list_discoverable_plugins. That helper path reaches the real discoverable-plugin listing code and returns the filtered result.

Call graph: calls 2 internal fn (curated_plugins_repo_path, list_discoverable_plugins); 5 external calls (assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, tempdir).

async fn list_tool_suggest_discoverable_plugins_includes_configured_plugin_ids()

Purpose: This test checks that a plugin named in the user’s discoverable-tool configuration is returned with the expected user-facing details. It verifies not just that the plugin appears, but that its important metadata is preserved.

Data flow: It creates a temporary Codex home, writes a curated marketplace containing a sample plugin, and writes config that marks that sample plugin as discoverable. It loads the config, asks for discoverable plugins, and compares the result to the expected ID, name, description, skill flag, MCP server name, and app connector ID.

Call relations: This test uses the same simple helper path as the other local tests. After the fake marketplace and config are ready, it calls list_discoverable_plugins, which eventually calls the production suggestion-listing function.

Call graph: calls 2 internal fn (curated_plugins_repo_path, list_discoverable_plugins); 5 external calls (assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, tempdir).

fn text_input(text: &str) -> UserInput

Purpose: This small helper creates a plain text user input from a string. Tests use it so they do not have to repeat the full UserInput::Text structure every time they need a text message.

Data flow: It takes a text string, copies it into an owned string, adds an empty list of text elements, and returns a UserInput::Text value. It does not change anything outside itself.

Call relations: The linked-text plugin mention tests call this helper when they need input that looks like a normal written message containing a link. It hands that prepared input to collect_explicit_plugin_mentions, which then does the real parsing being tested.

Call graph: called by 4 (collect_explicit_plugin_mentions_dedupes_structured_and_linked_mentions, collect_explicit_plugin_mentions_from_linked_text_mentions, collect_explicit_plugin_mentions_ignores_dollar_linked_plugin_mentions, collect_explicit_plugin_mentions_ignores_non_plugin_paths); 1 external calls (new).

fn plugin(config_name: &str, display_name: &str) -> PluginCapabilitySummary

Purpose: This helper creates a minimal fake plugin description for tests. It lets each test name the plugin by its internal config name and its display name without filling in every field by hand.

Data flow: It takes a plugin config name and display name, turns both into owned strings, fills the remaining plugin fields with simple default test values, and returns a PluginCapabilitySummary.

Call relations: The plugin mention tests use this helper to build the list of available plugins and the expected result. Those plugin summaries are passed into collect_explicit_plugin_mentions, so the test can check whether the correct plugin was selected.

Call graph: 1 external calls (new).

fn collect_explicit_app_ids_from_linked_text_mentions()

Purpose: This test proves that an app mention written as a link inside plain text is recognized. In this case, app://calendar should produce the app id calendar.

Data flow: It starts with one text input containing a Markdown-style link to an app. It sends that input to collect_explicit_app_ids, then compares the returned set with a set containing only calendar.

Call relations: During the test run, this function calls the real app-id collection function and uses an assertion to verify the answer. It focuses on the linked-text form of an app mention.

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

fn collect_explicit_app_ids_dedupes_structured_and_linked_mentions()

Purpose: This test makes sure the same app is not counted twice when it appears in both text-link form and structured mention form. The user may mention the same thing in more than one representation, but the system should treat it as one app request.

Data flow: It builds two inputs that both point to app://calendar: one text link and one structured mention. It passes them to collect_explicit_app_ids and expects a set with just one calendar entry.

Call relations: This test calls the real app-id collector after creating mixed input forms. The final assertion checks the deduplication behavior, meaning duplicate mentions collapse into a single result.

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

fn collect_explicit_app_ids_ignores_non_app_paths()

Purpose: This test checks that the app collector does not mistake other kinds of references for apps. Links to MCP resources, skills, or ordinary files should not become app ids.

Data flow: It creates text and structured mentions for non-app paths such as mcp://, skill://, and a file path. It passes all of them to collect_explicit_app_ids and expects an empty set back.

Call relations: The test exercises the filtering part of the app-id collector. It confirms that only app:// paths are accepted, while other mention types are ignored.

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

fn collect_explicit_plugin_mentions_from_structured_paths()

Purpose: This test proves that a structured plugin mention can select the matching plugin from the available plugin list. A structured mention is already separated from plain text and includes a path like plugin://sample@test.

Data flow: It creates two fake plugins, then provides one structured mention pointing to sample@test. It passes both the mention and the plugin list to collect_explicit_plugin_mentions, and expects only the matching sample plugin back.

Call relations: This test calls the real plugin mention collector with structured input. The assertion verifies that the collector connects the mention path to the correct plugin summary.

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

fn collect_explicit_plugin_mentions_from_linked_text_mentions()

Purpose: This test checks that a plugin mention written as a link in normal text is recognized when it uses the plugin-style @ label. For example, [@sample](plugin://sample@test) should select the sample plugin.

Data flow: It builds a list of available fake plugins and a text input containing a plugin link. It sends both to collect_explicit_plugin_mentions, then expects the matching plugin summary as the only result.

Call relations: This test uses text_input to create the plain text message, then calls the real plugin mention collector. The assertion confirms that linked text can trigger plugin selection.

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

fn collect_explicit_plugin_mentions_dedupes_structured_and_linked_mentions()

Purpose: This test makes sure one plugin is returned only once even if the user input mentions it in two different ways. It protects against duplicate plugin activation caused by repeated references to the same plugin.

Data flow: It creates a text link and a structured mention that both point to plugin://sample@test. It passes those inputs, along with the available plugin list, to collect_explicit_plugin_mentions and expects a single sample plugin in the result.

Call relations: The test uses text_input for the linked-text case and also includes a structured mention. It then calls the plugin mention collector and checks that the collector merges the duplicate references.

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

fn collect_explicit_plugin_mentions_ignores_non_plugin_paths()

Purpose: This test checks that the plugin collector ignores links that point to apps, skills, or files. A plugin collector should only react to plugin paths, not to every link-like thing in the user message.

Data flow: It creates one available plugin, then builds a text input containing non-plugin links such as app://calendar, skill://team/skill, and a file path. It passes that to collect_explicit_plugin_mentions and expects an empty plugin list.

Call relations: This test uses text_input to prepare the message and then calls the real plugin mention collector. The assertion verifies the collector’s filtering rule: non-plugin paths are left alone.

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

fn collect_explicit_plugin_mentions_ignores_dollar_linked_plugin_mentions()

Purpose: This test captures a subtle rule: even if a link points to plugin://..., it should not count as an explicit plugin mention when the visible label uses $ instead of @. That prevents app-style labels from accidentally activating plugins.

Data flow: It creates one available plugin and a text input containing [$sample](plugin://sample@test). It passes them to collect_explicit_plugin_mentions and expects no plugins to be returned.

Call relations: The test uses text_input to build the linked message, then calls the plugin mention collector. The assertion checks that the collector pays attention not only to the link destination, but also to the mention style shown in the text.

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

fn render_plugins_section_returns_none_for_empty_plugins()

Purpose: This test makes sure no plugin section is produced when the plugin list is empty. That matters because showing plugin instructions when no plugins exist would add noise and could confuse later behavior.

Data flow: It starts with an empty list of plugins. It passes that list to the plugin-section renderer, then compares the result with None, meaning “no section was produced.” Nothing is changed outside the test.

Call relations: During the test run, this function exercises the renderer with the simplest possible input: no plugins. It then hands the actual and expected values to assert_eq!, which decides whether the behavior is correct.

Call graph: 1 external calls (assert_eq!).

fn render_plugins_section_keeps_plugin_usage_guidance_without_listing_plugins()

Purpose: This test checks that having a plugin causes the general plugin instructions to appear, while keeping the section focused on usage guidance rather than a plugin-by-plugin list. It protects the exact wording of that guidance.

Data flow: It builds one sample plugin summary, using a default summary as a base and filling in a name, description, and the fact that it has skills. It sends that plugin list into the renderer, expects a rendered text block back, and compares that block with the exact expected plugin-instructions text.

Call relations: During the test run, this function creates a realistic plugin summary and asks the renderer for the plugin section. It uses default to avoid filling in unrelated fields, then uses assert_eq! to verify that the rendered text matches the approved guidance exactly.

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

fn app(id: &str) -> AppInfo

Purpose: Creates a simple fake app connector record for tests. It fills in the required fields with predictable defaults so each test only has to care about the app ID.

Data flow: It receives an app ID as text. It copies that ID into both the app's ID and name fields, leaves optional details like logos and descriptions empty, marks the app as enabled but not accessible, and returns the completed AppInfo test object.

Call relations: This helper is used by with_app_enabled_state_preserves_unrelated_disabled_connector when that test needs two connector records with known starting values. It calls standard string construction to turn borrowed text into owned strings.

Call graph: called by 1 (with_app_enabled_state_preserves_unrelated_disabled_connector); 1 external calls (new).

fn plugin_names(names: &[&str]) -> Vec<String>

Purpose: Converts a short list of plugin display names into the owned string list expected by connector data structures. It keeps test setup compact and easy to read.

Data flow: It receives a slice of text references such as plugin names. It copies each one into a standalone String and returns them as a vector.

Call relations: codex_app_tool calls this helper when building fake tool metadata with plugin display names. This keeps the tool-building helper focused on the larger ToolInfo shape instead of string conversion.

Call graph: called by 1 (codex_app_tool).

fn test_tool_definition(tool_name: &str) -> Tool

Purpose: Builds a minimal fake MCP tool definition for tests. It supplies a tool name and an empty input description, which is enough for these connector tests.

Data flow: It receives a tool name. It creates an empty JSON object for the tool schema, wraps it in shared ownership, and returns a Tool object with the given name and no extra description.

Call relations: codex_app_tool calls this when it needs a realistic ToolInfo object. The helper delegates to external Tool and JSON constructors so the fake tool has the same basic shape as a real one.

Call graph: called by 1 (codex_app_tool); 3 external calls (new, default, new_with_raw).

fn codex_app_tool(
    tool_name: &str,
    connector_id: &str,
    connector_name: Option<&str>,
    plugin_display_names: &[&str],
) -> ToolInfo

Purpose: Creates a fake Codex Apps MCP tool tied to a connector. Tests use it to simulate the tools Codex would normally discover from installed app connectors.

Data flow: It receives a tool name, connector ID, optional connector name, and plugin display names. If a connector name is present, it sanitizes that name and builds a namespaced callable path; otherwise it uses the general Codex Apps server name. It then returns a ToolInfo record containing the server name, callable names, connector identity, optional connector display name, plugin names, and a minimal tool definition.

Call relations: Several tests use this helper to make realistic MCP tool data. Inside, it calls plugin_names to prepare display names and test_tool_definition to create the embedded tool object.

Call graph: calls 2 internal fn (plugin_names, test_tool_definition).

fn with_accessible_connectors_cache_cleared(f: impl FnOnce() -> R) -> R

Purpose: Runs a test section while temporarily clearing the shared accessible-connectors cache. This prevents one test's cached data from leaking into another test, like wiping a whiteboard before using it and then restoring what was there.

Data flow: It receives a closure, which is a block of code to run. It locks the global cache, saves the previous cache value, clears it, runs the closure, then locks the cache again and restores the saved value. It returns whatever the closure returned.

Call relations: refresh_accessible_connectors_cache_from_mcp_tools_writes_latest_installed_apps uses this helper around its cache refresh check. The helper interacts with the shared cache directly so the test can make a clean assertion about the newly written cache contents.

Call graph: called by 1 (refresh_accessible_connectors_cache_from_mcp_tools_writes_latest_installed_apps).

fn accessible_connectors_from_mcp_tools_carries_plugin_display_names()

Purpose: Checks that when multiple MCP tools belong to the same connector, Codex keeps the connector's plugin display names. This matters because the user-visible connector entry should still show which plugin sources are associated with it.

Data flow: The test builds two fake calendar tools with connector metadata and one unrelated non-connector tool. It passes them into the connector-conversion logic, then compares the result with the one expected calendar AppInfo. The expected output includes the connector name, generated install URL, accessibility flag, enabled state, and deduplicated plugin display names.

Call relations: The Rust test runner calls this test. It uses local fake data and assertion helpers, and it exercises the connector-building path that groups MCP tools into accessible app connector records.

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

async fn refresh_accessible_connectors_cache_from_mcp_tools_writes_latest_installed_apps()

Purpose: Checks that refreshing the accessible-connectors cache writes the latest connector list derived from MCP tools. This protects the cached installed-app view from becoming stale or missing newly discovered connector information.

Data flow: The test creates a temporary Codex home folder, builds a config with the Apps feature enabled, computes the cache key, and creates fake connector tools. Inside a cleared-cache section, it refreshes the cache from those tools, reads the cached value back, and compares it with the expected list of accessible connector apps.

Call relations: The async test runner calls this test. It relies on with_accessible_connectors_cache_cleared to isolate the shared cache, then checks the refresh and readback path as one end-to-end cache story.

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

fn accessible_connectors_from_mcp_tools_preserves_description()

Purpose: Checks that connector descriptions from MCP namespace metadata are preserved in the app record. This matters because that description is what helps users understand what a connector can do.

Data flow: The test builds one fake calendar ToolInfo with a namespace description, connector ID, and connector name. It converts the tool list into accessible connectors and expects one AppInfo whose description is exactly the namespace description from the tool metadata.

Call relations: The test runner invokes this test. It constructs the ToolInfo directly rather than through the helper because the important detail here is the namespace description field.

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

async fn app_approvals_reviewer_uses_app_then_default_then_global()

Purpose: Verifies the priority order for approval reviewer settings. For Codex Apps, an app-specific setting should win, then the app default, and only then the global setting; non-app MCP servers should use the global setting.

Data flow: For two combinations of reviewer values, the test writes a temporary config file containing a global reviewer, a default app reviewer, and a calendar-specific reviewer. It loads the config and asks for the reviewer for calendar, for another app, for no connector ID, and for a custom server. Each answer is compared with the expected priority result.

Call relations: The async test runner calls this test. It uses temporary files and config loading to exercise the real configuration path rather than manually constructing every setting in memory.

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

async fn default_app_approvals_reviewer_respects_global_reviewer_requirements()

Purpose: Checks that enterprise-wide reviewer restrictions override an app default that is not allowed. This prevents local app settings from bypassing organization policy.

Data flow: The test writes a config where the global reviewer is auto review and the default app reviewer is user. It also loads a cloud policy saying only auto review is allowed. After building the config, it asks for the reviewer for a Codex Apps connector and expects auto review, because the user reviewer is forbidden by the requirement.

Call relations: The async test runner invokes this test. It calls the cloud-config fixture helper to simulate an enterprise requirement, then verifies that the approval-reviewer lookup respects that requirement.

Call graph: calls 1 internal fn (loader_with_enterprise_requirement); 4 external calls (assert_eq!, default, write, tempdir).

async fn app_approvals_reviewer_respects_global_reviewer_requirements()

Purpose: Checks that enterprise-wide reviewer restrictions also override an app-specific reviewer that is not allowed. This closes a more specific loophole than the default-app case.

Data flow: The test writes a config where the global reviewer is auto review but the calendar app asks for user review. It loads a cloud policy allowing only auto review, builds the config, asks for calendar's reviewer, and expects auto review.

Call relations: The async test runner calls this test. Like the related default-app test, it uses the enterprise requirement fixture to make sure the real config enforcement path is being tested.

Call graph: calls 1 internal fn (loader_with_enterprise_requirement); 4 external calls (assert_eq!, default, write, tempdir).

async fn with_app_enabled_state_preserves_unrelated_disabled_connector()

Purpose: Checks that applying enabled or disabled state from configuration does not accidentally re-enable an unrelated connector. This matters because disabling one app should not be undone when another app is processed.

Data flow: The test builds a temporary config and injects requirements saying the drive connector is disabled. It creates a Slack app that is already disabled and a Drive app. After applying enabled-state logic, it expects Slack to remain disabled and Drive to be disabled according to requirements.

Call relations: The async test runner invokes this test. It uses the app helper to create simple connector records, builds a requirement stack with external constructors, then asserts that the enabled-state transformation produces the intended final app list.

Call graph: calls 2 internal fn (new, app); 7 external calls (from, default, new, default, assert_eq!, default, tempdir).

async fn tool_suggest_connector_ids_include_configured_tool_suggest_discoverables()

Purpose: Checks that configured connector-type tool suggestions are included. It also checks that non-connector suggestions and blank connector IDs are ignored.

Data flow: The test writes a temporary config with tool suggestion discoverables: one valid connector, one plugin, and one whitespace-only connector ID. After loading the config, it asks for suggested connector IDs and expects only the valid connector ID.

Call relations: The async test runner calls this test. It exercises the configuration-reading path for tool suggestions and uses an assertion to make sure only usable connector IDs come out.

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

async fn tool_suggest_connector_ids_exclude_disabled_tool_suggestions()

Purpose: Checks that a connector listed as disabled is removed from tool suggestions even if it was also listed as discoverable. This gives the disabled list the expected veto power.

Data flow: The test writes a config with calendar and Gmail as discoverable connector suggestions, then marks calendar as disabled. It loads the config and expects the connector-ID set to contain Gmail only.

Call relations: The async test runner invokes this test. It is paired with the inclusion test and verifies the filtering step after configured suggestions are read.

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

async fn tool_suggest_uses_connector_id_fallback_when_directory_cache_is_empty()

Purpose: Checks that tool suggestions can still show a configured connector even when the connector directory cache has no detailed app information. This fallback keeps suggestions useful when cached metadata is missing.

Data flow: The test writes a config enabling apps and declaring Gmail as a discoverable connector. It builds a config, creates dummy authentication, creates a plugin manager rooted in the temporary Codex home, then asks for discoverable tools with empty directory inputs. It expects a DiscoverableTool made from the connector ID fallback.

Call relations: The async test runner calls this test. It creates a PluginsManager and dummy auth object, then exercises the authenticated tool-suggestion listing path where the directory cache contributes no connector details.

Call graph: calls 2 internal fn (new, create_dummy_chatgpt_auth_for_testing); 4 external calls (assert_eq!, default, write, tempdir).

async fn tool_suggest_includes_connectors_from_loaded_plugin_apps()

Purpose: Checks that connectors from already loaded plugin apps are included in tool suggestions. This matters because some app connectors may be known from loaded plugins even if they were not listed in the config file.

Data flow: The test writes a config with the Apps feature enabled, builds the config, creates dummy authentication and a plugin manager, and supplies one loaded plugin-app connector ID. It asks for discoverable tools and expects a DiscoverableTool created from that connector ID.

Call relations: The async test runner invokes this test. It follows the same authenticated suggestion-listing path as the fallback test, but the important input here is the loaded_plugin_app_connector_ids list.

Call graph: calls 2 internal fn (new, create_dummy_chatgpt_auth_for_testing); 5 external calls (assert_eq!, default, write, tempdir, vec!).

fn build_request_plugin_install_elicitation_request_uses_expected_shape()

Purpose: This test proves that a connector install suggestion becomes the exact approval request the system expects. It uses a Google Calendar connector example to make sure the request includes the right message, thread information, server name, and connector metadata.

Data flow: The test starts with install arguments and a sample connector record. It passes those into the request-building function along with a server name, thread id, turn id, and user-facing reason. The result is compared with a fully written-out expected request, so any missing field, wrong value, or changed structure makes the test fail.

Call relations: During the test run, Rust’s test runner calls this function. The function creates the connector example, calls the production request builder from the surrounding module, and then hands the result to an equality assertion to confirm that connector install requests keep their agreed contract.

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

fn build_request_plugin_install_elicitation_request_injects_plugin_metadata()

Purpose: This test checks the plugin version of the install approval request. It makes sure plugin-only details, such as the remote plugin id and linked connector ids, are included in the request metadata.

Data flow: The test builds install arguments and a sample plugin record with a name, remote plugin id, MCP server names, and app connector ids. It feeds that data into the request-building function. The produced request is then compared against the expected request, including the plugin metadata that should be embedded inside the form.

Call relations: The test runner calls this test as part of the suite. Inside, the test constructs a plugin example, asks the production request builder to turn it into an approval form, and uses an equality assertion to catch any accidental loss or renaming of plugin-specific metadata.

Call graph: 4 external calls (new, assert_eq!, Plugin, vec!).

fn build_request_plugin_install_meta_uses_expected_shape()

Purpose: This test focuses just on the metadata object used inside an install approval request. It verifies that connector metadata is packaged with the correct approval kind, persistence setting, tool identity, install URL, and suggestion reason.

Data flow: The test creates a Gmail connector example and passes it, along with the tool type, action type, and suggestion reason, into the metadata-building function. The returned metadata object is compared with the exact expected metadata. The output should contain connector fields and leave plugin-only fields empty.

Call relations: This test is called by the test runner. It exercises the lower-level metadata builder directly, instead of checking the larger request wrapper, so failures point more clearly to the metadata construction step.

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

fn verified_connector_install_completed_requires_accessible_connector()

Purpose: This test checks the rule for deciding whether one connector installation is complete. A connector only counts as complete if its id appears in the list of accessible connectors.

Data flow: The test starts with a list containing one accessible connector, Google Calendar. It asks the verification helper about the matching id, which should return true, and then about a missing Gmail id, which should return false. Nothing is changed; the test only checks the yes-or-no answers.

Call relations: The test runner calls this function. The function exercises the connector verification helper and uses assertions to confirm both the successful case and the missing-connector case, which are the two important branches of the rule.

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

fn all_requested_connectors_picked_up_requires_every_expected_connector()

Purpose: This test checks the rule for deciding whether a set of requested connectors has all been picked up after installation. It must not succeed when even one requested connector is missing.

Data flow: The test creates a list with one accessible connector, then checks two requested-connector lists. When the requested list only contains Calendar, the helper should return true. When the requested list contains Calendar and Gmail, the helper should return false because Gmail is not accessible.

Call relations: The test runner calls this test during the suite. The test calls the group-checking helper and uses assertions to show that it depends on every requested connector being present, not merely one of them.

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

fn make_skill(name: &str, path: &str) -> SkillMetadata

Purpose: Creates a small fake SkillMetadata record for tests. It lets each test describe a skill by just giving a name and path, instead of repeating all the boilerplate fields every time.

Data flow: It takes a skill name and a path string. It fills in a complete skill metadata object, including a generated description, a test absolute path, user scope, and empty optional fields. The output is a ready-to-compare fake skill record.

Call relations: Most collection tests call this first to build the available skills list. It relies on the test path helper to turn simple path text into the path type used by the real code, then hands those skill records to collect_mentions.

Call graph: called by 13 (collect_explicit_skill_mentions_allows_explicit_path_with_connector_conflict, collect_explicit_skill_mentions_dedupes_by_path, collect_explicit_skill_mentions_prefers_linked_path_over_name, collect_explicit_skill_mentions_prefers_resource_path, collect_explicit_skill_mentions_prioritizes_structured_inputs, collect_explicit_skill_mentions_skips_ambiguous_name, collect_explicit_skill_mentions_skips_disabled_structured_and_blocks_plain_fallback, collect_explicit_skill_mentions_skips_invalid_structured_and_blocks_plain_fallback, collect_explicit_skill_mentions_skips_missing_path_with_no_fallback, collect_explicit_skill_mentions_skips_missing_path_without_fallback (+3 more)); 2 external calls (test_path_buf, format!).

fn set(items: &'a [&'a str]) -> HashSet<&'a str>

Purpose: Turns a short list of expected strings into a set, so tests can compare mention results without caring about order.

Data flow: It receives a slice of string references. It copies those references into a HashSet, which keeps one copy of each item. The returned set is used as the expected names or paths in assertions.

Call relations: It supports assert_mentions. The mention extractor returns sets, so this helper builds matching expected sets for clean test comparisons.

fn assert_mentions(text: &str, expected_names: &[&str], expected_paths: &[&str])

Purpose: Checks that mention extraction found exactly the expected skill names and linked paths in a piece of text.

Data flow: It takes input text plus expected names and paths. It runs the real extract_tool_mentions logic, converts the expected values into sets, and compares both sides. If anything differs, the test fails with a readable assertion.

Call relations: All the extract_tool_mentions_* tests use this as their shared checker. It hides repetitive assertion setup so each test can focus on one rule about mention syntax.

Call graph: called by 6 (extract_tool_mentions_handles_plain_and_linked_mentions, extract_tool_mentions_keeps_plugin_skill_namespaces, extract_tool_mentions_requires_link_syntax, extract_tool_mentions_skips_common_env_vars, extract_tool_mentions_stops_at_non_name_chars, extract_tool_mentions_trims_linked_paths_and_allows_spacing); 1 external calls (assert_eq!).

fn linked_skill_mention(name: &str, unix_path: &str) -> String

Purpose: Builds a Markdown-style linked skill mention for tests, such as [$alpha](/tmp/alpha). This keeps linked mention examples consistent across tests.

Data flow: It receives a skill name and a Unix-style path string. It converts the path through the test path helper and formats the name and path into link text. The output is a string that can be inserted into fake user text.

Call relations: Several selection tests use this to create explicit path mentions. Those texts are then passed through collect_mentions to check whether path-based selection beats name-based guessing.

Call graph: called by 1 (collect_explicit_skill_mentions_dedupes_by_path); 1 external calls (format!).

fn collect_mentions(
    inputs: &[UserInput],
    skills: &[SkillMetadata],
    disabled_paths: &HashSet<AbsolutePathBuf>,
    connector_slug_counts: &HashMap<String, usize>,
) -> Vec<SkillMetadata>

Purpose: Provides a short test wrapper around the real collect_explicit_skill_mentions function. It makes the tests easier to read by giving the main operation a compact name.

Data flow: It receives user inputs, available skills, disabled skill paths, and connector name counts. It passes them straight into the real collection function. The output is the list of selected skill metadata records.

Call relations: The skill-selection tests call this after building fake inputs and skills. It is the bridge between the test setup and the production logic being checked.

Call graph: called by 13 (collect_explicit_skill_mentions_allows_explicit_path_with_connector_conflict, collect_explicit_skill_mentions_dedupes_by_path, collect_explicit_skill_mentions_prefers_linked_path_over_name, collect_explicit_skill_mentions_prefers_resource_path, collect_explicit_skill_mentions_prioritizes_structured_inputs, collect_explicit_skill_mentions_skips_ambiguous_name, collect_explicit_skill_mentions_skips_disabled_structured_and_blocks_plain_fallback, collect_explicit_skill_mentions_skips_invalid_structured_and_blocks_plain_fallback, collect_explicit_skill_mentions_skips_missing_path_with_no_fallback, collect_explicit_skill_mentions_skips_missing_path_without_fallback (+3 more)).

fn text_mentions_skill_requires_exact_boundary()

Purpose: Verifies that a plain $skill-name mention only matches when the skill name ends at a real boundary. This prevents $notion-research-doc from accidentally matching inside $notion-research-docs.

Data flow: It feeds several example strings and one target skill name into text_mentions_skill. It expects true for clean mentions surrounded by punctuation or parentheses, and false for longer words that merely start with the same text.

Call relations: This directly exercises the low-level text matching rule. It protects later selection logic from receiving false matches caused by partial names.

Call graph: 1 external calls (assert_eq!).

fn text_mentions_skill_handles_end_boundary_and_near_misses()

Purpose: Checks that a skill mention at the very end of text is still valid, while similar longer names are not. It also confirms that a later correct mention is found even after an earlier near miss.

Data flow: It sends short text examples to text_mentions_skill with alpha-skill as the target. The function under test returns booleans, and the test compares them to the expected true or false values.

Call relations: This adds coverage for edge cases around the end of the string and repeated scanning. It supports confidence that plain-text mention detection behaves predictably.

Call graph: 1 external calls (assert_eq!).

fn text_mentions_skill_handles_many_dollars_without_looping()

Purpose: Makes sure the matcher does not get stuck or behave badly when the text contains many dollar signs. This guards against a small parsing bug becoming a hang or slowdown.

Data flow: It creates a string with 256 dollar signs followed by ordinary text. It asks whether that text mentions alpha-skill, and expects false. Nothing is selected or changed; the important result is that the check finishes normally.

Call relations: This stress-style test exercises text_mentions_skill on unusual input. It is separate from normal matching tests because its main concern is safe progress, not finding a valid skill.

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

fn extract_tool_mentions_handles_plain_and_linked_mentions()

Purpose: Confirms that mention extraction sees both simple $alpha mentions and linked [$beta](/tmp/beta) mentions. It also checks that the linked path is captured.

Data flow: It passes one sentence containing both mention styles into assert_mentions. The expected output is two names, alpha and beta, plus the linked path /tmp/beta.

Call relations: This calls the shared assertion helper, which calls the real extractor. It establishes the basic behavior that the later, more specific extraction tests refine.

Call graph: calls 1 internal fn (assert_mentions).

fn extract_tool_mentions_skips_common_env_vars()

Purpose: Checks that common environment variable names like $PATH, $HOME, and $XDG_CONFIG_HOME are not treated as skill requests. Environment variables are operating-system placeholders, not skill names.

Data flow: It sends texts containing environment-variable-looking tokens and real skill mentions into assert_mentions. The expected results include only real skill names like alpha or beta, and no path for [$HOME](/tmp/skill).

Call relations: This protects extract_tool_mentions from over-reading normal shell-style text. It uses the shared helper so the test stays focused on the ignore list behavior.

Call graph: calls 1 internal fn (assert_mentions).

fn extract_tool_mentions_requires_link_syntax()

Purpose: Verifies that paths are only collected when the mention is a proper Markdown-style link. A name and a path sitting near each other should not be treated as a linked skill path.

Data flow: It tests examples like [beta](/tmp/beta), [$beta] /tmp/beta, and [$beta](). The extractor should find $beta as a name where appropriate, but it should not record a usable path unless the link syntax and path are valid.

Call relations: This calls assert_mentions, which checks the real extractor. It narrows the meaning of “linked path” so path-based selection only happens when the user clearly supplied one.

Call graph: calls 1 internal fn (assert_mentions).

fn extract_tool_mentions_trims_linked_paths_and_allows_spacing()

Purpose: Checks that linked skill mentions still work when users include extra spaces around the parentheses or path. This makes the parser forgiving without changing the meaning.

Data flow: It passes text like [$beta] ( /tmp/beta ) into assert_mentions. The expected result is name beta and clean path /tmp/beta, with surrounding spaces removed.

Call relations: This exercises the extractor through the shared assertion helper. It ensures later path-based skill selection can work even with slightly messy but understandable user formatting.

Call graph: calls 1 internal fn (assert_mentions).

fn extract_tool_mentions_stops_at_non_name_chars()

Purpose: Verifies where a plain mention name ends. For example, $alpha.skill should mention alpha, while underscores remain part of names like beta_extra.

Data flow: It gives the extractor text containing punctuation and underscore examples. The expected name set shows which characters are accepted as part of a mention and where parsing stops.

Call relations: This calls assert_mentions to check the extractor. It documents the name-character rules that feed into skill matching.

Call graph: calls 1 internal fn (assert_mentions).

fn extract_tool_mentions_keeps_plugin_skill_namespaces()

Purpose: Checks that namespaced plugin skill names such as $slack:search are preserved as one mention. The colon matters because it separates a plugin or connector namespace from the skill action.

Data flow: It passes text containing $slack:search and $alpha into the extraction checker. The expected names are exactly slack:search and alpha, with no paths.

Call relations: This uses assert_mentions to exercise the real extractor. It protects plugin-style skill naming from being split or truncated.

Call graph: calls 1 internal fn (assert_mentions).

fn collect_explicit_skill_mentions_text_respects_skill_order()

Purpose: Ensures that plain text mentions do not reorder selected skills based on where they appear in the sentence. The existing available-skills order remains the deciding order.

Data flow: It creates two fake skills in the order beta then alpha, while the text mentions alpha first and beta second. After collection, the expected selected list is still beta then alpha.

Call relations: This builds skills with make_skill, calls collect_mentions, and compares the result. It checks that the collection layer preserves its established ordering behavior instead of following text order.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_prioritizes_structured_inputs()

Purpose: Checks that a structured skill input is treated as more explicit than a plain text mention. Structured input means the system has already received a separate skill name and path, not just words in a sentence.

Data flow: It prepares text asking for alpha and a structured input naming beta with its path. Collection returns beta first, then alpha, showing that the structured request gets priority.

Call relations: The test uses make_skill for setup and collect_mentions for the real selection step. It documents how mixed input types are combined.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_skips_invalid_structured_and_blocks_plain_fallback()

Purpose: Verifies that a bad structured skill reference blocks fallback to a plain text mention of the same skill. This avoids silently doing something different from the explicit structured request.

Data flow: It creates one real alpha skill at /tmp/alpha, then supplies text mentioning alpha and a structured skill input pointing alpha at /tmp/missing. Collection returns an empty list because the structured path is invalid and the plain mention is not used as a backup.

Call relations: This calls make_skill and then collect_mentions. It checks a safety rule in the collection logic: an explicit but invalid path should not be ignored in favor of a looser name match.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_skips_disabled_structured_and_blocks_plain_fallback()

Purpose: Checks that a disabled skill is not selected, even when both structured input and plain text mention it. It also confirms that disabling blocks fallback behavior.

Data flow: It creates alpha, marks alpha’s path as disabled, and supplies both text and structured input for alpha. Collection returns no skills.

Call relations: The test builds the disabled path set with the test path helper, then calls collect_mentions. It protects the rule that disabled skills stay disabled no matter how they are mentioned.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 5 external calls (new, from, assert_eq!, test_path_buf, vec!).

fn collect_explicit_skill_mentions_dedupes_by_path()

Purpose: Ensures that mentioning the same linked skill path more than once selects the skill only once. This prevents duplicate injections of the same skill.

Data flow: It creates one alpha skill and user text containing the same linked mention twice. Collection returns a one-item list containing alpha.

Call relations: It uses linked_skill_mention to build repeated link text, then sends it through collect_mentions. It checks that the collector treats the path as the identity for removing duplicates.

Call graph: calls 3 internal fn (collect_mentions, linked_skill_mention, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_skips_ambiguous_name()

Purpose: Verifies that a plain name mention is ignored when more than one skill has that same name. The system should not guess between two possible paths.

Data flow: It creates two skills both named demo-skill but with different paths. Text mentions $demo-skill, and collection returns an empty list because the name alone is ambiguous.

Call relations: This uses make_skill to set up the ambiguity and collect_mentions to test the real behavior. It supports the broader safety rule that unclear user requests should not activate a random skill.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_prefers_linked_path_over_name()

Purpose: Checks that an explicit linked path wins over an ambiguous plain name. If the user gives the exact path, the system can choose the right skill even when names collide.

Data flow: It creates two demo-skill records with different paths. The text includes both a plain $demo-skill and a linked mention pointing to beta’s path. Collection returns only beta.

Call relations: The test combines linked_skill_mention, make_skill, and collect_mentions. It shows how the collection logic resolves ambiguity when a path gives a precise answer.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_skips_plain_name_when_connector_matches()

Purpose: Ensures that a plain $alpha-skill mention is not treated as a skill when a connector with the same name exists. This avoids choosing the skill when the user might have meant the connector.

Data flow: It creates one alpha skill and a connector-name count saying alpha-skill exists as a connector. The text mentions $alpha-skill, and collection returns no selected skills.

Call relations: This test passes connector conflict information into collect_mentions. It checks the collector’s caution around names shared by different capability types.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (from, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_allows_explicit_path_with_connector_conflict()

Purpose: Checks that a connector name conflict does not block a skill when the user provides an explicit linked path. The path removes the uncertainty.

Data flow: It creates alpha and a connector-name conflict for alpha-skill. The user text contains a linked mention pointing to alpha’s exact path. Collection returns alpha.

Call relations: This uses the same connector conflict setup as the plain-name conflict test, but with a path-based mention. Through collect_mentions, it confirms that precise linked paths are allowed.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (from, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_skips_when_linked_path_disabled()

Purpose: Verifies that a linked skill mention is ignored if the linked path is disabled. Even an exact path should not override a disabled setting.

Data flow: It creates two same-named skills, links to alpha’s path in the text, and marks alpha’s path as disabled. Collection returns no selected skills.

Call relations: The test builds skills with make_skill, creates the disabled path set, and calls collect_mentions. It confirms that the disabled list is enforced after path resolution.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 5 external calls (new, from, assert_eq!, test_path_buf, vec!).

fn collect_explicit_skill_mentions_prefers_resource_path()

Purpose: Checks that when a linked path matches one of several same-named skills, that path chooses the matching skill. This is another direct test of path-based disambiguation.

Data flow: It creates two demo-skill records at different paths and text linking to beta’s path. Collection returns beta.

Call relations: This is centered on collect_mentions, with setup from make_skill and linked mention formatting. It reinforces that the resource path is the strongest clue for selecting a skill.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_skips_missing_path_with_no_fallback()

Purpose: Ensures that a linked mention to a missing path does not fall back to a same-named skill. A wrong explicit path is treated as wrong, not as a hint to guess.

Data flow: It creates two demo-skill records but links to /tmp/missing. Collection finds no skill at that path and returns an empty list.

Call relations: This calls collect_mentions after creating ambiguous same-name skills. It protects the rule that explicit path mentions must match a known skill path.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn collect_explicit_skill_mentions_skips_missing_path_without_fallback()

Purpose: Checks the same missing-path rule when there is only one skill with that name. Even without ambiguity, the collector should not ignore an invalid linked path and select by name instead.

Data flow: It creates one demo-skill at /tmp/alpha and text linking demo-skill to /tmp/missing. Collection returns no skills.

Call relations: This final selection test uses make_skill and collect_mentions. It confirms that exact linked path requests are strict in both ambiguous and non-ambiguous cases.

Call graph: calls 2 internal fn (collect_mentions, make_skill); 4 external calls (new, new, assert_eq!, vec!).

fn test_skill_metadata(skill_doc_path: AbsolutePathBuf) -> SkillMetadata

Purpose: Creates a small, predictable fake SkillMetadata record for tests. The tests use it so they do not need to repeat all the fields required to describe a skill.

Data flow: It receives the path to a fake SKILL.md file. It puts that path into a SkillMetadata value, fills the name and description with simple test text, leaves optional fields empty, and returns the completed fake skill record.

Call relations: The document-read and script-run tests call this helper while setting up their fake skill inventory. It gives those tests a known skill named test-skill, so they can later check that the detection code found the expected skill.

Call graph: called by 4 (skill_doc_read_detection_matches_absolute_path, skill_doc_read_detection_matches_shared_read_parser, skill_script_run_detection_matches_absolute_path_from_any_workdir, skill_script_run_detection_matches_relative_path_from_skill_root).

fn test_path_display(unix_path: &str) -> String

Purpose: Turns a Unix-style test path string into the display form used by the current test environment. This keeps the tests portable instead of assuming that paths are printed the same way everywhere.

Data flow: It receives a path written as a string, builds a test path object from it, converts that path to its printable display text, and returns the resulting string.

Call relations: Tests use this helper when they need to put a path into a fake command token list. It relies on the shared test path builder, then hands the formatted path text to the detection functions as if it had come from a shell command.

Call graph: 1 external calls (test_path_buf).

fn script_run_detection_matches_runner_plus_extension()

Purpose: Checks that a command using a script runner and a script-looking filename is recognized as a script run. In this case, python3 is the runner and fetch_comments.py is the script file.

Data flow: It builds a list of command tokens: python3, an option, and a .py script path. It passes those tokens to script_run_token, then checks that the result is present rather than empty.

Call relations: This test directly exercises the low-level script-run recognizer. It confirms that later, higher-level skill matching has a script path to work with when a command looks like a normal script execution.

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

fn script_run_detection_excludes_python_c()

Purpose: Checks that inline Python code is not mistaken for running a script file. The command python3 -c print(1) runs code supplied on the command line, not a file from a skill’s scripts folder.

Data flow: It builds tokens for python3 -c print(1), sends them to script_run_token, and checks that no script token is returned.

Call relations: This test guards against a false positive in the script-run recognizer. It matters because the broader skill detection should only connect commands to skills when an actual script file path is present.

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

fn skill_doc_read_detection_matches_absolute_path()

Purpose: Checks that reading a skill document by its full path is linked back to the correct skill. This covers commands such as cat /tmp/skill-test/SKILL.md.

Data flow: It creates a fake skill whose document is at an absolute path, normalizes that path, and stores the skill in the fake loaded-skill outcome under that document path. It then builds command tokens for reading that document and passes them, along with a working directory, to detect_skill_doc_read. The expected output is the fake skill named test-skill.

Call relations: This test uses test_skill_metadata to build the skill record and then calls the document-read detector. It proves that the detector can look at command tokens, compare the path against the known skill-document map, and return the matching skill.

Call graph: calls 1 internal fn (test_skill_metadata); 9 external calls (new, default, from, new, assert_eq!, test_path_buf, canonicalize_if_exists, detect_skill_doc_read, vec!).

fn skill_doc_read_detection_matches_shared_read_parser()

Purpose: Checks that the skill document detector works with a shared parser for common file-reading commands, not just one hard-coded command. Here it uses nl, a command that prints files with line numbers.

Data flow: It sets up the same kind of fake skill and normalized SKILL.md path as the other document-read test. It then builds tokens for nl -ba /tmp/skill-test/SKILL.md, runs detect_skill_doc_read, and expects to get back the fake skill named test-skill.

Call relations: This test again uses test_skill_metadata for setup, then sends the command tokens into the document-read detector. It confirms that the detector’s file-reading logic is shared broadly enough to catch different tools that read a SKILL.md file.

Call graph: calls 1 internal fn (test_skill_metadata); 9 external calls (new, default, from, new, assert_eq!, test_path_buf, canonicalize_if_exists, detect_skill_doc_read, vec!).

fn skill_script_run_detection_matches_relative_path_from_skill_root()

Purpose: Checks that running a skill script by a path relative to the skill’s root folder is recognized. For example, from inside the skill folder, python3 scripts/fetch_comments.py should point to that skill.

Data flow: It creates a fake skill, records the normalized scripts directory for that skill, and builds command tokens with a relative script path. It calls detect_skill_script_run with the working directory set to the skill root. The detector should combine the working directory and relative path, match it to the known scripts directory, and return the fake skill.

Call relations: This test uses test_skill_metadata while preparing the fake loaded-skill outcome, then calls the script-run detector. It verifies the everyday case where a user is already inside the skill folder and runs a script with a short relative path.

Call graph: calls 1 internal fn (test_skill_metadata); 9 external calls (new, default, from, new, assert_eq!, test_path_buf, canonicalize_if_exists, detect_skill_script_run, vec!).