[Windows][Dot] Local Codex browser works, Dot task cannot control it — any working recovery?

[thatissj]

I’m looking for a working recovery for browser/Computer Use in Dot-started Windows tasks. Has anyone fixed this on their PC?

What happens: the computer is online and Dot can run shell commands. An ordinary local Codex chat can open https://example.com/ and read “Example Domain”, but the affected Dot task cannot use browser/desktop control. Correlated logs show:

hostId=durable server=cua_repl status=failed error="MCP server failed to start." failureReason=null
hostId=durable server=codex_app status=failed error="MCP server failed to start." failureReason=null

Environment: Windows 11 x64 build 26200; Desktop 26.928.31416; MSIX 26.928.3736.0; CLI 0.159.2. The official updater says up_to_date; Full Access was selected.

Already tried: restart/reconnect, proxy/TUN repair, stale sandbox-cache repair, and correct MSIX activation. These restored connectivity/local execution, but no browser test through Dot has succeeded.

What I’m asking: if you have restored the browser in a Dot task, please share the working version and exact steps, and whether it survives restart/update. The SystemRoot workaround in #49820 reportedly restores app-control MCP; browser/CUA remains separate there, and I have not tested it here. Is there a separate browser recovery?

Related bug discussion: #49458. I also checked #49423. This Q&A is to collect practical recovery steps from other users; the root cause on this PC is still unconfirmed.

中文求助： 同一台 Windows 电脑，本机 Codex 可以控制浏览器，Dot 能执行命令却无法控制浏览器，两个相关 MCP 服务启动失败。连接、沙箱和启动入口已修复，问题仍在。有没有人真正恢复过 Dot 的浏览器控制？希望分享有效版本、具体操作，以及重启或更新后是否仍有效。

English report · 中文报告 · Download ZIP

Observed October 1, 2026. Private account details, paths and identifiers are omitted.