Computer Use runtime not exposed on Windows + /feedback does not open

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

Codex Desktop 26.611.8604.0 Session cli_version: 0.140.0-alpha.19

What subscription do you have?

ChatGPT pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Computer Use appears installed and enabled, but the visual runtime/tool bridge is not exposed to the model in Codex Desktop on Windows. When I mention @Computer / @Ordinateur, Codex detects the Computer Use plugin/skill, but cannot use visual Computer Use APIs. It falls back to shell commands such as Start-Process, notepad.exe, or firefox instead of controlling the UI visually.

Also, /feedback does not open the feedback dialog in this thread.

Environment

• Windows
• Codex Desktop package visible locally: OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0
• Session metadata shows cli_version: 0.140.0-alpha.19
• Computer Use plugin enabled: computer-use@openai-bundled
• Computer Use plugin version visible locally: 26.611.62324

Expected behavior

When I mention @Computer / @Ordinateur, Codex should expose and use the Computer Use visual runtime so it can list apps, capture windows, click, type, and inspect UI state.

Actual behavior

The Computer Use plugin is detected as a skill, but the expected runtime bridge is not available to the model. The agent reports that the node_repl/js bridge required by computer-use-client.mjs is not exposed. It then falls back to shell commands to open applications.

Examples:

• Asked to open Firefox with @Ordinateur
• Asked to open Notepad and type text
• Asked to use WhatsApp visually

In each case, Codex could only launch apps via shell or refused to continue because it could not visually inspect the app.

Checked

• computer-use@openai-bundled is enabled in ~/.codex/config.toml
• computer-use-client.mjs exists locally
• No requirements.toml disabling computer_use was found
• No local Computer Use deny config was found
• Restarting the PC did not fix it
• Reinstalling/reactivating the plugin did not fix it
• /feedback typed in Codex Desktop does not open the feedback dialog
• codex doctor --summary --ascii --no-color fails with Accès refusé

Impact

Computer Use cannot be used for visual desktop automation on Windows, even though the plugin appears installed and enabled.

What steps can reproduce the bug?

1. On Windows, install/enable the Computer Use plugin in Codex Desktop.
2. Start a new Codex Desktop thread.
3. Mention @Computer / @Ordinateur and ask it to open or visually control an app, for example:

• @Ordinateur ouvre Firefox
• @Ordinateur ouvre Notepad et écris bonjour

1. Observe that Codex reads the Computer Use skill/plugin instructions but cannot access the expected visual runtime bridge.
2. Codex falls back to shell commands such as Start-Process, firefox, or notepad.exe, or refuses to continue because it cannot visually inspect the target app.
3. Type /feedback in the same Codex Desktop thread.
4. Observe that the feedback dialog does not open.
5. Run codex doctor --summary --ascii --no-color from PowerShell.
6. Observe that it fails with Accès refusé.

What is the expected behavior?

When @Computer / @Ordinateur is mentioned in Codex Desktop, Codex should expose the Computer Use visual runtime tools to the model and use them to operate desktop apps visually.

Expected capabilities include:

• list available apps/windows
• capture target window state
• click/type/scroll via Computer Use
• inspect UI state before acting
• ask for app permissions when needed

Also, /feedback should open the feedback dialog and codex doctor should run or provide an actionable diagnostic error.

Additional information

This appears to be different from a simple app permission issue: the plugin is detected and the Computer Use skill is available, but the underlying runtime/tool bridge is not exposed to the model.

The issue persisted after:

• restarting Windows
• restarting Codex Desktop
• reinstalling/reactivating the Computer Use plugin

The thread can still run shell commands, so the failure seems specific to Computer Use runtime/tool injection rather than general local execution.