菜单
记录与分类「在 Codex 桌面界面有明确报错语句」的 codex-app-transfer 问题。按 Codex UI 报错语句建索引,命中已知记录直接给分类+排查路径+根因;未命中则按方法论诊断、完事归档一条。当遇到/排查 Codex 界面报错(如 "stream disconnected before completion"、"error sending request for url"、"Reconnecting N/5" 等),或刚诊断完一个这类 bug 需要存档时使用。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Cmochance/mochan-skills --skill transfer-bug-recorder命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | transfer-bug-recorder |
| description | 记录与分类「在 Codex 桌面界面有明确报错语句」的 codex-app-transfer 问题。按 Codex UI 报错语句建索引,命中已知记录直接给分类+排查路径+根因;未命中则按方法论诊断、完事归档一条。当遇到/排查 Codex 界面报错(如 "stream disconnected before completion"、"error sending request for url"、"Reconnecting N/5" 等),或刚诊断完一个这类 bug 需要存档时使用。 |
把「Codex 界面有明确报错语句」的 transfer 问题做成可检索知识库:按报错语句分类引导 → 走对应排查路径 → 记录根因/修复/是否真 bug。目标是下次同类报错快速定位,不再从零长链路瞎查。
⚠️ 记录只是参考线索,不是定论。 报错语句匹配到某条记录,只意味着"这是一个候选假设",不等于根因相同 —— 同一句 Codex 报错完全可能是不同原因(本 skill 诞生那次就反复锚错方向)。命中记录后必须按方法论结合当前实际去验证(尤其方法论 #4「监控 Codex 进程真实 TCP 连接」、#2「代码+测试+观测三结合」)确认后才下结论。把记录当起点假设,不当终点结论。 验证与记录冲突 → 信实际,并补/订正记录。
records/INDEX.md 按报错语句片段匹配。命中 → 读对应记录、照它的「决定性诊断」走。records/<slug>.md + 在 records/INDEX.md 加一行。Reconnecting N/5 这种中间态,等轮次真 settle 再读最终报错(driver 完成信号会被中间态骗,见方法论 #5)。rg "<报错片段>" records/INDEX.md → 命中走记录;未命中 → 按「分类引导」定层 + 「排查方法论」诊断。| 报错语句片段 | 层 | 首要排查方向 |
|---|---|---|
error sending request for url (http://127.0.0.1:PORT/...) | 传输/连接层(reqwest 连不上) | 查 Codex 实际连哪个远端(方法论 #4)。常见:.codex/.env 的 HTTP_PROXY 把本地回环也代理了、且代理端口死/变 → records/proxy-port-stale-env.md |
stream disconnected before completion | 流式中断(连上又断) | 区分 WS 传输 / 上游掉流 / proxy 中断。开 CAS_DIAG_TRACE=1 看 forward-trace 上游码 |
Reconnecting N/5(循环) | 传输重试耗尽 | 多是上面两类的表象;等 settle 看最终报错,别拿"Reconnecting"当结论 |
报错含 HTTP 4xx/5xx | 上游 / adapter | forward-trace 的 outbound;provider 限流(429/503)/ 参数被剥 / schema 400 |
Thinking 卡死 / 无文本输出 | 模型 / 审批 | 模型慢 / 等桌面端审批(M1 不支持远程批准)/ 纯工具轮无文本 |
"层"判错是最大的坑:
error sending request是传输层(根本没连上目标),别当成 transfer 的业务/协议 bug。
/responses,HTTP/1.1 + h2c + WS 真帧三种传输各打一遍(零依赖 Node 探针:http.request / http2.connect / 手搓 WS 帧)。三种都能完整回流 SSE = proxy 无辜,问题在 Codex 侧/环境。
3a. proxy WS 行为速查:native-responses provider 的 WS upgrade 回 426 让 Codex 降级 HTTP;chat provider(openai_chat)接受 WS 走 ws→http;warmup 帧(generate:false/空 input)回 Close 1003。$end=(Get-Date).AddSeconds(30); $seen=@{}
while((Get-Date) -lt $end){ $p=(Get-Process Codex,codex -EA SilentlyContinue).Id
Get-NetTCPConnection -EA SilentlyContinue | ?{ $_.OwningProcess -in $p -and $_.RemoteAddress -notin @('0.0.0.0','::') } |
%{ $k="$($_.RemoteAddress):$($_.RemotePort)"; if(-not $seen[$k]){$seen[$k]=1; Write-Output "$k $($_.State)"} }
Start-Sleep -Milliseconds 250 }
[data-local-conversation-final-assistant] 会被"Reconnecting"中间态提前触发抓到假回复(见 codex-e2e-test skill)。远程机经 UU远程 + computer-use 截。.codex/.env 的代理会代理回环:HTTP_PROXY 让 Codex 把 127.0.0.1:18081(transfer proxy)也走代理。代理端口死/变 → 整个 transfer 模式挂,但 transfer 本身没毛病、与版本无关。修法是改 .env 端口或加 NO_PROXY=127.0.0.1,localhost,::1。这类是用户环境问题,别改 transfer 代码、别自作主张覆盖用户代理意图。Win32_Process Create 或计划任务(S4U) 才脱离 SSH 会话;捕获日志用 append 别 truncate(每次重启 truncate 会丢数据);IPv4 127.0.0.1 和 IPv6 ::1 都要监听(Codex 可能走 IPv6)。远程 Windows 测试机的 SSH 访问按你的本地配置(主机别名 / 凭据)。---
error_signatures: # 匹配用的报错原文片段(可多条,保留原文标点/URL)
- "error sending request for url (http://127.0.0.1"
symptom: 一句话症状
layer: 传输层 | 流 | 上游 | 模型
is_transfer_bug: false # 是否真 transfer 代码 bug(false=环境/外部,别改代码)
---
- **现象**:Codex 界面报 `<原文>`
- **走过的弯路**:别人少踩(本次锚错了哪些方向)
- **决定性诊断**:哪一步一锤定音 + 命令/证据
- **根因**:...
- **修复**:...
- **关联**:`records/<其它记录 slug>.md` / issue 编号 / commit
~/.claude/skills/transfer-bug-recorder/(2026-06-17 建)。把「Codex 桌面界面有明确报错语句」的 transfer 问题做成可检索知识库:按报错语句建索引,命中已知记录直接给分类+排查路径+根因;未命中按方法论诊断、完事归档一条。
stream disconnected before completion / error sending request for url / Reconnecting N/5 / HTTP 4xx-5xx / Thinking 卡死等),或刚诊断完这类 bug 要存档。SKILL.md(分类引导表 + 排查方法论 + 记录模板)+ records/INDEX.md(报错语句索引,rg 匹配)+ records/<slug>.md(每条 bug 详录)。error sending request=传输层、先问 Codex 连到哪);② 监控 Codex 进程真实 TCP 连接(Get-NetTCPConnection by Codex/codex pid)是最决定性一招;③ 代码+测试+真实观测缺一不可,别只看测试结果瞎猜。codex-e2e-test。