Windows Codex desktop app leaves global proxy set to 127.0.0.1:22307 after elevated sandbox tool execution
What version of the Codex App are you using (From “About Codex” dialog)?
Desktop app version: OpenAI.Codex / ChatGPT 26.721.31836
What subscription do you have?
Plus
What platform is your computer?
Windows 11
What issue are you seeing?
Environment:
- OS: Windows 11
- Desktop app version: OpenAI.Codex / ChatGPT 26.721.31836
- Date observed: July 24, 2026
Summary:
The Windows Codex desktop app repeatedly changes the current user's global WinINET proxy settings to:
ProxyEnable = 1
ProxyServer = 127.0.0.1:22307
The proxy configuration is sometimes left behind after the local tool or proxy process stops responding. This causes browser network failures, severe system slowdown, application hangs, and, on several occasions, an inability to shut down or restart Windows normally.
This is reproducible without Git push, SSH, or any explicit proxy command.
Minimal reproduction:
- Fully exit the Codex/ChatGPT desktop app.
- Remove the proxy values and confirm that Windows proxy scanning is clean.
- In Codex settings, disable all plugins, apps, and MCP servers.
- Set the following in ~/.codex/config.toml:
[features.network_proxy]
enabled = false
- Restart the desktop app.
- Run one local read-only tool command that requires access outside the workspace.
- The first sandboxed read is denied or delayed.
- Approve the read-only permission escalation.
- Scan the Windows proxy configuration again.
Actual result:
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings is changed to:
ProxyEnable = 1
ProxyServer = 127.0.0.1:22307
Expected result:
A sandbox-local proxy must not modify or persist the current user's global Windows proxy configuration. Any temporary proxy configuration must be restored reliably after the tool finishes, fails, is denied, or the app exits.
Additional observations:
- The issue still occurs with plugins, apps, and MCP servers disabled.
- It still occurs when features.network_proxy.enabled is set to false.
- No Git, SSH, remote repository operation, proxy command, or network tool was used in the latest reproduction.
- Fully exiting the desktop app and removing the proxy restores normal browser access.
- Reopening the app and invoking local tools can cause the proxy entry to reappear.
- The behavior started after the desktop app update installed around July 22, 2026.
- Codex CLI 0.145.0 release notes mention Windows network-proxy enforcement and elevated sandbox changes, which may be related.
Impact:
- Browser and WinINET applications lose network access.
- Codex and other applications become unresponsive.
- The machine has required forced power-off multiple times.
- Continued use of local Codex tools is currently unsafe on this machine.
Please investigate whether elevated Windows sandbox initialization or cleanup is incorrectly writing the sandbox proxy into HKCU WinINET settings, and whether cleanup fails after denied, failed, timed-out, or interrupted tool executions.
sandbox.2026-07-23.log
sandbox.2026-07-24.log
<img width="865" height="440" alt="Image" src="https://github.com/user-attachments/assets/245561db-a608-465c-878e-27429adcf56a" />
<img width="865" height="816" alt="Image" src="https://github.com/user-attachments/assets/6c319bfb-dd77-47e2-8372-4c4511ac3a7a" />
What steps can reproduce the bug?
这次复现非常关键，已经证明：
• 关闭插件、应用、MCP无效。
• features.network_proxy.enabled=false 无效。
• Git、SSH和远程提交不是必要条件。
• 高概率触发点是 Codex桌面端的本地工具沙箱，尤其是权限升级执行。
本轮精确链路是：
- 配置已关闭 network_proxy。
- 插件、应用、MCP全部关闭。
- 我读取工作区外HTML文件。
- 第一次读取被沙箱拒绝并异常等待约26秒。
- 你批准只读权限升级后，读取成功。
- 随即检测到：
ProxyEnable=1
ProxyServer=127.0.0.1:22307
这与“elevated sandbox初始化或回收时错误写入用户全局代理”高度吻合。
可提交给 OpenAI 的最小复现已经很清楚：
Windows 11，ChatGPT/Codex桌面端 26.721.31836。已关闭所有插件、应用、MCP，并设置 features.network_proxy.enabled=false。系统代理清理后，执行一次需要权限升级的本地只读 Get-Content；首次沙箱读取被拒并延迟，批准升级读取后，HKCU立即出现 ProxyEnable=1、ProxyServer=127.0.0.1:22307。未执行Git、SSH、联网、代理设置或远程提交。
What is the expected behavior?
_No response_
Additional information
_No response_