Codex agent accidentally triggered Chrome plugin install prompt while trying to request filesystem permission.

Open 💬 0 comments Opened May 17, 2026 by warenhubner

What version of the Codex App are you using (From “About Codex” dialog)?

Codex 26.513.31313

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

While using Codex desktop, the agent accidentally triggered an unrelated Chrome plugin install prompt while trying to continue a local filesystem cleanup task.

Context:

Codex App version: Codex 26.513.31313
Codex CLI version: codex-cli 0.130.0
Subscription: ChatGPT Plus
Platform: Microsoft Windows NT 10.0.26200.0 x64
Time: 2026-05-17 around 08:48-08:52 Asia/Jakarta (+07:00)

What I asked the agent to do:
Clean up duplicate HyperFrames plugin entries by keeping the local rich HyperFrames install and removing/disabling the duplicate hyperframes@openai-curated entry.

The intended local actions were:

Edit C:\Users\<USER>\.codex\config.toml
Remove C:\Users\<USER>\.codex\plugins\cache\openai-curated\hyperframes

What happened:

The agent verified both HyperFrames entries existed.
The agent attempted to edit config.toml, but the edit was blocked because C:\Users\<USER>\.codex was outside the normal writable workspace.
Instead of correctly requesting filesystem permission or stopping, the agent accidentally invoked the plugin install flow for chrome@openai-bundled.
This surfaced a user-facing prompt: “Install Chrome? Control Chrome with Codex.”
Chrome/browser control was unrelated to the HyperFrames cleanup task.

Expected behavior:
When filesystem access is blocked, the agent should either:

request the specific filesystem permission needed, or
stop and explain that it cannot proceed.

It should not trigger an unrelated plugin install prompt.

Impact:
This is confusing and potentially risky because a user could approve an unrelated plugin install while believing it is required for the original task.

What steps can reproduce the bug?

I do not know if this reproduces deterministically, but these were the steps in my session:

Start in Codex Desktop on Windows with a workspace at C:\Users\<USER>\Primary Intel.
Have two HyperFrames plugin entries present:

hyperframes@home-local
hyperframes@openai-curated

Ask the agent to clean up the duplicate HyperFrames install by:

keeping hyperframes@home-local
removing/disabling hyperframes@openai-curated
deleting C:\Users\<USER>\.codex\plugins\cache\openai-curated\hyperframes

The agent attempted to edit C:\Users\<USER>\.codex\config.toml.
The edit was blocked because .codex was outside the writable workspace.
The agent then attempted to request permission, but instead invoked the plugin-install flow for chrome@openai-bundled.
Codex displayed an unrelated prompt: “Install Chrome? Control Chrome with Codex.”

No browser or Chrome access was needed for the requested HyperFrames cleanup.

What is the expected behavior?

If the agent needs filesystem access to continue a task, it should request the specific filesystem permission needed or stop and explain that it cannot proceed.

It should not invoke an unrelated plugin-install flow.

In this case, the expected behavior was one of:

Request permission to edit/remove files under C:\Users\<USER>\.codex, specifically:

C:\Users\<USER>\.codex\config.toml
C:\Users\<USER>\.codex\plugins\cache\openai-curated\hyperframes

Or stop and explain that the cleanup could not continue because the required .codex write access was unavailable.

The agent should not show an “Install Chrome?” prompt because Chrome/browser control was unrelated to the task.

Additional information

I interrupted/stopped the agent after the unexpected Chrome plugin prompt appeared.

The agent later stated that the Chrome prompt was caused by an incorrect tool call: it used the plugin-install prompt mechanism for chrome@openai-bundled while trying to recover from a blocked filesystem edit. The agent confirmed Chrome/browser access was unrelated to the task.

Verified state after interruption:

The HyperFrames cleanup was not completed.
hyperframes@home-local was still present in C:\Users\<USER>\.codex\config.toml.
hyperframes@openai-curated was still present in C:\Users\<USER>\.codex\config.toml.
The duplicate curated cache folder still existed.
The local rich HyperFrames install still existed.

The concerning part is not just that the task failed, but that a user-facing install prompt for an unrelated plugin appeared during a filesystem cleanup flow. A user could reasonably think the Chrome install was required to continue the original task.

View original on GitHub ↗