背景
2026-09-22,ChatGPT 经正式 wanctl MCP 在用户的 macOS 上开发本机白板。用户要求提交本 issue,供同步修复。正常路径下,Workspace 的项目根相对路径、独立 shell 环境和 exec request_id / offset 非常有用;问题集中在异常后的确定性。此报告只描述实际观察,不把 502 直接归因于 device、relay 或 MCP 任一层。没有精确版本信息,不能断言对应某个发布版本。
实际观察 A:enter 返回 EOF,但带 workspace 引用
- wanctl_workspace(action=enter, target=, root=)。
- 返回 is_error=true:
EOF,同时返回 workspace=<device>#w-...。
- 沿该原引用调用 status,返回:
workspace unavailable: unknown, closed, or not owned by this controller; never fall back to another workspace。
- 随后一次明确的新 enter 成功。
问题:客户端无法区分未创建、创建但响应丢失、已关闭或 controller 绑定丢失;无法判断新 enter 是否会遗留一个仍存活的 shell。
实际观察 B:文件写入 502,回读也断线
- 在成功进入的 workspace 用 wanctl_write 创建
omp-rpc.cjs。
- MCP 返回
ConnectorClientServerError: 502: "Server returned 502: 'Upstream or external service errors'"。
- 用同一 workspace 的 wanctl_read 回查该文件,返回:
result unknown: the connection dropped after the request was sent; nothing was changed by reading omp-rpc.cjs, so retry。
- 后续 status 一度返回
dial relay (404): device offline,peers 也出现 502。
- 没有盲目重试写入。经用户已授权的另一条独立开发通道读取同一台 Mac、同一项目,最终确认文件为 not_found。这只是本次最终观察,不代表一般情况下 write 502 等于未写入。
问题:exec 有 request_id 和查询记录,write/edit 的不确定结果目前只能靠另一次成功文件读取确认;故障期间 Agent 不能安全继续,也不能把失败当成未执行。
附带体验:开发 shell PATH
新 workspace 的 /bin/sh 起初找不到 node 和 omp,但它们在用户日常终端可用。明确 export 开发 PATH 一次后,随后独立 exec_async 仍能使用,说明状态保持有效。建议把它视作可配置的环境可见性改进,而非自动加载全部 shell 配置的要求。
建议
- 工作区状态提供明确结构化 reason_code,区分 never-created / closed / owner-mismatch / device-restarted / transport-unavailable,并标出可否安全重试。
- enter 使用稳定调用标识并可恢复响应,断线重试不重复创建 shell。
- write/edit 提供稳定 operation_id 和结果查询:received / running / committed / failed / unknown,成功包含最终 sha256;同 ID 不同内容应拒绝,同 ID 相同内容不重复执行。
- relay/MCP 502 尽可能保留 request_id、是否已发送到设备、是否有权威完成结果;不可凭断线推断失败。
- 提供显式、可控的开发环境初始化选项;报告 shell 与初始化状态,不回传凭据或整个环境。
验收建议
- 在 enter 已创建 shell、但响应未送达时断开连接;同请求恢复应返回原 workspace,不产生第二个 shell。
- 在 write 原子 rename 前后各注入断线;重连查询能区分未提交/已提交,并返回一致哈希。
- 同 operation_id 同内容重试不得重复副作用;不同内容拒绝。
- device restart、MCP restart、controller 不匹配和显式 exit 各有可区分状态,绝不静默回退其他工作区。
- 已正常工作的项目根路径、shell cwd/env、异步 offset 行为保持回归通过。
未附设备完整 ID、指纹、本机用户名、路径、登录态或密钥。
背景
2026-09-22,ChatGPT 经正式 wanctl MCP 在用户的 macOS 上开发本机白板。用户要求提交本 issue,供同步修复。正常路径下,Workspace 的项目根相对路径、独立 shell 环境和 exec request_id / offset 非常有用;问题集中在异常后的确定性。此报告只描述实际观察,不把 502 直接归因于 device、relay 或 MCP 任一层。没有精确版本信息,不能断言对应某个发布版本。
实际观察 A:enter 返回 EOF,但带 workspace 引用
EOF,同时返回workspace=<device>#w-...。workspace unavailable: unknown, closed, or not owned by this controller; never fall back to another workspace。问题:客户端无法区分未创建、创建但响应丢失、已关闭或 controller 绑定丢失;无法判断新 enter 是否会遗留一个仍存活的 shell。
实际观察 B:文件写入 502,回读也断线
omp-rpc.cjs。ConnectorClientServerError: 502: "Server returned 502: 'Upstream or external service errors'"。result unknown: the connection dropped after the request was sent; nothing was changed by reading omp-rpc.cjs, so retry。dial relay (404): device offline,peers 也出现 502。问题:exec 有 request_id 和查询记录,write/edit 的不确定结果目前只能靠另一次成功文件读取确认;故障期间 Agent 不能安全继续,也不能把失败当成未执行。
附带体验:开发 shell PATH
新 workspace 的 /bin/sh 起初找不到 node 和 omp,但它们在用户日常终端可用。明确 export 开发 PATH 一次后,随后独立 exec_async 仍能使用,说明状态保持有效。建议把它视作可配置的环境可见性改进,而非自动加载全部 shell 配置的要求。
建议
验收建议
未附设备完整 ID、指纹、本机用户名、路径、登录态或密钥。