本文首发于 X（Twitter）@chao_zhao_1985：原文链接
桌面 Codex 能正常使用，dot 却把这台电脑标成 Offline。重启过应用，问题还在。这种情况下，从哪里查起？
这次 Windows 排查找到了两处问题：官方执行器没有继承电脑已有的代理环境；第一次生成的启动文件又因路径转义错误，没有真正启动桌面应用。
修正后，桌面应用与官方执行器都继承了代理环境，执行器日志记录了连接到 rendezvous。网络连接已有运行证据，dot 实际读取本机文件仍待验收。
下面记录完整的判断过程、最小修复，以及最后该如何验证。
先确定问题卡在哪一段
dot 访问本机文件，至少要经过四个阶段：
网络连接 → dot 访问授权 → 本地任务工作目录准备 → 实际文件读取。
Offline 需要先查网络和执行器状态；可以连接却不能启动任务，要看授权与工作目录准备；任务启动后读不到文件，再查执行电脑、绝对路径和读取错误。
尤其不要只凭 DesktopTaskWorkspaceUnavailableError 就认定“目录权限不够”。它是上层错误，底层也可能是进程来源校验失败。完整错误链比错误名称更有用。
诊断必须针对当前桌面应用
我先核对了真正运行的应用路径、安装包版本、OpenAI 签名，以及桌面应用使用的 CLI。
本案产品名称是 Codex，桌面进程名称却是 ChatGPT.exe。安装包版本为 26.930.3930.0，实际使用的 CLI 为 codex-cli 0.160.0。运行时 CLI 的哈希与当前安装包中的文件一致。
这里的版本号只是案例快照。诊断时应该使用自己当前桌面应用的 CLI，不能随手调用终端里另一份旧 codex。
在确认来源后，用 CLI 的完整路径检查：
$CliPath = Read-Host ‘粘贴已确认的桌面运行时 CLI 完整路径’ & $CliPath —version & $CliPath doctor —help
帮助明确支持后，再运行 doctor —json。报告先在本机查看，分享时只提取脱敏结论。
网页能打开，执行器仍可能连不上
最近连接失败时间附近，日志反复出现：
Noise executor failed to connect to rendezvous noise_reason=“websocket_error”
这把本案故障定位到了网络阶段。官方诊断中的 HTTP 检查可以通过，WebSocket 检查却失败。
因此，普通网页能打开，不能证明执行器连接正常；未经认证的请求返回 403，也不足以判定登录失效。
接下来查到了真正关键的差异：电脑已经使用代理，但桌面主进程、app-server 和 exec-server 都没有继承相关代理环境变量。
在终端里查看环境，只能证明这个终端有什么变量。检查对象必须是正在运行的桌面应用及执行器，而且只读取必要的代理项，不输出完整环境。
用同一个 CLI 比较直连和现有代理
我核实了本机代理的实际协议、端口和监听进程，然后仅对诊断进程临时设置代理环境，进行对照：
-
直连：WebSocket 失败，出现 os error 10054。
-
现有代理：收到 HTTP 101 Switching Protocols，握手成功。
这支持了“代理环境缺失影响连接”的判断，但当时还不能宣布 dot 修好了。
原因是：doctor 这里检查的是 Responses WebSocket；dot 执行器的 rendezvous 连接，需要在真正启动桌面应用后核对实际日志。
如果直连和代理都成功，或两者都失败，就不能照搬这个修复方案。
最小修复：由签名桌面应用启动官方执行器
修复方案很小：给本次启动的正确桌面应用设置已有代理环境，由桌面应用自己启动官方执行器。
保留的关系是：启动文件 → 签名桌面应用 → 官方执行器。
没有修改系统代理、登录、配置历史、防火墙或证书，也没有写入持久环境变量。
不要用 Python 或外部监督进程单独替代桌面执行器。网络连通以后，进程来源校验仍可能拒绝本地工具。若日志确实出现 untrusted-process-ancestry，应恢复官方启动链路，不伪造来源或就绪状态。本案没有出现这项错误。
第一次启动文件为什么失败？
第一次生成的启动文件经过多层字符串转义，Windows 路径中的反斜杠丢失了。签名检查于是报“找不到文件”，桌面应用根本没有通过该文件启动。
这是启动文件的路径缺陷，不能当成应用签名失效。
修正时，CMD 只保留简单入口，具体逻辑放进独立 PowerShell 文件；先用 Resolve-Path 解析绝对路径，再用同一路径校验签名、检查退出状态和启动。
只读验证通过后，保存工作，通过菜单或托盘完整退出桌面应用，保持已有代理运行，再回终端按回车。由启动文件打开应用。
真正重启后，证据发生了变化
新进程检查确认：桌面应用和官方执行器都继承了代理变量，执行器的父进程是桌面应用。
新进程对应的日志也出现了：
Local Work executor connected to rendezvous
这才是本案网络连接恢复的运行证据。connected 标签依然不能替代文件读取验收。
最后一步：让 dot 读取一个新的随机文件
先通过正式电脑设置检查授权：dot 详情 → Computers → 这台电脑 → Allow → Allow access。
已经成功的授权就保留。官方说明中，Offline 并不表示已有授权被撤销；功能适用范围及桌面版本要求也应按自己的场景核对。官方本地访问说明
接着在本机创建一个不含私人信息的随机文本文件：
只把绝对路径交给 dot，不要预先告诉它验收码。可以直接使用下面的要求：
请在我的这台 Windows 电脑上启动只读任务，实际读取文件：[替换为刚才生成的绝对路径]。不得使用云电脑的同名文件、历史结果、缓存或猜测内容替代。成功时返回执行电脑、读取路径、文件内的 acceptance_code、原始文件字节数、读取时间与时区，以及本次工具执行结果。失败时返回错误原文及底层错误链，标明失败发生在网络连接、访问授权、工作目录准备还是实际文件读取阶段。
收到回执后，用本机原始文件核对随机码和字节数，同时确认实际执行位置及本次工具结果。
只有这些证据吻合，才能宣布“这一次本机只读链路通过”。没有回执，就保持“待验收”；一次小文本读取通过，也不能扩大为所有项目或写入能力都已验证。
回退和以后重启
代理环境只作用于此次启动的桌面应用及子进程。完整退出应用，再从正常入口打开，即恢复原启动环境。
如果网络仍依赖该代理，完整退出应用或重启电脑后，需要再次使用这个启动方式。应用路径、版本或代理端口变更时，也要重新核实。
本案已经验证了代理继承和官方执行器连接恢复。最后的随机文件读取，仍等 dot 的实际回执。
这套排查方法的价值，是让每一步都有对应证据：知道故障发生在哪里，知道改动影响了什么，也知道距离真正验收还差什么。
———