手机端发送命令未被远端 Codex 执行，且输入框状态异常

[ictpeng]

问题描述

在手机端向远端 Codex 发送命令时，命令似乎没有成功发送到远端执行。

当前表现

手机端输入命令并发送后：

1. 远端 Codex 没有执行该命令。
2. 发送的命令文字变灰。
3. 该命令没有出现在上方的对话/显示区域中。
4. 命令文字仍然留在输入框里。
5. 整体感觉像命令没有真正发送出去，卡在输入框状态中。

期望表现

手机端点击发送后：

1. 命令应成功出现在上方对话/显示区域。
2. 输入框应清空。
3. 远端 Codex 应收到并执行该命令。
4. 如果发送失败，应显示明确错误提示，而不是只让文字变灰并停留在输入框里。

影响

手机端无法可靠控制远端 Codex，用户无法判断命令是发送中、发送失败，还是远端未执行。这个状态很容易让人误以为操
作已经发出，但实际没有生效。

复现步骤

1. 打开手机端页面。
2. 在输入框中输入一条 Codex 命令。
3. 点击发送。
4. 观察命令是否出现在上方显示区域，以及远端 Codex 是否执行。

实际结果

命令文字变灰，但仍留在输入框中；上方显示区域没有出现该命令；远端 Codex 没有执行。

期望结果

命令应进入对话/显示区域，输入框清空，远端 Codex 开始执行；如果失败，应提示发送失败原因。

建议排查方向

• 手机端发送事件是否正常触发。
• WebSocket / API 请求是否实际发出。
• 发送失败时是否缺少错误提示。
• 输入框 pending / disabled 状态是否没有正确恢复。
• 手机端与桌面端/远端 Codex 的状态同步是否存在问题。

[yzs15]

补充定位：这个问题不应按“手机端特有 bug”处理，手机端本质上就是网页端。同一套 Web UI 在桌面浏览器上也可能触发同类状态异常。

目前更需要关注的竞态是：

1. Codex Desktop / ChatGPT Desktop 正在执行某个本地 thread A。
2. 网页端/手机端对同一个 thread A 再提交 prompt。
3. 如果网页端当前实现是另起一个 resume 或另一个执行宿主去写同一个会话，就可能和桌面端 live session 竞争，导致 prompt 没有进入真实执行队列、输入框进入 pending/灰色状态、上方对话区没有新增消息，用户也拿不到明确错误。

这个 issue 需要修复两层问题：

• 产品行为层：同一个 thread 同一时间只能有一个权威执行入口。网页端提交时必须知道该 thread 是否已经被桌面端 live session 占用。
• UI 反馈层：如果发送失败或被拒绝，输入框不能只变灰并保留文本；必须恢复可编辑状态，并显示明确错误原因。

建议优先验证的方案是：看网页端能否 attach 到同一个 live app-server thread，而不是重新 resume 同一个本地会话。

需要调查的问题：

• Codex Desktop / ChatGPT Desktop 运行中的本地 task 是否有可发现的 app-server endpoint/socket/port。
• 该 endpoint 是否有认证 token 或 pairing 机制。
• app-server 是否支持网页端作为第二个 client attach 到同一个 live thread，并把新的 prompt 排入同一个执行队列。
• 如果 Desktop 没有公开/可发现的 app-server endpoint，本仓库就不能假装能控制它；此时应退化为检测/提示：该对话正在桌面端执行，网页端暂不能提交，请等待完成或回到桌面端继续。

验收标准建议：

1. 当桌面端正在执行 thread A，网页端对 thread A 发送 prompt 时：
   • 要么成功 attach 到同一个 live app-server thread，并让 prompt 在同一个执行队列中出现；
   • 要么明确拒绝提交，提示“该对话正在桌面端执行，网页端暂不能提交/请等待完成”。
2. 不允许出现输入框文字变灰、仍留在输入框、上方无消息、远端无执行且无错误提示的状态。
3. 发送失败时必须清理 pending 状态，保留用户输入，并显示具体错误。
4. 增加复现测试：Desktop/live host 正在执行同一 thread 时，Web/mobile 再提交 prompt 的行为必须可预测。

相关但独立的问题：Codex app 合并到 ChatGPT desktop 后的安装/检测/启动适配见 #23。这个 issue 仍聚焦“网页端与桌面端同时提交同一对话”的并发控制和 UI 错误反馈。