CODEX KNOWLEDGE

Claude Codex CC Switch 机器级控制面说明书

2026/04/26 71 min read CODEX KNOWLEDGE 类 治理规则 类 工具工作流 形态 规范 目录 CODEX KNOWLEDGE CLAUDE CODEX CC SWITCH 机器级控制面说明书

Claude / Codex / CC Switch 机器级控制面说明书

Truth Layer

当前唯一 live 控制点

Claude

  • 启动入口：C:\Users\ASUS-KL\bin\claude-launch.ps1
  • provider 指针：C:\Users\ASUS-KL\.cc-switch\settings.json
  • provider 真相源：C:\Users\ASUS-KL\.cc-switch\cc-switch.db
  • 权限与运行模式：C:\Users\ASUS-KL\.claude\settings.json
  • 次级本地配置壳：C:\Users\ASUS-KL\.claude\config.json

Codex

  • 启动入口：C:\Users\ASUS-KL\bin\codex.ps1
  • launcher：C:\ProgramData\npm-global\codex-launcher.cjs
  • 启动门禁：C:\Users\ASUS-KL\.codex\gateway.ps1
  • 运行主配置：C:\Users\ASUS-KL\.codex\config.toml
  • interactive policy：C:\Users\ASUS-KL\.codex\industrial-control\policies\interactive-policy.json

CC Switch

  • 主配置目录：C:\Users\ASUS-KL\.cc-switch
  • provider 指针：C:\Users\ASUS-KL\.cc-switch\settings.json
  • provider 数据库：C:\Users\ASUS-KL\.cc-switch\cc-switch.db
  • 应用程序：C:\Users\ASUS-KL\AppData\Local\Programs\CC Switch\cc-switch.exe

当前职责边界

  • CC Switch 负责 Claude provider 的动态 truth，包括当前 provider、token、base URL。
  • claude-launch.ps1 负责每次启动时把 CC Switch 当前 truth 注入 Claude 进程环境。
  • C:\Users\ASUS-KL\.claude\settings.json 只负责 Claude 的权限、sandbox、approval 与运行时行为。
  • C:\Users\ASUS-KL\.claude\config.json 不再承载备用 auth truth，只保留最小本地壳。
  • Codex 的模型、认证、权限与 gateway 逻辑只由 .codex 自己的 live 链路控制，不与 Claude provider 层混用。

2026-04-26 启动链体检结论

  • codex 当前真实入口解析到 C:\Users\ASUS-KL\bin\codex.ps1，再进入 C:\Users\ASUS-KL\.codex\gateway.ps1，最后进入 C:\ProgramData\npm-global\codex-launcher.cjs。
  • claude 当前真实入口在 PowerShell 中优先是 C:\Users\ASUS-KL\Documents\PowerShell\Microsoft.PowerShell_profile.ps1 里定义的 claude function；该函数只转发到 C:\Users\ASUS-KL\bin\claude-launch.ps1。
  • claude.cmd 仍存在于 C:\Users\ASUS-KL\bin\claude.cmd，但它只是对 claude-launch.ps1 的批处理包装，不是第二套独立 truth。
  • C:\Users\ASUS-KL\.claude\glm-gateway 已不存在；当前发现的 GLM、LongCat、claude-sonnet-4-20250514 等字符串只在 archive、history、debug 日志中出现，不在 live 配置中生效。
  • C:\Users\ASUS-KL\.codex\industrial-control\policies\interactive-policy.json 当前 enabled = false，因此 Codex 当前 live 行为不是受控交互模式，而是直接使用 .codex 的常规执行链。
  • C:\Users\ASUS-KL\.claude\settings.json 当前 live 行为为 approvalPolicy = never、sandboxMode = danger-full-access、agentMode = full-access；C:\Users\ASUS-KL\.claude\config.json 仅保留空 allow/deny 壳，不承载 provider truth。

已下线旧链路

  • C:\Users\ASUS-KL\.claude\glm-gateway 已删除。
  • GLM / LiteLLM / http://127.0.0.1:4000 旧本地代理链已退出当前 live 路径。
  • C:\Users\ASUS-KL\.codex\claude\unified-config.json 旧统一配置元数据已下线并归档。
  • C:\Users\ASUS-KL\.codex\shared\tools\sync-config.sh 旧统一同步脚本已下线并归档。

Archive / History 分层

  • 归档区：
    • C:\Users\ASUS-KL\.claude\archive-nonlive-20260426
    • C:\Users\ASUS-KL\.codex\archive-nonlive-20260426
  • 历史区：
    • C:\Users\ASUS-KL\.claude\file-history
    • C:\Users\ASUS-KL\.claude\projects
    • C:\Users\ASUS-KL\.claude\history.jsonl
    • C:\Users\ASUS-KL\.codex\history.jsonl

Constraint Layer

禁止复活的旧模式

  • 不要再把 Claude provider truth 写回 C:\Users\ASUS-KL\.claude\settings.json 或 C:\Users\ASUS-KL\.claude\config.json。
  • 不要再恢复 glm-gateway、LiteLLM、http://127.0.0.1:4000 作为默认 Claude base URL。
  • 不要再引入新的并行 Claude auth source，除非用户明确要求替换 CC Switch 为新的单一真相源。
  • 不要再恢复 .codex\claude\unified-config.json 或 sync-config.sh 这条旧统一链作为 live 控制面。
  • 不要把 archive / history 区中的文件当成当前 live 配置来修改或解释。

当前残余风险

  • 当前用户级与机器级环境变量中的 ANTHROPIC_* 已为空，但某些已打开的 PowerShell 进程仍可能继承旧会话里的 ANTHROPIC_* 值。
  • 这个残余污染目前不会重新定义 Claude 的 live provider truth，因为 C:\Users\ASUS-KL\bin\claude-launch.ps1 会先清掉 ANTHROPIC_*，再只从 CC Switch 当前 provider 重新注入。
  • 这类残余更像“当前 shell 会话污染”，不是机器级持久配置冲突；若要清空，只需关闭旧 shell 或在新 shell 中重新启动 claude。
  • Codex 不读取 ANTHROPIC_* 作为它自己的 live provider truth；它的 live provider 仍只看 C:\Users\ASUS-KL\.codex\config.toml。

排障顺序

  1. 先解真实命令入口。
  2. 再解 controlling config / provider pointer。
  3. 再解 launcher / gateway / wrapper chain。
  4. 最后才看 archive、history、旧说明文档。

完成判定

  • 只要改动了 Claude / Codex / CC Switch 的 live 控制点，就必须：
    • 更新本说明书；
    • 更新 machine-readable facts layer；
    • 必要时更新博客记录；
    • 必要时更新全局规则与门禁层。

Strategy Layer

维护策略

  • 保持每一层只有一个 live truth owner：
    • provider truth 只有 CC Switch
    • Claude 权限 truth 只有 .claude/settings.json
    • Codex 运行 truth 只有 .codex/config.toml + gateway + launcher
  • live / archive / history 目录必须长期分离。
  • 兼容逻辑允许暂时存在，但要写明退场条件，并在主链稳定后删掉。
  • 文档优先描述 current truth，不要把 target-state 或历史方案写成现在仍生效。

快速判断口诀

  • 看入口，不看猜测。
  • 看 live，不看备份。
  • 看控制层，不看历史记录。
  • 同类事实只认一个 owner。

变更 checklist

  • 这次改的是哪一层：provider / launcher / permission / gateway / policy / docs？
  • 当前唯一 live owner 有没有变化？
  • 有没有新增并行 truth source？
  • archive / history / blog / rule 层是否需要同步？
  • 有没有需要下线的兼容分支或旧文档说法？

Control Plane Facts Layer

machine-readable control plane

  • 独立控制面 JSON：E:\My Project\Atramenti-Console\codex\plugins\obsidian\data\docs\codex-knowledge\claude-codex-control-plane.json
  • 对应 schema：E:\My Project\Atramenti-Console\codex\plugins\obsidian\data\docs\codex-knowledge\claude-codex-control-plane.schema.json
  • 该 JSON 负责提供当前控制面的 machine-readable truth，包括：
    • truth owners
    • live paths
    • archive paths
    • history paths
    • forbidden legacy chains
    • 控制面文档入口

one-shot health check

  • 一键体检脚本：C:\Users\ASUS-KL\.codex\automations\check-claude-codex-control-plane.ps1
  • 该脚本默认输出：
    • control plane JSON 是否成功加载
    • claude 当前真实入口
    • CC Switch 当前 provider pointer
    • Claude 权限来源与关键行为字段
    • codex 当前真实入口
    • interactive policy 当前是否启用
    • forbidden legacy chains 当前是否仍存在

expected healthy result

  • 当前健康态应满足：
    • controlPlaneLoaded = true
    • providerPointer 为 CC Switch 当前 provider id
    • approvalPolicy = never
    • sandboxMode = danger-full-access
    • interactivePolicyEnabled = false
    • forbiddenLegacyChains.anyPresent = false

2026-04-26 实测结果

  • powershell -NoProfile -ExecutionPolicy Bypass -File C:\Users\ASUS-KL\.codex\gateway.ps1 已返回合法 JSON，不再报 Missing an argument for parameter 'CodexArgs'。
  • powershell -NoProfile -ExecutionPolicy Bypass -Command "codex --help" 已成功穿过 bin -> gateway -> launcher -> codex engine 链并输出帮助。
  • powershell -NoProfile -ExecutionPolicy Bypass -Command "claude --help" 已成功输出帮助。
  • 无 TTY 的验证进程里直接跑 codex 仍会看到 stdin is not a terminal；这属于当前验证方式限制，不属于启动链损坏。

Operator Convenience Layer

bin shortcut

  • 快捷体检入口：C:\Users\ASUS-KL\bin\check-control-plane.cmd
  • 该入口直接调用：C:\Users\ASUS-KL\.codex\automations\check-claude-codex-control-plane.ps1
  • 以后做本机控制面健康检查时，优先跑这个快捷命令，而不是手输完整脚本路径。
  • Claude bug-fix 专用入口：
    • C:\Users\ASUS-KL\bin\claude-bugfix.ps1
    • C:\Users\ASUS-KL\bin\claude-bugfix.cmd
  • 作用：
    • 继续使用 CC Switch 当前 provider truth
    • 继续使用本机 stream proxy
    • 但跳过共享 MCP / plugin / 厚提示层，尽量把 Claude 拉到更轻的修 bug 模式

live script header notes

  • 以下 live 脚本已写入极短控制面注释，目的是让维护者打开文件第一眼就知道 truth owner 和禁止恢复的旧链路：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1
    • C:\ProgramData\npm-global\codex-launcher.cjs
    • C:\Users\ASUS-KL\.codex\gateway.ps1
  • 这些注释不是业务逻辑，而是防止未来维护时重新把 token/base URL/model/旧 unified-config/旧 loopback 方案写回错误层。

2026-04-26 启动链修复点

  • C:\Users\ASUS-KL\bin\codex.ps1 已修正 WinPS 5 下空参数启动时对 gateway.ps1 的调用方式：
    • 先写 CODEX_FORWARD_ARGS_JSON
    • 有参数才显式传 -CodexArgs
    • 无参数时直接调用 gateway
  • C:\Users\ASUS-KL\.codex\gateway.ps1 已修正 WinPS 5 relay 到 pwsh 时的空参数兼容性：
    • 明确 DefaultParameterSetName = 'Launch'
    • 只有在 CodexArgs 非空时才向 relay 命令附加 -CodexArgs
  • 这次修复的目标不是改变控制面 owner，而是恢复既有 live 控制面在 Windows PowerShell 下的兼容性。
  • C:\Users\ASUS-KL\Documents\PowerShell\profile.ps1 与 C:\Users\ASUS-KL\Documents\WindowsPowerShell\profile.ps1 现已在 shell 启动时主动清理旧 ANTHROPIC_* 环境变量，防止 stale parent session 把旧 Claude 桥接值继续带进新 shell。
  • C:\Users\ASUS-KL\.claude\settings.json 已执行一轮“短回合收尾优化”：
    • useCompactMode = false
    • terseMode = false
    • defaultServiceTier = standard
    • CLAUDE_CODE_MAX_OUTPUT_TOKENS = 12000
  • C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md 已补“任务闭环规则”与“回合结束前自检清单”，用于降低 Claude 把子步骤完成误判成整任务完成的概率。

2026-04-26 补充：Claude 风格收紧与真实样本压测

背景

  • 在修完 cc-vibe 流式兼容问题后，用户对 Claude 的剩余不满不再集中在“卡死/掉字”，而是：
    • 会补礼貌尾巴
    • 短答不够字面
    • 有时看起来不够硬执行
  • 这一轮的目标不是换 provider，也不是换 model，而是把当前 live Claude 调得更像“短、硬、少自作主张”的执行型风格。

live 配置调整

  • C:\Users\ASUS-KL\.claude\settings.json
    • terseMode: false -> true
    • modelReasoningEffort: high -> medium
    • env.CLAUDE_CODE_MODEL_REASONING_EFFORT: high -> medium
  • C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
    • 新增“风格收紧协议”
    • 明确要求：
      • 默认更短、更硬执行
      • 只回答 / exactly / 不要客套 视为硬约束
      • 指定精确标签与固定顺序时，优先按原格式输出
  • C:\Users\ASUS-KL\bin\claude-launch.ps1
    • 新增短 --append-system-prompt
    • 作用：
      • 对短答、精确答、精确格式要求做 launcher 级字面服从补强
      • 不改 provider truth，不写死 token，只在每次启动时补一小段行为提示

对照测试

  • 纯净模式（claude.exe --bare --print）：
    • 只回答 测试 -> 测试
    • Reply with exactly TEST and nothing else. -> TEST
  • 调整前 live 模式（claude-launch.ps1 --print）：
    • 只回答 测试 -> 测试收到。
    • Reply with exactly TEST and nothing else. -> TEST

调整后 live 压测样本

  • 只回答 修好了 -> 修好了
  • 只回答 测试 -> 测试
  • 只回答 OK -> OK
  • Reply with exactly TEST and nothing else. -> TEST
  • 你正在修 Claude 掉线。先不要总结，不要客套，只用一句话说你下一步立刻会做什么。
    • 返回为单句直接动作描述，不再补礼貌尾巴

当前结论

  • 这说明当前 live Claude 的主要问题确实不只是“模型本体蠢”，而是：
    • 流式兼容坏过
    • 行为层提示过重
    • 默认风格更容易补话
  • 到这一步，短答/字面答/少客套 已明显改善。

仍存边界

  • 对“精确四标签格式”这类强格式要求，在单轮 --print 风格压测里仍不稳定：
    • 某些过于抽象或信息留空的 prompt，Claude 仍倾向先追问
    • 某些单轮演示式 prompt，会出现只回一个标签或把任务理解错的情况
  • 因此当前判断是：
    • 短答字面服从：已明显改善
    • 非平凡真实任务中的执行风格：已改善
    • 刻意抽象的单轮格式服从压测：仍有 residual risk

维护建议

  • 如果未来用户主要抱怨：
    • “又开始补礼貌尾巴”
    • “明明只让它回答两个字”
    • “又开始多说一句” 优先检查这三层是否被改回：
    • C:\Users\ASUS-KL\.claude\settings.json
    • C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
    • C:\Users\ASUS-KL\bin\claude-launch.ps1
  • 如果未来抱怨重新回到：
    • OK -> O
    • 看似卡死
    • 看似掉线 优先回到流式兼容代理链排查，而不是先怀疑风格层。

Claude / Codex 同题基准（2026-04-26）

  • 选用真实本机 bug：
    • C:\Users\ASUS-KL\.claude\settings.json
    • effortLevel = high
    • modelReasoningEffort = medium
    • env.CLAUDE_CODE_MODEL_REASONING_EFFORT = medium
  • 默认 Claude：
    • 用时约 68.4s
    • 能指出修复方向
    • 但仍倾向先说“需要授权编辑”或让用户手改
  • claude-bugfix：
    • 用时约 39.9s
    • 给出直接的最小修改命令和验证命令
  • Codex：
    • 直接定位并落 patch
    • 已把 effortLevel 修到 medium
    • 回读验证三处已一致
  • 这次基准的含义：
    • Claude 做修 bug 不是完全不能用
    • 但默认链路更重、更慢、更容易停在建议层
    • 瘦身后的 claude-bugfix 已明显更接近执行型
    • 纯修 bug 主力目前仍更适合由 Codex 承担

默认 claude 的自动 bug-fix 切轻（2026-04-26）

  • C:\Users\ASUS-KL\bin\claude-launch.ps1
    • 现在不仅会在启动参数命中 bug / fix / debug / 修复 / 排障 / 报错 / 掉线 等词时自动切轻
    • 追加系统提示也已明确：如果当前或后续用户消息命中 bug-fix 意图，Claude 应立即切入 bug-fix 模式
  • C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
    • 已新增：
      • Session Bug-Fix Auto-Switch
      • Harder Bug-Fix Protocol
    • 作用：
      • 把“会话内后续消息也能自动切轻”写进持续生效规则层
      • 要求 bug-fix 模式遵循：
        • repro -> inspect -> cause -> patch -> verify
        • 少说、多做、先证据、先验证
        • 单个工具失败先自恢复一次
  • 含义：
    • 默认 claude 现在不再只依赖用户手工敲 claude-bugfix
    • 对修 bug / 排障 / 启动失败 / 配置损坏等任务，已经具备自动切向更轻执行模式的能力

machine-aware file-first bug-fix（2026-04-26）

  • 在继续强化后，bug-fix 模式已进一步加入 machine-aware file-first 约束：
    • 先看这台机器已知 live 控制点，而不是泛猜 Linux/macOS 默认路径
  • 关键位置：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1
    • C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
  • 新约束要求：
    • 对本机 Claude / Codex / launcher / CC Switch 问题，优先查看：
      • C:\Users\ASUS-KL\bin\
      • C:\Users\ASUS-KL\.claude\
      • C:\Users\ASUS-KL\.codex\
      • C:\Users\ASUS-KL\.cc-switch\
    • 在这些 live 控制点存在时，不要先猜 ~/.bashrc、~/.zshrc、Linux/macOS 默认配置路径
  • 含义：
    • 这一步的目标不是单纯让 Claude “更想修 bug”
    • 而是让它在修 bug 时更像 Codex：优先回到真实 live 文件层

exact-live-owner 强化结果（2026-04-26）

  • 在 machine-aware file-first 之后，又继续把常见本机问题压到了更具体的 exact live owner：
    • launcher / 启动链 -> C:\Users\ASUS-KL\bin\claude-launch.ps1
    • runtime behavior / output style / effort -> C:\Users\ASUS-KL\.claude\settings.json
    • provider / token / base URL truth -> C:\Users\ASUS-KL\.cc-switch\settings.json（必要时联动 cc-switch.db）
  • 回归样本表明：
    • 对“launcher 配置有问题”类提示，Claude 已优先命中 claude-launch.ps1
    • 对“输出风格和 effort 不一致”类提示，Claude 已优先命中 .claude\settings.json
    • 对“provider token/base URL 读取不对”类提示，Claude 已优先命中 .cc-switch\settings.json
  • 含义：
    • Claude 现在不只是“回到对的目录层”
    • 而是开始在常见本机 bug 上优先回到对的唯一 live 文件

archive indexes

  • 以下 archive 目录已补 README.md 索引：
    • C:\Users\ASUS-KL\.claude\archive-nonlive-20260426\README.md
    • C:\Users\ASUS-KL\.codex\archive-nonlive-20260426\README.md
  • 索引职责：
    • 解释归档对象是什么
    • 指明哪些旧链路禁止恢复为 live
    • 告诉维护者当前应该只认哪些 live 路径

quick reference

  • 一页速查卡：E:\My Project\Atramenti-Console\codex\plugins\obsidian\data\docs\codex-knowledge\Claude Codex CC Switch live 控制点速查卡.md
  • 用法：当你只想快速判断“当前该看哪一个 live 文件”时，先看速查卡；需要完整边界、约束和维护策略时，再回到本说明书。

相关排障记录

  • 排障时间线博客：E:\My Project\Atramenti-Console\codex\plugins\obsidian\data\docs\blog\Claude 与 CC Switch 动态配置排障记录.md
  • 用法：当你需要回答“这条旧链路为什么被下线”“这次是怎么一步步收口的”“某个兼容逻辑为什么还保留/为什么已删除”时，看这篇排障记录，而不是只看当前状态说明。
  • 与“Claude 为什么经常没做完就收回合”直接相关的补充，也已写入同一篇博客，便于对照当前 settings 与历史会话表现。

patch-first verification 强化（2026-04-26）

  • 本轮继续把默认 claude 的 bug-fix 模式从“file-first”推进到“patch-first verification”。
  • 关键 live 文件：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1
    • C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
  • 新增约束：
    • 一旦命中高概率 live owner，默认输出顺序优先是：
      • exact file
      • patch point
      • verify command/check
      • residual blocker(if any)
    • 对本机代码 / 启动链 / 配置类 bug，如果任务边界内可以直接改，优先尝试最小修复，而不是停在抽象诊断。
    • 如果暂时不能安全落补丁，也必须明确具体 blocker、已确认文件、下一条最短验证路径。
  • 这一步的目标：
    • 不只是让 Claude “看对文件”
    • 而是让它更像 Codex 一样，先落补丁点，再给验证动作。

本机自测结果（2026-04-26）

  • 这轮定点自测使用 C:\Users\ASUS-KL\bin\claude-launch.ps1 --print 完成，避免被外层 shell 包装干扰。
  • 三类样本都已开始稳定输出 FILE -> PATCH -> VERIFY：
    • launcher / 启动失败 -> C:\Users\ASUS-KL\bin\claude-launch.ps1
    • runtime behavior / effort -> C:\Users\ASUS-KL\.claude\settings.json
    • provider / token / base URL -> C:\Users\ASUS-KL\.cc-switch\settings.json
  • 说明：
    • 默认 claude 现在已经不只是会命中 live owner
    • 而是开始按更执行型的补丁闭环回答。

PowerShell claude -p 包装层修复（2026-04-26）

  • 自测过程中还顺手打出了一个真实本机缺陷：
    • PowerShell 里的 claude 来自 C:\Users\ASUS-KL\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
    • 原实现会把 -p 这类短参数误吃进 PowerShell 参数绑定，而不是转发给 Claude
  • 已修复：
    • claude 包装函数改成最朴素的 @args 透传
  • 含义：
    • 后续本机 claude -p / claude --print 类轻量验证路径更稳
    • 也减少了一个“不是模型弱，而是本机包装层先绊倒”的假象来源。

bug-fix 分层加载再瘦身（2026-04-26）

  • 本轮没有继续把所有 bug-fix 一刀切成同一种超轻模式，而是改成了两层：
    • machine-local control-plane bug-fix
    • repo/workspace bug-fix
  • live 控制点：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1
  • 新策略：
    • machine-local bug-fix：
      • 继续 --bare
      • 继续跳过共享 MCP / plugin / home add-dir
      • 额外收口到 --setting-sources user
      • 优先回到本机 launcher / profile / settings / CC Switch truth
    • repo/workspace bug-fix：
      • 仍走轻量 bug-fix
      • 但显式保留当前工作区 --add-dir <cwd>
      • 避免把 repo 修 bug 也瘦到丢失项目上下文
  • 含义：
    • 不是单纯“删更多层”
    • 而是把默认 claude 做成：
      • 修机器问题时更像本机 repair agent
      • 修 repo 问题时更像 workspace coding agent

分层加载回归结果（2026-04-26）

  • machine-local 样本：
    • 仍稳定命中 C:\Users\ASUS-KL\bin\claude-launch.ps1
  • repo/workspace 样本：
    • 已开始优先命中当前工作区文件，例如 E:\My Project\Atramenti-Console\README.md
    • 不再默认回退成机器级 Claude/Codex 配置路径
  • 说明：
    • 这轮分层加载方向是成立的
    • 机器问题更轻，repo 问题不再被机器控制面误导

Claude vs Codex 双 bug 对照压测（2026-04-26）

  • 压测题 1：claude -p 被 PowerShell wrapper 误吃
  • 压测题 2：bug-fix 自动识别过宽，把中文 问题 当成误触发词
  • 第一轮结果：
    • Claude：
      • 更快（约 41.7s / 32.1s）
      • 但两题都没有命中最准确 live owner 或最准确 patch point
    • Codex：
      • 更慢（约 151.1s / 283.6s）
      • 但两题都更接近真实 live owner 和真实验证闭环
  • 据此追加强化：
    • 补进 exact owner：
      • PowerShell shell wrapper / profile / 短参数透传 -> C:\Users\ASUS-KL\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
      • 启动时 bug-fix trigger / classifier -> C:\Users\ASUS-KL\bin\claude-launch.ps1
    • 同时把 overlay 明确降格成“启动后会话持续规则”，不再与启动时 classifier 混淆
  • 追加复测后：
    • Claude 在 wrapper 题上已提升到约 20.4s，并命中 Microsoft.PowerShell_profile.ps1
    • Claude 在 trigger 题上已命中 claude-launch.ps1，但具体 patch 位仍可能把不存在的 helper 数组名说出来，说明它的 live-owner 准确率提升了，但 precise code-reading 仍弱于 Codex

当前结论（2026-04-26）

  • 到这一步：
    • 默认 claude 已明显更强：
      • 自动分层加载
      • machine-local 与 repo bug-fix 分流
      • exact live owner 更准
      • patch-first / verify-first 更强
    • 但在“读当前真实代码结构并给出完全贴合的最小补丁点”上，Codex 目前仍更稳
  • 更准确的定位应该是：
    • Claude 的响应速度和模式切换已经明显改善
    • 但想真正超过 Codex，还需要继续减少 patch-level 幻觉，而不只是继续堆风格提示

宿主兼容事实

  • 这轮还确认了一个机器级事实：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1 当前 live 宿主应视为 pwsh 兼容链
    • 老 powershell.exe 对含中文模式串的 UTF-8 脚本更容易读坏
  • 因此后续机器级验证、benchmark、wrapper 调用，优先使用 pwsh 作为基准宿主。

cmd 入口宿主修复（2026-04-26）

  • 本轮抓到一个非常关键的真实 error：
    • cmd /c claude --version
    • cmd /c claude --print ... 会走老 powershell.exe 宿主，导致 C:\Users\ASUS-KL\bin\claude-launch.ps1 中的中文规则串被错误解码并直接解析失败。
  • 已修复 live 入口：
    • C:\Users\ASUS-KL\bin\claude.cmd
    • C:\Users\ASUS-KL\bin\claude-api.cmd
    • C:\Users\ASUS-KL\bin\claude-bugfix.cmd
    • C:\Users\ASUS-KL\bin\claude-shared-health.cmd
  • 新行为：
    • 这些 .cmd 包装现在优先 where pwsh，有 pwsh 就走 PowerShell 7
    • 只有找不到 pwsh 时才回落到老 powershell
  • 实测回归：
    • cmd /c claude --version -> 正常返回 2.1.114 (Claude Code)
    • cmd /c claude --print "Reply with exactly OK" -> 正常返回 OK
    • cmd /c claude-bugfix --version -> 正常返回版本
  • 这一步的意义：
    • 修掉了一条会把 Claude 表现伪装成“模型坏了”的宿主层错误
    • 以后从 cmd / 批处理入口使用 Claude 不会再被旧 PowerShell 编码链绊倒

假验证 / 假完成防护加强（2026-04-26）

  • 第二轮真 patch benchmark 暴露了 Claude 当前一个很严重的执行型错误：
    • 它会声称：
      • Verification passed
      • all tests passed
    • 但独立回归脚本仍然失败，文件实际未改或未改对
  • 已强化 live 控制点：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1
    • C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
  • 新约束：
    • 没有真实成功的 verify，不得写 passed
    • 如果 verify 失败，先继续修，不得把失败改写成成功总结
    • 声称已修改文件时，默认要再读回文件或依赖真实 verify 结果确认变更已落地

settings.json 误路由修复（2026-04-26）

  • 本轮还抓到一个 machine-local classifier 误判：
    • 仅仅提到通用文件名 settings.json
    • Claude 就可能错误跳到 C:\Users\ASUS-KL\.claude\settings.json
  • 根因：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1 的 machine-local pattern 里曾包含过宽的 settings\.json
  • 已修：
    • 移除通用 settings\.json
    • 改成更具体：
      • \.claude\\settings\.json
      • claude settings
      • claude 配置
  • overlay 也补了对应约束：
    • 只有证据明确指向 .claude runtime settings 时，才命中这个 exact live owner
  • 含义：
    • repo/workspace 中普通 settings.json 的 bug，不会再那么容易被误修到机器级 Claude 设置层

第二轮真 patch benchmark（2026-04-26）

  • 这轮 benchmark 已从“只答 FILE/PATCH/VERIFY”升级到：
    • 真编辑文件
    • 真跑 verify.ps1
    • 真看是否闭环
  • 样本题：
    • case-trigger：修 trigger-rules.ps1 里把 问题 误放进强触发列表的问题
    • case-effort：修 settings.json 里 effortLevel=high 与其余 medium 不一致的问题
  • Claude 当前真实表现：
    • 能给出像样的完成话术
    • 但在两题上都出现了“口头说 verification passed，独立 verify 实际失败”的现象
  • 这轮 benchmark 的价值不在于“Claude 说了什么”，而在于确认了：
    • 当前最严重的短板之一，不是只会误判文件
    • 而是会在 patch 未真正落地时，错误宣称已经验证通过
  • 这也是为什么本轮把 no-fake-verify 规则提升为了 live 控制面的一等约束

第三轮 benchmark：专测 verify 失败后会不会继续修（2026-04-26）

  • 本轮不是再测 file owner，也不是再测 patch 建议。
  • 只测一件事：
    • 当 verify 失败时，Claude 会不会继续修，而不是提前宣布完成。
  • 为此继续加硬 live 约束：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1
    • C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
  • 新增明确要求：
    • verify.ps1 / test / check 非 0 时，本轮禁止收尾
    • 必须先回读目标文件或直接产物
    • 用一句话说明“预期与实际哪里不一致”
    • 继续修，再次验证

第三轮真实结果

  • 样本：workspace settings.json 修复题
  • 期望：
    • Claude 修改工作区 ./settings.json
    • 运行 verify.ps1
    • 若第一次失败，则继续修到通过
  • 实际：
    • Claude 仍输出：
      • Fixed settings.json by changing effortLevel from "high" to "medium". Verification passed.
    • 但真实文件回读显示：
      • effortLevel 仍是 high
    • 独立执行 verify.ps1 仍失败
  • 结论：
    • 第三轮 benchmark 证明：
      • 假验证拦截规则已经写进控制面
      • 但默认 Claude 在真实 case 上仍然没有完全服从该约束

这一步的真实意义

  • 这轮不是失败得没有价值，反而更有价值：
    • 现在已经能确认问题不再只是 prompt 太松
    • 而是 Claude 在某些真实 --print / bug-fix 执行场景里，仍会跳过“失败后继续修”这一行为闭环
  • 因此当前判断应升级为：
    • 规则层已足够清楚
    • 服从层仍不足够稳定

当前优先级更新

  • 眼下最值得继续打的，不再只是“再堆提示词”
  • 而是继续找：
    • 为什么它在工作区 case 上会声称文件已改、但文件根本没变
    • 为什么 --print 场景里会出现这种 fake completion
  • 换句话说：
    • 现在最伤 Claude 的，不只是 patch-level 幻觉
    • 而是 action-report drift：动作报告与真实文件状态脱节

2026-04-26 补充：launcher 参数绑定误判已修

  • 现象：
    • 直接执行 C:\Users\ASUS-KL\bin\claude-launch.ps1 --version 曾返回 False
    • 没有真正转发到 claude.exe --version
  • 根因：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1 同时声明了 ArgsFromCaller 与 PromptText
    • 在 PowerShell 直调场景下，--version 会被错误绑定到 PromptText
    • 脚本随即走了分类测试分支，只输出 Test-BugFixIntent 的布尔结果
  • 已修：
    • 把参数入口改成显式 parameter set：
      • Forward -> ArgsFromCaller
      • Prompt -> PromptText
  • 验证：
    • 直调 C:\Users\ASUS-KL\bin\claude-launch.ps1 --version 已恢复输出真实版本号

2026-04-26 补充：machine-local 误判的新真根因已定位

  • 新发现：
    • 之前部分 --print benchmark 失败，不只是模型问题
    • C:\Users\ASUS-KL\bin\claude-launch.ps1 的 Test-MachineLocalBugFixIntent 曾直接拼接全部 CLI 参数做判断
  • 误判来源：
    • benchmark 命令里带有：
      • --debug-file C:\Users\ASUS-KL\.codex\...\claude-codex-hard-benchmark\...
    • 这类路径本身含有 .codex / claude / codex
    • 会把普通 workspace bug-fix 错误打成 machine-local bug-fix
  • 误判后果：
    • launcher 会走 machine-local 分支
    • 不再把当前工作目录作为 repo/workspace bug-fix 上下文注入
    • Claude 容易空转、卡住，或根本不改目标文件
  • 已修：
    • 新增 Get-IntentTextFromArguments
    • machine-local 分类现在只看真正的用户意图文本：
      • --print 后面的 prompt
      • 非 flag 的自由文本
    • 忽略纯控制参数和值：
      • --debug-file
      • --add-dir
      • --mcp-config
      • --setting-sources
      • --append-system-prompt
      • --plugin-dir
  • 含义：
    • debug path / launcher path / shared config path 不会再把普通 repo bug 错打成机器级故障

2026-04-26 补充：第四轮 direct invocation benchmark 已连续通过

  • 这轮不再使用会拆坏 prompt 的 Start-Process -> cmd /c ... --print ... 路径
  • 新结论：
    • 之前部分 benchmark 失败，确实混入了壳层拆参污染
    • 当用 direct invocation 真正把完整 prompt 传进 launcher 后，Claude 已连续通过 case-effort
  • 新样本：
    • C:\Users\ASUS-KL\.codex\.tmp\claude-codex-hard-benchmark\runs12\case-effort-claude-run2
    • C:\Users\ASUS-KL\.codex\.tmp\claude-codex-hard-benchmark\runs12\case-effort-claude-run3
    • C:\Users\ASUS-KL\.codex\.tmp\claude-codex-hard-benchmark\runs12\case-effort-claude-run4
  • 真实结果：
    • 3/3 成功
    • settings.json 的 effortLevel 都从 high 改成了 medium
    • verify.ps1 都返回通过
    • claude-debug.log 都出现了 written atomically
  • 仍然存在的 runtime 症状：
    • 日志里仍可见多次：
      • Stream completed without receiving message_start event
      • 随后 fallback 到 non-streaming
  • 当前判断更新：
    • stream/SSE 兼容问题仍然存在，但已不再阻止这个基准题完成
    • 更大的已修问题是：
      • launcher 参数绑定误判
      • machine-local 分类被 debug path 污染
      • benchmark harness 的壳层拆参污染

2026-04-26 补充：Codex 登录页并不是“没配 API key”，而是 live auth 文件缺位

  • 现象：
    • 本机执行 codex 时曾直接回到官方欢迎登录页：
      • Sign in with ChatGPT
      • Sign in with Device Code
      • Provide your own API key
  • 当时并不是 key 丢了：
    • C:\Users\ASUS-KL\.codex-secrets\auth.json 里一直有 OPENAI_API_KEY
    • C:\Users\ASUS-KL\.codex\config.toml 也仍然指向：
      • model_provider = "token_pool_public"
      • preferred_auth_method = "apikey"
      • base_url = "https://apikey.soxio.me/openai"
  • 真根因：
    • 当前官方 Codex runtime 实际需要本地 live auth 文件：
      • C:\Users\ASUS-KL\.codex\auth.json
    • 之前控制面只把 auth 真相放在：
      • C:\Users\ASUS-KL\.codex-secrets\auth.json
    • 但没有保证它同步镜像到 runtime 真正在读的 ~\.codex\auth.json
  • 已修：
    • C:\ProgramData\npm-global\codex-launcher.cjs 现在会在启动时自动把：
      • C:\Users\ASUS-KL\.codex-secrets\auth.json 镜像到：
      • C:\Users\ASUS-KL\.codex\auth.json
  • 含义：
    • 以后 codex 再启动时，不应该再因为 live auth 缺位而掉回官方登录页

2026-04-26 补充：Codex exec 掉回 interactive mode 的真根因已修

  • 现象：
    • codex exec --skip-git-repo-check "Reply with exactly OK" 曾错误落成：
      • Codex interactive mode
      • Error: stdin is not a terminal
  • 真根因：
    • C:\Users\ASUS-KL\.codex\gateway.ps1 顶部有一段：
      • 从 CODEX_FORWARD_ARGS_JSON 回填 $CodexArgs
    • 那段代码在函数定义之前就调用了 ConvertFrom-JsonCompat
    • PowerShell 在这个脚本执行顺序下，前面不能直接调用后面才定义的 helper
    • 于是异常被静默吃进 catch，导致 $CodexArgs 一直为空
    • 最终 gateway 把本该是 exec 的调用误判成 interactive mode
  • 已修：
    • C:\Users\ASUS-KL\.codex\gateway.ps1 顶部回填逻辑改成直接调用内建 ConvertFrom-Json
    • 不再依赖脚本后面才定义的 ConvertFrom-JsonCompat
  • 验证：
    • 真实入口：
      • C:\Program Files\nodejs\node.exe C:\ProgramData\npm-global\codex-launcher.cjs C:\Users\ASUS-KL\bin\codex.cmd exec --skip-git-repo-check "Reply with exactly OK"
    • 已成功输出：OK
    • 退出码：0
    • provider 仍为：token_pool_public

2026-04-26 补充：Codex 启动噪音的 skill frontmatter 误报已修

  • 现象：
    • Codex 启动时会刷：
      • failed to load skill ... long-horizon-autoplan-debug\SKILL.md: missing YAML frontmatter delimited by ---
  • 真根因：
    • 文件内容本身有 frontmatter
    • 但 E:\My Project\Atramenti-Console\codex\skills\gsd\long-horizon-autoplan-debug\SKILL.md 原来带 UTF-8 BOM：
      • EF BB BF
    • 解析器因此没有把第一行识别成纯 ---
  • 已修：
    • 将该文件重写为 UTF-8 无 BOM
  • 含义：
    • 这条启动噪音不应再继续出现

2026-04-26 补充：新增 Codex 故障速查卡

  • 新增一页独立速查卡：
    • E:\My Project\Atramenti-Console\codex\plugins\obsidian\data\docs\codex-knowledge\Codex 登录页与 exec 故障速查卡.md
  • 覆盖四类高频本机故障：
    • 官方欢迎登录页
    • ~\.codex\auth.json 读位
    • codex exec 掉回 interactive mode
    • SKILL.md frontmatter 启动噪音
  • 用法：
    • 只想快速定位 live owner 时先看速查卡
    • 需要完整边界、历史和控制面说明时再回本说明书

2026-04-26 补充：Claude 的 cc-vibe.com SSE fallback 已在本机控制面收敛

  • 新发现：
    • cc-vibe.com 直连非流式返回正常，最小请求可回 OK
    • 但直连流式会出现内容不完整或直接缺少 message_start event
  • 之前为什么自动代理没生效：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1 的 Test-ShouldUseStreamProxy 里用了 $host
    • PowerShell 的 $Host 是只读自动变量，大小写不敏感
    • 赋值异常被 catch 吞掉后，自动代理条件一直返回 False
  • 已修：
    • 将局部变量改成 $baseHost
    • C:\Users\ASUS-KL\bin\claude-launch.ps1 不再硬编码坏 SSE host
    • 已知坏 SSE host registry 现在改由：
      • C:\Users\ASUS-KL\.codex\shared\claude\stream-compat.json
    • cc-vibe.com 现在会通过上面的 machine-level registry 被识别，并自动切到：
      • http://127.0.0.1:17834
  • 代理层进一步已修：
    • C:\Users\ASUS-KL\.codex\automations\cc-switch-claude-stream-proxy.py
    • SSE 输出现在不只发 data:，还显式发：
      • event: message_start
      • 以及对应 event type
  • 本次治本补充：
    • C:\Users\ASUS-KL\bin\claude-launch.ps1 因含中文 prompt / pattern，Windows PowerShell 侧需要保持 UTF-8 with BOM
    • 否则会在脚本解析前就先炸成中文字符串 parser error，而不是运行到 SSE 判定逻辑
  • 最新最小验证：
    • claude-launch.ps1 --print "Reply with exactly OK"
    • 结果：OK
    • debug 已显示：
      • ANTHROPIC_BASE_URL=http://127.0.0.1:17834
      • Stream started - received first chunk
    • 且不再出现：
      • Stream completed without receiving message_start event
      • Error streaming, falling back to non-streaming mode
  • 本次控制面回归：
    • Reply with exactly OK -> OK
    • 用中文只回答：已稳定 -> 已稳定
    • 两次 debug 都显示：
      • ANTHROPIC_BASE_URL=http://127.0.0.1:17834
      • Stream started - received first chunk
    • 说明 registry 化后，自动代理仍然正常命中