Chrome Skill cache and marketplace instructions disagree on browser-client entrypoint

What version of the Codex App are you using?

I could not reliably copy the desktop app build from the session. The local CLI reports:

codex-cli 0.128.0

Chrome plugin metadata found locally:

chrome@openai-bundled 0.1.7

What subscription do you have?

Unknown / not relevant to the local reproduction.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0

What issue are you seeing?

The Chrome Skill is visible in the Codex UI, but the local Chrome plugin/skill files appear to be inconsistent between the cached plugin copy and the bundled marketplace copy. This made the agent initially fail to use Chrome even though the Chrome extension itself could be reached once the trusted marketplace path and the correct setup function were used.

Two local Chrome plugin copies were present:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\0.1.7\...
%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\...

The cached SKILL.md instructs the agent to use setupAtlasRuntime:

const { setupAtlasRuntime } = await import("<plugin root>/scripts/browser-client.mjs");
await setupAtlasRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get("extension");

However, loading the cached browser-client.mjs fails with:

privileged native pipe bridge is not available; browser-client is not trusted. Load browser-client from the openai-bundled marketplace directory.

After switching to the trusted bundled-marketplace path, following the cached skill instructions still fails because the marketplace browser-client.mjs does not export setupAtlasRuntime:

setupAtlasRuntime is not a function

The bundled-marketplace SKILL.md and browser-client.mjs use/export setupBrowserRuntime instead:

const { setupBrowserRuntime } = await import("<plugin root>/scripts/browser-client.mjs");
await setupBrowserRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get("extension");

Using setupBrowserRuntime from the bundled-marketplace path succeeded and returned a Chrome backend with metadata including the Codex Chrome extension id and profile metadata. At that point browser.user.openTabs() worked.

A related observation: the Chrome Skill was visible in the UI skill modal, but it was not surfaced to the active model context/tool discovery in the same way as the other listed skills. The agent had to find the Chrome skill files by searching the local .codex directories manually.

What steps can reproduce the bug?

1. On Windows, install/enable the Codex Chrome plugin and Codex Chrome Extension.
2. Open a Codex session where Chrome Skill is visible in the UI.
3. Attempt to use the Chrome Skill from the active session.
4. Observe that the cached Chrome Skill instructions point to setupAtlasRuntime under %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\0.1.7\skills\chrome\SKILL.md.
5. Try importing browser-client.mjs from the cached plugin path.
6. Observe the trust error telling the agent to use the openai-bundled marketplace directory.
7. Switch to %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\scripts\browser-client.mjs.
8. Follow the cached instructions and call setupAtlasRuntime.
9. Observe setupAtlasRuntime is not a function.
10. Call setupBrowserRuntime from the bundled-marketplace path instead.
11. Observe that Chrome connection succeeds and browser.user.openTabs() works.

What is the expected behavior?

The Chrome Skill instructions visible/available to the agent should match the trusted browser-client.mjs entrypoint that the runtime expects.

Specifically:

• The skill/docs used by the agent should point to the trusted bundled-marketplace browser-client path when that is required.
• The setup function name in the active skill docs should match the exported function (setupBrowserRuntime in this environment).
• If the cache copy is stale or untrusted, it should not be the copy that instructs the agent.
• If Chrome Skill is visible in the UI, it should be discoverable/available to the model consistently enough that the agent does not have to search .codex internals manually.

Additional information

Existing related issues found before filing:

• #21781 reports browser-client is not trusted on Windows.
• #21852 mentions the older cached browser-client path reporting the trust error and the bundled-marketplace path working.
• #23302 reports a similar trust bridge error in a remote/mobile-started thread.

This issue is narrower: even after switching to the trusted bundled-marketplace path, the cached Chrome Skill instructions and the trusted marketplace runtime disagree on the setup function name (setupAtlasRuntime vs setupBrowserRuntime), which leads the agent down a failing path before discovering the workaround.