[Windows] Chrome control repeatedly breaks after updates: bundled CUA does not apply proxy settings #46386

Control of local Chrome regularly stops working in the ChatGPT/Codex Windows desktop app. Over the past few days, the same cycle has been repeating: browser access is restored, the next update replaces the browser-control component, and access breaks again.

Please fix this at the application level so that proxy support works out of the box and survives updates.

Latest confirmed incident — September 18, 2026:

• Application: OpenAI.Codex 26.915.3509.0.
• Plugin: unified-computer-use 26.915.31029.
• Bundled Node.js: v24.21.0.
• Chrome runs on the same computer, using the existing user profile.
• Internet access is configured through Hiddify in system proxy mode.

When attempting to retrieve the browser state, the tool returns:

Unexpected token '<', "<html>..." is not valid JSON

A similar failure was resolved on September 17 with application version 26.911.7940.0 and plugin version 26.911.61220. The problem returned after the next update.

Diagnostic findings. The working proxy and Windows user settings remained intact. However, the update installed a new runtime containing the original cua-repl.mjs, without the previously applied workaround. The generated configuration for the bundled MCP server did not include forwarding of the required proxy environment variables.

Meanwhile, the browser-control component makes requests to external ChatGPT services. The installed code includes, in particular, a request to /backend-api/aura/identity, followed by parsing the response as JSON. A healthy local Chrome instance therefore does not guarantee that the tool will work: its service requests also need to use the correct network configuration.

These observations point to a problem with forwarding or applying proxy settings in the bundled component. This is consistent with the documented mechanism for explicitly passing environment variables through MCP env / env_vars. MCP documentation.

Temporary recovery. We explicitly set HTTP_PROXY, HTTPS_PROXY, NO_PROXY, and NODE_USE_ENV_PROXY=1 in the component's launcher, then fully restart the application. Chrome control works again afterwards. However, the next runtime is installed into a new directory, and this workaround no longer takes effect.

I understand that updates replace bundled files. The problem is that using a built-in feature requires editing those files in the first place.

Expected fix:

1. Consistent network settings across the application and its bundled components. Browser/CUA service requests should use the proxy configuration supported by the application. This could be implemented through a shared networking layer, or by explicitly passing the necessary settings to child processes and correctly initializing their HTTP clients.

2. Configuration that survives updates. Settings should be stored independently of versioned runtime directories and automatically applied to new versions. Users should not have to modify launchers, copy generated MCP configurations, or pin paths to old runtimes.

3. Connection recovery without restarting the entire application. After a temporary network failure or proxy recovery, the component should be able to reconnect. There should also be a way to restart only the browser integration while keeping other tasks running. Reconnection attempts should use the current network settings.

4. Actionable diagnostics. Failures in the local connection to Chrome should be distinguished from failures in requests to ChatGPT servers. Instead of a JSON parsing error caused by an HTML page, the tool should report a clear reason, the HTTP status, and the stage at which the failure occurred.

5. Regression coverage before releasing updates. This needs a Windows test with a working HTTP proxy, a restricted child-process environment, and replacement of the bundled runtime: after the update, control of the existing Chrome instance should continue working without manual repairs.

A related problem with cua_repl configuration being reset has already been reported in issue #42454. My case demonstrates the practical impact on the bundled browser integration on Windows.

Impact on my work. Browser access is failing almost every day. Each time, I have to interrupt my tasks and spend time and agent usage limits investigating the cause, repeating diagnostics, and restoring access. My usage allowance is being consumed by repairing the tool itself instead of doing my work. Restarting the entire application also disrupts parallel tasks.

The browser integration needs to work reliably, retain its network settings, and survive updates without repeated manual repairs.