Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

transfer-bug-recorder

Étoiles1

Forks0

Mis à jour3 juillet 2026 à 13:48

记录与分类「在 Codex 桌面界面有明确报错语句」的 codex-app-transfer 问题。按 Codex UI 报错语句建索引,命中已知记录直接给分类+排查路径+根因;未命中则按方法论诊断、完事归档一条。当遇到/排查 Codex 界面报错(如 "stream disconnected before completion"、"error sending request for url"、"Reconnecting N/5" 等),或刚诊断完一个这类 bug 需要存档时使用。

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

Cmochance

Cmochance/mochan-skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name

transfer-bug-recorder

description

transfer-bug-recorder

把「Codex 界面有明确报错语句」的 transfer 问题做成可检索知识库:按报错语句分类引导 → 走对应排查路径 → 记录根因/修复/是否真 bug。目标是下次同类报错快速定位,不再从零长链路瞎查。

⚠️ 记录只是参考线索,不是定论。 报错语句匹配到某条记录,只意味着"这是一个候选假设",不等于根因相同 —— 同一句 Codex 报错完全可能是不同原因(本 skill 诞生那次就反复锚错方向)。命中记录后必须按方法论结合当前实际去验证(尤其方法论 #4「监控 Codex 进程真实 TCP 连接」、#2「代码+测试+观测三结合」)确认后才下结论。把记录当起点假设,不当终点结论。 验证与记录冲突 → 信实际,并补/订正记录。

何时用

查(LOOKUP):遇到 Codex 界面报错 → 先来 records/INDEX.md 按报错语句片段匹配。命中 → 读对应记录、照它的「决定性诊断」走。
记(RECORD):刚诊断完一个有明确 Codex UI 报错的 transfer 问题 → 按下方模板写一条 records/<slug>.md + 在 records/INDEX.md 加一行。

流程

拿到报错原文(verbatim,含 URL/端口/HTTP 码 —— 这些是分类钥匙)。报错若是 Reconnecting N/5 这种中间态,等轮次真 settle 再读最终报错(driver 完成信号会被中间态骗,见方法论 #5)。
rg "<报错片段>" records/INDEX.md → 命中走记录;未命中 → 按「分类引导」定层 + 「排查方法论」诊断。
诊断完 RECORD 归档。

分类引导(按 Codex UI 报错语句定"层"+ 首要方向)

报错语句片段	层	首要排查方向
`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。

排查方法论(2026-06-17 一次 proxy-port 惨痛长查的血泪)

报错语句先定"层",按上表。传输层错 → 先问"Codex 到底连到哪了",而不是钻 transfer 协议逻辑。
代码 + 测试 + 真实观测,缺一不可。只看测试结果瞎猜会反复锚错方向(被用户点名批过)。
proxy 侧先洗清:直接探 transfer proxy 的 /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。

★ 最决定性的一招:监控 Codex 进程的真实 TCP 连接。

$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 }

触发一轮(driver 或人工发消息),看它连的真实远端。proxy/MITM 都收不到时,这步直接看出"Codex 连的是代理口、不是目标端口"。

截 settled 后的 Codex 界面:有些报错只在轮次真结束后渲染;driver 的完成信号 [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 代码、别自作主张覆盖用户代理意图。
MITM 抓包的坑(方法论 #4 通常已够,#4 不够才架):SSH 起 GUI app(Codex/transfer)落 session 0(用户看不见、半残、网络行为可能异常);后台进程要 WMI Win32_Process Create 或计划任务(S4U) 才脱离 SSH 会话;捕获日志用 append 别 truncate(每次重启 truncate 会丢数据);IPv4 127.0.0.1 和 IPv6 ::1 都要监听(Codex 可能走 IPv6)。远程 Windows 测试机的 SSH 访问按你的本地配置(主机别名 / 凭据)。

记录模板(写到 records/.md)

---
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

来自 auto-memory 的实证补充(2026-07-03 迁移,如与上文重复以上文为准)

~/.claude/skills/transfer-bug-recorder/(2026-06-17 建)。把「Codex 桌面界面有明确报错语句」的 transfer 问题做成可检索知识库:按报错语句建索引,命中已知记录直接给分类+排查路径+根因;未命中按方法论诊断、完事归档一条。

何时用:遇到/排查 Codex 界面报错(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)是最决定性一招;③ 代码+测试+真实观测缺一不可,别只看测试结果瞎猜。
配套:[[reference_windows_test_machine_ssh_access]]、[[reference_codex_responses_ws_transport_fallback]]、skill codex-e2e-test。

Plus depuis ce dépôt

même dépôt

adaptive-review

Cmochance/mochan-skills

用户显式触发的本地代码审查:按 diff 特征自动从 lens 池选 3-6 个相关审查维度(不是固定 3-agent、也不是几十 agent 的 workflow),跑 Route→Fan-out→Verify→Synthesize,对抗式 verify 杀假阳性后按严重度出报告。替代项目「固定 3-agent 本地审查」约定。三档 quick/standard/thorough,默认 standard;thorough 复用现有 /code-review Workflow 不重造。仅用户显式触发,不自动跑。

2026-07-121

tiered-review

Cmochance/mochan-skills

分级路由的代码审查:把多维度审查的「广度发现」层 offload 到 grok CLI(用 grok 订阅省 Claude 额度),Claude 只做高档对抗验证 + 综合。当多 agent 审查(pr-review-toolkit:* 子 agent)或 code-review workflow 被触发时,PreToolUse hook 会 deny 并把发现层改道到本 skill 的 grok 编排器。grok-only MVP(agy 第三腿暂缓)。

2026-07-121

merge-closeout

Cmochance/mochan-skills

用户说「merge 收尾」时的固定收尾 SOP(step0-6):stacked child PR base 解耦、squash merge、.app 转移加 test 前缀、清理远端/本地/worktree 并逐项 verify、关联 GitHub issue、Linear MOC transition + step6.2 强制扫描未完成 issue 挂强相关。含搭车改动补 Done issue、外部 contributor workflow approve、fork PR 收尾差异、深层 stacked squash、reviewThreads 分页坑等变体。没听到「merge 收尾」明确指令绝不主动 merge。

2026-07-081

release-flow

Cmochance/mochan-skills

发版/release 全流程 SOP:dispatch 前预发布微 PR(版本号全盘 grep bump、双语 release notes 硬模板 2500-3200 字符、release-notes/vX.Y.Z.md CI 门禁)、release.yml workflow_dispatch 版本校验、merge cleanup 顺序、build 完保持 draft 等用户显式确认才转 Latest。用户说「发版/准备 release/触发 release workflow」时使用。

2026-07-071

plane-index

Cmochance/mochan-skills

本地 Plane work item 索引(Plane Cloud)。需要定位、查找、回忆 Plane work item 时(按编号/关键词/状态/标签/project/归档),先查本地索引再按需 MCP 拉详情;也负责索引的增量/全量刷新。与 linear-index 同构,但适配 Plane(原生归档、无限 issue、PQL、external_id 回链 Linear)。

2026-07-031

codex-e2e-test

Cmochance/mochan-skills

通过 CDP 注入驱动真实运行的 Codex Desktop 跑一轮对话并读回 assistant 回复,对 codex-app-transfer 的 Codex 集成做 E2E/冒烟测试(验证 provider 路由 / 协议适配 / 注入 / 代理链路端到端是否真的工作),替代很多手搓 E2E。默认新建独立会话测试、结束精准归档,绝不动用户已有会话。当需要"在真实 Codex 里发一句 prompt 看实际效果"而不仅是跑单测时使用。

2026-07-031

name

transfer-bug-recorder

description

transfer-bug-recorder

⚠️ 记录只是参考线索,不是定论。 报错语句匹配到某条记录,只意味着"这是一个候选假设",不等于根因相同 —— 同一句 Codex 报错完全可能是不同原因(本 skill 诞生那次就反复锚错方向)。命中记录后必须按方法论结合当前实际去验证(尤其方法论 #4「监控 Codex 进程真实 TCP 连接」、#2「代码+测试+观测三结合」)确认后才下结论。把记录当起点假设,不当终点结论。 验证与记录冲突 → 信实际,并补/订正记录。

何时用

查(LOOKUP):遇到 Codex 界面报错 → 先来 records/INDEX.md 按报错语句片段匹配。命中 → 读对应记录、照它的「决定性诊断」走。
记(RECORD):刚诊断完一个有明确 Codex UI 报错的 transfer 问题 → 按下方模板写一条 records/<slug>.md + 在 records/INDEX.md 加一行。

流程

拿到报错原文(verbatim,含 URL/端口/HTTP 码 —— 这些是分类钥匙)。报错若是 Reconnecting N/5 这种中间态,等轮次真 settle 再读最终报错(driver 完成信号会被中间态骗,见方法论 #5)。
rg "<报错片段>" records/INDEX.md → 命中走记录;未命中 → 按「分类引导」定层 + 「排查方法论」诊断。
诊断完 RECORD 归档。

分类引导(按 Codex UI 报错语句定"层"+ 首要方向)

报错语句片段	层	首要排查方向
`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。

排查方法论(2026-06-17 一次 proxy-port 惨痛长查的血泪)

报错语句先定"层",按上表。传输层错 → 先问"Codex 到底连到哪了",而不是钻 transfer 协议逻辑。
代码 + 测试 + 真实观测,缺一不可。只看测试结果瞎猜会反复锚错方向(被用户点名批过)。
proxy 侧先洗清:直接探 transfer proxy 的 /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。

★ 最决定性的一招:监控 Codex 进程的真实 TCP 连接。

$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 }

触发一轮(driver 或人工发消息),看它连的真实远端。proxy/MITM 都收不到时,这步直接看出"Codex 连的是代理口、不是目标端口"。

截 settled 后的 Codex 界面:有些报错只在轮次真结束后渲染;driver 的完成信号 [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 代码、别自作主张覆盖用户代理意图。
MITM 抓包的坑(方法论 #4 通常已够,#4 不够才架):SSH 起 GUI app(Codex/transfer)落 session 0(用户看不见、半残、网络行为可能异常);后台进程要 WMI Win32_Process Create 或计划任务(S4U) 才脱离 SSH 会话;捕获日志用 append 别 truncate(每次重启 truncate 会丢数据);IPv4 127.0.0.1 和 IPv6 ::1 都要监听(Codex 可能走 IPv6)。远程 Windows 测试机的 SSH 访问按你的本地配置(主机别名 / 凭据)。

记录模板(写到 records/.md)

---
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

来自 auto-memory 的实证补充(2026-07-03 迁移,如与上文重复以上文为准)

何时用:遇到/排查 Codex 界面报错(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)是最决定性一招;③ 代码+测试+真实观测缺一不可,别只看测试结果瞎猜。
配套:[[reference_windows_test_machine_ssh_access]]、[[reference_codex_responses_ws_transport_fallback]]、skill codex-e2e-test。