最近折腾了一下 Android 版 ChatGPT 里的 Codex 连接 Windows 桌面端，记录一下完整过程。
我的现象是：手机端点进 Codex 后，一直停在“正在等待桌面端…”，但 Windows 这边完全没有弹窗，也没有任何确认提示。
最后确认不是手机端没发请求，而是 Windows 端的 remote-control websocket 没有正常连上。
环境
- Windows 11
- Codex Desktop
- Android ChatGPT App
- Windows 和手机访问 OpenAI / ChatGPT 都需要代理
- 本机代理端口：
127.0.0.1:7890
这里不贴具体节点信息，只说思路。
需要先满足的条件
Windows 端至少要满足两类条件：
- Codex 的远控功能开关要启用
- Windows 端要有一个
codex remote-controlhost 在线，并成功连到 ChatGPT 的远控 websocket
也就是说，只在手机上点 Codex 不够；Windows 这边也要有一个能被云端找到的 remote-control host。
Codex 配置
先看 C:\Users\<你的用户名>\.codex\config.toml。
需要有：
[features]
remote_connections = true
remote_control = true
也可以用命令打开：
codex features enable remote_connections
codex features enable remote_control
检查：
codex features list
看到类似这样就行：
remote_connections true
remote_control true
这里有个坑：有时候重启 Codex 后，remote_control 可能会被写丢，最好重新检查一遍。
我一开始踩的坑
1. 以为 MFA 开了就一定能连
OpenAI 账号需要开启 MFA，这一步确实要做。
但 MFA 只是账号安全前置条件，不代表 Windows 端 remote-control 已经在线。
我开启 MFA 后，手机端还是一直等待桌面端。
2. 以为 Windows 桌面端会自动弹窗
我一开始以为手机点 Codex 后，Windows Codex 桌面端会弹一个确认窗口。
实际并没有。
至少在我这个 Windows 版本里，设置页的“连接”更像是 SSH connection from this PC，不是手机扫码绑定入口。
3. 以为代理规则里写了 chatgpt.com 就够了
我的代理配置里本来就有：
rules:
- DOMAIN-SUFFIX,chatgpt.com,Proxy
- DOMAIN-SUFFIX,openai.com,Proxy
但这不一定够。
原因是：Clash / Mihomo 的规则只能处理已经进入代理内核的流量。
如果 Codex 后端进程自己直连 chatgpt.com，没有走 127.0.0.1:7890，也没有被 TUN 接管，那这些规则根本没有机会生效。
我的日志里典型错误是：
failed to connect to app-server remote control websocket
os error 10060
这个在我的环境里基本就是 Windows 端直连超时。
4. 以为设置 Windows 系统代理就够了
Windows 系统代理开着，不代表所有后端进程都会读。
Electron / 浏览器类程序通常会吃系统代理，但 Codex 的 remote-control 更像 CLI / Rust 后端进程，它更可能读环境变量：
HTTP_PROXY
HTTPS_PROXY
ALL_PROXY
所以就出现了一个很绕的情况：
- Codex 普通聊天能用
- 手机端也有请求
- 但 Windows remote-control websocket 还是 10060
我最终采用的方案
我没有选择全局设置用户环境变量，也没有开 TUN。
最后用的是一个最小影响面的方案：只给 codex remote-control 这个进程注入代理环境变量。
这样不会影响整台电脑，也不会改变其它软件的代理行为。
启动脚本
新建脚本：
C:\Users\<你的用户名>\.codex\remote-control\start-codex-remote-control.ps1
内容如下：
$ErrorActionPreference = "Stop"
$proxy = "http://127.0.0.1:7890"
$logPath = Join-Path $env:USERPROFILE ".codex\codex-remote-control.log"
$existing = Get-CimInstance Win32_Process |
Where-Object {
$_.CommandLine -like "*remote-control*" -and
$_.CommandLine -notlike "*start-codex-remote-control.ps1*"
} |
Select-Object -First 1
if ($existing) {
Write-Host "Codex 手机远控已经在运行。PID: $($existing.ProcessId)"
Write-Host "日志: $logPath"
Read-Host "按 Enter 关闭"
exit 0
}
$env:HTTP_PROXY = $proxy
$env:HTTPS_PROXY = $proxy
$env:ALL_PROXY = $proxy
Write-Host "正在启动 Codex 手机远控..."
Write-Host "仅当前进程使用代理: $proxy"
Write-Host "日志: $logPath"
Write-Host ""
Write-Host "保持此窗口运行；关闭窗口会停止手机远控。"
Write-Host ""
codex remote-control --enable remote_control *>> $logPath
然后可以在桌面建一个快捷方式，目标填：
pwsh -NoLogo -NoProfile -ExecutionPolicy Bypass -File "C:\Users\<你的用户名>\.codex\remote-control\start-codex-remote-control.ps1"
以后双击这个快捷方式即可。
这个脚本会不会让全电脑都走 7890
不会。
脚本里设置的是 PowerShell 当前进程的环境变量：
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "http://127.0.0.1:7890"
它只影响这条进程树：
PowerShell
└─ codex remote-control
不会改 Windows 系统代理。
不会改用户级环境变量。
不会影响浏览器、Git、npm、Python 或其它程序。
并且 codex remote-control 把请求送到 127.0.0.1:7890 后，后面仍然由 Clash / Mihomo 按原来的规则分流。
成功标志
成功后日志里会看到：
connected to app-server remote control websocket
完整目标大概是：
wss://chatgpt.com/backend-api/wham/remote/control/server
如果重复运行，可能会看到：
409 Conflict
Remote app server already online
这个一般不是坏事，意思是云端已经认为有一个 remote app server 在线。
怎么检查进程是否还在
Get-CimInstance Win32_Process |
Where-Object { $_.CommandLine -like "*remote-control*" } |
Select-Object ProcessId,Name,CommandLine
如果看到：
codex remote-control --enable remote_control
说明 host 还在。
重启电脑会怎样
如果只是手动运行脚本，那么重启电脑后进程会消失。
需要重新双击快捷方式。
如果想省事，可以自己做成“登录时启动”的计划任务，但我个人倾向先手动跑，确认稳定后再自动化。
关于 Clash / Mihomo Merge 和 TUN
我也试过在 Nyanpasu / Mihomo 里加进程规则，比如：
find-process-mode: always
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
strict-route: true
dns-hijack:
- any:53
prepend__rules:
- PROCESS-NAME,codex.exe,Proxy
- PROCESS-NAME,Codex.exe,Proxy
这个方案理论上可以。
但要注意，PROCESS-NAME 规则要真正有用，流量必须先进入 Mihomo。
不开 TUN 的情况下，如果 Codex 后端直接连外网，这条进程规则可能根本碰不到它。
所以如果要走这个路线，关键不是只写规则，而是 TUN 必须真的生效。Windows 上 TUN 通常还需要管理员权限。
我最后没有继续用这个方案，因为它影响面更大，也更容易和日常代理规则搅在一起。
绑定后为什么去掉 Merge 还可以用
我还遇到一个现象：绑定成功后，去掉 Merge 规则，手机端仍然可以继续使用。
后来确认是因为我手动启动的 codex remote-control 进程还在后台跑。
这个进程启动时已经带了代理环境变量，所以不依赖后续的 Merge 规则。
也就是说，关键不是 Merge 本身，而是有没有一个能连上 ChatGPT 远控 websocket 的 Windows remote-control host。
简单总结
这条链路大概是：
Android ChatGPT
-> ChatGPT 云端
-> Windows codex remote-control host
-> 本机 Codex
我这里真正卡住的是：
Windows codex remote-control host
-> chatgpt.com 远控 websocket
最终解决：
开启 Codex remote_control
+
单独启动 codex remote-control
+
只给这个进程设置 127.0.0.1:7890 代理
这样不污染系统环境变量，不改全局代理，不影响其它软件，用起来也比较好排查。
2 个帖子 - 2 位参与者