Windows Codex Desktop App 26.506.3741.0: Chrome/browser-use/terminal regressions

[richie-liu512]

Summary

I am seeing several Windows-only issues in Codex Desktop App 26.506.3741.0 that appear related to plugin/runtime/tool exposure and the embedded terminal.

Environment:

• OS: Windows
• Codex Desktop App: Microsoft Store / MSIX package
• Package: OpenAI.Codex 26.506.3741.0
• Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• Shell used for checks: Windows PowerShell 5.1 (5.1.26100.8115)
• Chrome extension status: shows Connected

I am filing these together because they all affect the Windows Desktop App workflow and may share sandbox/plugin/runtime causes.

---

1. Chrome plugin is connected, but Codex opens/uses a blank Chrome instead of the existing/default Chrome profile

What I expected

When using the Codex Chrome plugin, Codex should be able to use the connected Chrome extension/session or at least a Chrome window using my real Chrome profile, cookies, extensions, bookmarks, and login state.

What happens

The Chrome extension shows Connected, but when Codex tries to use Chrome it opens a new/blank Chrome instance with no bookmarks, no extensions, and no login state. It behaves like an isolated/sandboxed blank profile rather than the existing/default browser.

Notes

This is on the Microsoft Store/MSIX build. It looks like Chrome launched from Codex may inherit MSIX/sandbox isolation and cannot see the normal user profile.

---

2. Embedded PowerShell terminal paste duplicates text

Repro

1. Open Codex Desktop App on Windows.
2. Open the embedded PowerShell terminal.
3. Copy a small string, e.g. test.
4. Paste with keyboard shortcut or context-menu/right-click paste.

Expected

Text is pasted once.

Actual

Text is pasted twice in the embedded terminal.

This happens inside Codex's terminal, not in normal external PowerShell/Windows Terminal.

---

3. Running Codex as administrator breaks Ctrl+C behavior

Repro

1. Run Codex Desktop App as Administrator.
2. Try using Ctrl+C in the Codex app / terminal context.

Expected

Ctrl+C should work normally according to the focused UI context, or at least behave consistently with non-admin mode.

Actual

Ctrl+C stops working / is not handled as expected while other shortcuts still work.

---

4. Browser Use plugin appears enabled in Settings and @ menu, but the browser-use tool is not exposed to the agent

This is the most recent and most reproducible issue.

Initial state

Settings > Browser showed:

in-app browser plugin unavailable

Plugins search could not find Browser / browser-use.

Investigation

The app package contains browser-use:

C:\Program Files\WindowsApps\OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\browser-use

Important files found:

• .codex-plugin\plugin.json
• scripts\browser-client.mjs
• skills\browser\SKILL.md

The plugin metadata includes:

{
  "name": "browser-use",
  "version": "0.1.0-alpha2",
  "description": "Browser / browser-use plugin\n\nAliases: @browser, @browser-use, browser-use, Browser, in-app browser...",
  "skills": "./skills/",
  "interface": {
    "displayName": "Browser",
    "shortDescription": "Control the in-app browser with Codex"
  }
}

User plugin cache contains:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser-use
%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\0.1.7

cipher /c reports the cache directories as unencrypted (U).

config.toml originally contained:

[marketplaces.openai-bundled]
last_updated = "2026-05-09T00:00:00Z"
source_type = "local"
source = '\\?\C:\Program Files\WindowsApps\OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled'

[plugins."chrome@openai-bundled"]
enabled = true

After adding:

[plugins."browser-use@openai-bundled"]
enabled = true

Settings > Browser now shows Browser Use and the toggle is enabled. The @ plugin picker also shows Browser / Chrome.

Repro after enabling

1. Fully quit and restart Codex.
2. Open a new thread.
3. Select Browser from the @ menu.
4. Ask:

@Browser open https://example.com. Do not use PowerShell, Start-Process, or the system default browser; use only the Codex in-app browser. If the tool is not exposed, say so.

Actual

Codex replies that the tool is not exposed / it does not have the browser-use or Codex in-app browser control tool available. It falls back to PowerShell / Start-Process when not explicitly forbidden.

Expected

The Browser Use tool should be exposed to the agent/runtime, allowing Codex to control the in-app browser as described by the plugin and docs.

Additional note

Ctrl+Shift+B can manually open the in-app browser, so the UI/browser panel exists. The problem is specifically that the agent runtime does not receive the browser automation tool.

---

Request

Could the Codex team please clarify:

1. Is Windows/MSIX expected to support using the connected Chrome extension with the user's existing Chrome profile/session, or does it intentionally launch an isolated Chrome profile?
2. Is Browser Use automation currently supported on Windows Desktop App 26.506.3741.0, or only the manual in-app browser panel?
3. Why can Browser Use appear in Settings and the @ menu while the actual browser-use tool is not exposed to the agent?
4. Is there a recommended config/cache repair procedure for openai-bundled plugins on Windows?
5. Are the embedded terminal paste duplication and admin Ctrl+C issues known regressions in the Windows desktop app?

Thanks.