Claude 与 CC Switch 动态配置排障记录

目标

本次调整的目标不是把某个固定 token 写死，而是让 Claude Code 每次启动时都动态读取 CC Switch 当前选中的 Claude provider，避免以下问题反复出现：

• 旧的 ANTHROPIC_* 用户环境变量残留覆盖当前配置
• 旧 launcher / shared provider 把错误的 Base URL、Model、Token 注入进程
• C:\Users\ASUS-KL\.claude\settings.json 留下过期 token 副本
• CC Switch 当前 provider 已经变化，但 Claude 仍在吃旧值

当前 source of truth

当前 Claude 相关配置的真相源只保留为 CC Switch：

• CC Switch 主配置目录：C:\Users\ASUS-KL\.cc-switch\
• CC Switch 数据库：C:\Users\ASUS-KL\.cc-switch\cc-switch.db
• CC Switch 日志：C:\Users\ASUS-KL\.cc-switch\logs\cc-switch.log
• CC Switch 主设置文件：C:\Users\ASUS-KL\.cc-switch\settings.json
• 当前 Claude provider 指针字段：currentProviderClaude

Claude 本地侧不再保存 token 真值：

• C:\Users\ASUS-KL\.claude\settings.json 当前已清空为 {}，不再作为 token / base URL 真相源

CC Switch 当前数据库状态

在 providers 表中，当前选中的 Claude provider 为：

• id = ccvibe-1777173109177
• app_type = claude
• name = ccvibe
• is_current = 1

该 provider 的 settings_config 当前为：

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "sk-454e877d2448309833ad4e06d5cba7ab52ed3f0bf495b69af3ae52de087e8dd6",
    "ANTHROPIC_BASE_URL": "https://cc-vibe.com"
  }
}

这说明：

• 当前 CC Switch 数据库里的 Claude 配置是 cc-vibe.com
• token 当前来自 CC Switch 数据库记录，而不是手写在 Claude 配置里

launcher 当前行为

当前入口文件：

• C:\Users\ASUS-KL\bin\claude-launch.ps1

当前 launcher 已改为：

1. 启动时先清空当前进程里的旧 ANTHROPIC_*
2. 读取 C:\Users\ASUS-KL\.cc-switch\settings.json
3. 取出 currentProviderClaude
4. 到 C:\Users\ASUS-KL\.cc-switch\cc-switch.db 的 providers 表中查询对应 settings_config
5. 把查询到的 env 动态注入给 claude.exe

也就是说，Claude Code 现在是：

• 动态跟随 CC Switch 当前 provider
• 不依赖用户环境变量
• 不依赖 .claude\settings.json 中的 token 副本
• 不依赖旧 shared provider 的 model / token / base URL 注入

已清理的旧污染源

本次清理过的旧污染源包括：

• 用户环境变量中的：
  • ANTHROPIC_API_KEY
  • ANTHROPIC_AUTH_TOKEN
  • ANTHROPIC_BASE_URL
  • ANTHROPIC_MODEL
• C:\Users\ASUS-KL\.claude\settings.json 中曾经残留的：
  • https://api.longcat.chat/anthropic
  • LongCat-Flash-Thinking-2601
• launcher 中旧的：
  • 共享 provider 的 ANTHROPIC_MODEL 强注入
  • 旧 primaryApiKey fallback
  • 依赖 .claude\settings.json 常驻 token 副本的逻辑

运行时验证结论

在全新 PowerShell 进程中探测 launcher 最终喂给 claude.exe 的运行时环境，结果为：

• ANTHROPIC_AUTH_TOKEN = sk-454e877d2448309833ad4e06d5cba7ab52ed3f0bf495b69af3ae52de087e8dd6
• ANTHROPIC_BASE_URL = https://cc-vibe.com

并且不再自动注入：

• ANTHROPIC_MODEL
• LongCat-Flash-Thinking-2601
• claude-sonnet-4-20250514

这说明本机动态读取链路已经成立。

当前剩余问题

当前剩下的问题不再是“本机没用上 CC Switch 配置”，而是：

• cc-vibe 当前 token 对 Claude Code 请求返回 403
• 提示表现为：
  • Please run /login
  • API Error: 403 {"error":{"type":"forbidden","message":"Request not allowed"}}

这个现象更像是：

• token 失效
• token 没权限调用当前接口
• provider 套餐未开通 / 未绑定
• token 只适用于某类客户端，不适用于当前 Claude Code 请求

结论

本机现在已经达成以下状态：

• Claude 不再硬编码 token
• Claude 不再依赖用户环境变量里的 ANTHROPIC_*
• Claude 每次启动都动态读取 CC Switch 当前 provider
• CC Switch 是 Claude 配置的唯一真相源

因此，后续若再出现 Claude 鉴权失败，应优先排查：

1. CC Switch 当前 provider 是否正确
2. CC Switch 数据库中的 token 是否已变化
3. cc-vibe 上游是否拒绝该 token

而不应再优先怀疑本机 launcher / 用户环境变量 / .claude\settings.json 副本。

2026-04-26 补充：Claude 权限变回最小的根因与修复

• 根因不是 CC Switch token 丢了，而是 C:\Users\ASUS-KL\.claude\settings.json 被清成了 {}。
• 这会导致 Claude 丢失原本的高权限 / yolo 行为，于是重新开始频繁向用户要确认、要决定。
• 旧的高权限配置其实还在 C:\Users\ASUS-KL\.cc-switch\cc-switch.db 的 settings.common_config_claude 里。
• 修复方式：把其中与权限/运行模式相关的安全配置恢复回 C:\Users\ASUS-KL\.claude\settings.json，但刻意排除：
  • ANTHROPIC_AUTH_TOKEN
  • ANTHROPIC_BASE_URL
  • ANTHROPIC_* 模型相关字段
  • 顶层硬编码 model
• 这样现在的职责边界变成：
  • C:\Users\ASUS-KL\bin\claude-launch.ps1：每次启动时动态从 CC Switch 当前 provider 读取 token/base URL
  • C:\Users\ASUS-KL\.claude\settings.json：只负责 yolo 权限、sandbox、approval、自动确认等行为设置
• 当前确认结果：
  • approvalPolicy = never
  • sandboxMode = danger-full-access
  • permissions.defaultMode = bypassPermissions
  • .claude\settings.json 中已无 model 字段
  • .claude\settings.json 的 env 中已无 ANTHROPIC_* 硬编码
• 如果后面再出现 403 / Please run /login，那通常是上游 provider（例如 cc-vibe）对当前 token 的授权问题，不再是本地读取链路的问题。

2026-04-26 补充：彻底统一 Claude 与 Codex 的 live 控制层

Claude 统一结果

• C:\Users\ASUS-KL\.claude\config.json 原先还残留一套备用 auth：primaryApiKey = sk-local-claude-glm-bridge-20260420。
• 这会和 CC Switch -> claude-launch.ps1 的动态 provider 链并行存在，属于第二真相源。
• 已处理为只保留最小非认证配置：
  • 当前 C:\Users\ASUS-KL\.claude\config.json 仅剩 permissions 空规则
  • 认证不再从这里读取
• 当前 Claude 的 live 职责边界：
  • C:\Users\ASUS-KL\bin\claude-launch.ps1：动态读取 CC Switch 当前 provider
  • C:\Users\ASUS-KL\.claude\settings.json：只负责 yolo 权限 / sandbox / approval 行为
  • C:\Users\ASUS-KL\.claude\config.json：不再承载备用 API key

Codex 统一结果

• Codex 之前之所以总出现 controlled interactive mode，控制点在：
  • C:\ProgramData\npm-global\codex-launcher.cjs
  • C:\Users\ASUS-KL\.codex\industrial-control\policies\interactive-policy.json
  • C:\Users\ASUS-KL\.codex\gateway.ps1
• 已做的修复：
  1. interactive-policy.json 中 interactive_mode.enabled 改为 false
  2. codex-launcher.cjs 现在会尊重这个开关，不再无条件注入 controlled prompt
  3. codex-launcher.cjs 对 --version / --help 做 launcher 级直通，不再进 gateway
  4. gateway.ps1 修正管理参数 bypass 顺序，并补了 CODEX_FORWARD_ARGS_JSON 的读取
• 验证结果：
  • codex --version 现在直接返回：codex-cli 0.123.0-alpha.5
  • codex --help 现在直接输出帮助，不再跳进 controlled interactive mode

当前结论

• Claude：主认证真相源已收敛为 CC Switch
• Claude：权限层与 provider 层已分离，避免再因为 token/provider 调整把 yolo 权限一并搞乱
• Codex：受控交互限制链已关闭到 live 直通状态
• 仍然可能存在历史备份、日志、file-history、glm-gateway 遗留文件，但它们不再是当前 live 控制层

2026-04-26 补充：完全删除 GLM 残留与下线旧 unified-config 链

GLM Gateway 删除结果

• 用户已明确要求完全删除 GLM 相关本地残留。
• 已删除目录：C:\Users\ASUS-KL\.claude\glm-gateway
• 删除验证结果：
  • Test-Path C:\Users\ASUS-KL\.claude\glm-gateway 返回 False
• 删除后复扫当前 live 控制文件，未再发现以下旧链路引用：
  • glm-gateway
  • supervise-claude-glm-gateway
  • run-claude-glm-gateway
  • 127.0.0.1:4000
  • litellm
• 结论：旧的本地 GLM / LiteLLM 转发链已经完全退出当前 Claude live 链路。

旧 unified-config 链下线结果

• 核查确认 C:\Users\ASUS-KL\.codex\claude\unified-config.json 并不属于当前 live 启动链。
• 同时确认 C:\Users\ASUS-KL\.codex\shared\tools\sync-config.sh 只是旧统一配置方案的辅助脚本，不再被当前 launcher / gateway / bin 包装层使用。
• 已归档到 C:\Users\ASUS-KL\.codex\archive-nonlive-20260426：
  • C:\Users\ASUS-KL\.codex\shared\tools\sync-config.sh
  • C:\Users\ASUS-KL\.codex\claude\unified-config.json
  • C:\Users\ASUS-KL\.codex\claude\hooks
  • C:\Users\ASUS-KL\.codex\claude\plans
  • C:\Users\ASUS-KL\.codex\claude\settings
  • 空壳目录 C:\Users\ASUS-KL\.codex\claude
• 验证结果：
  • Test-Path C:\Users\ASUS-KL\.codex\claude 返回 False
  • Test-Path C:\Users\ASUS-KL\.codex\shared\tools\sync-config.sh 返回 False
• 当前再次检索时，仅剩以下位置还提到旧 unified-config 结构：
  • 归档副本：C:\Users\ASUS-KL\.codex\archive-nonlive-20260426\...
  • 说明文档：C:\Users\ASUS-KL\.codex\shared\claude\unified-config-plan.md
• 结论：旧 unified-config 方案已经完成下线，不再参与当前 Codex / Claude 的 live 配置链。

当前 live 控制点收口结论

• Claude live 控制点：
  • C:\Users\ASUS-KL\bin\claude-launch.ps1
  • C:\Users\ASUS-KL\.cc-switch\settings.json
  • C:\Users\ASUS-KL\.cc-switch\cc-switch.db
  • C:\Users\ASUS-KL\.claude\settings.json
  • C:\Users\ASUS-KL\.claude\config.json
• Codex live 控制点：
  • C:\Users\ASUS-KL\bin\codex.ps1
  • C:\ProgramData\npm-global\codex-launcher.cjs
  • C:\Users\ASUS-KL\.codex\gateway.ps1
  • C:\Users\ASUS-KL\.codex\config.toml
  • C:\Users\ASUS-KL\.codex\industrial-control\policies\interactive-policy.json
• 至此，本机上与本轮排障直接相关的旧 provider / GLM 转发 / unified-config 旧同步链都已经从 live 路径中剥离。

2026-04-26 补充：兼容脚本中的 GLM 特判也已清除

• 在完成 live 配置层、归档层、旧 unified-config 链下线后，又对 .codex\automations 中的兼容脚本做了最后清理。
• 本次处理文件：
  • C:\Users\ASUS-KL\.codex\automations\sync-claude-shared-runtime.ps1
  • C:\Users\ASUS-KL\.codex\automations\check-claude-codex-shared-runtime.ps1

清理内容

• sync-claude-shared-runtime.ps1
  • 删除了“如果存在 glm-gateway\run-claude-glm-gateway.ps1，就把默认 Claude Base URL 设为 http://127.0.0.1:4000”的旧兼容分支。
• check-claude-codex-shared-runtime.ps1
  • 删除了把 http://127.0.0.1:4000 当成特殊例外的旧判断。

验证结果

• 对上述两份脚本复扫后，已不再出现：
  • glm
  • litellm
  • 127.0.0.1:4000

最终收口结论

• 至此，旧的 GLM / LiteLLM / 本地 4000 代理 残留已经从以下四层全部清除：
  1. live 启动链
  2. live 配置文件
  3. 兼容/自动化脚本
  4. 旧 unified-config 同步链
• 后续如果再搜索到相关关键词，通常只会出现在：
  • archive-nonlive-20260426 归档目录
  • file-history / projects / history.jsonl 等历史记录区
  • 个别说明文档或 changelog
• 这些位置都不再参与当前实际运行时控制。

2026-04-26 复盘：让项目更有条理、更稳定的长期原则

这次排障得到的核心经验

• 不是“配置太多”本身危险，而是“同一类事实被多份 live 文件同时控制”。
• 表面能跑不代表系统清晰；真正稳定的系统必须能回答“到底哪份配置在生效”。
• 历史残留如果不分层，会持续污染排障判断；备份、旧脚本、废弃网关、旧文档不应与 live 文件并列放在根目录。
• 修复不能只修当前报错，还要顺手降低未来复发路径；否则只是把混乱短暂压住。

一个更稳定项目应具备的因素

• 单一真相源：provider、permission、launcher、gateway 各只有一个 live owner。
• 清晰职责边界：认证层、权限层、启动层、运行层、文档层分开。
• live / archive / history 分层：当前生效、归档、历史记录不能混在一起。
• 可追踪启动链：从命令入口到最终控制文件应能一路追清。
• 兼容逻辑可退场：临时过渡分支存在时，要明确退场条件，稳定后及时移除。
• 文档和 machine-readable facts 同步：人看的说明书与脚本可读的 registry / state 要一起维护。
• 验证闭环：修改后要验证真实运行路径，而不是只看文件内容。

已固化到长期治理层的规则方向

• 本机多工具控制面默认强制单一 live truth，不允许 parallel truth 与当前 live 路径并列。
• 旧 proxy/provider/unified-config 方案一旦退场，就应降级到 archive/history，不再挂在 live 根目录。
• 机器级控制面变更默认同时更新：
  • Markdown 控制面说明书
  • machine-readable JSON facts layer
  • 必要时的全局规则 / 门禁层
• 后续遇到类似问题，应优先定位 controlling entrypoint 和 controlling config，再看 archive/history，而不是先做 broad search。

2026-04-26 补充：新增独立 control-plane JSON 与一键体检脚本

新增文件

• E:\My Project\Atramenti-Console\codex\plugins\obsidian\data\docs\codex-knowledge\claude-codex-control-plane.json
• E:\My Project\Atramenti-Console\codex\plugins\obsidian\data\docs\codex-knowledge\claude-codex-control-plane.schema.json
• C:\Users\ASUS-KL\.codex\automations\check-claude-codex-control-plane.ps1

目的

• 不再只靠 Markdown 说明当前控制面，而是增加独立 machine-readable facts 文件。
• 让未来 agent、脚本、排障流程可以先读取 claude-codex-control-plane.json，而不是从多个文档和配置中猜测当前 live truth。
• 提供一个一键体检入口，快速确认当前控制面是否发生漂移。

体检脚本当前验证结果

• controlPlaneLoaded = true
• providerPointer = ccvibe-1777173109177
• approvalPolicy = never
• sandboxMode = danger-full-access
• interactivePolicyEnabled = false
• forbiddenLegacyChains.anyPresent = false

含义

• 当前 Claude / Codex / CC Switch 控制面不仅有人类可读说明书，也已经具备：
  • 机器可读 truth layer
  • 可执行健康检查入口
  • 可验证的 forbidden legacy chain 检查
• 这使得后续维护不再依赖口头记忆或历史聊天，而可以直接先读 JSON、再跑脚本、最后看说明书。

2026-04-26 补充：成品化收尾（注释、快捷入口、archive 索引）

新增快捷入口

• 新增 bin 级体检入口：C:\Users\ASUS-KL\bin\check-control-plane.cmd
• 该命令直接调用：C:\Users\ASUS-KL\.codex\automations\check-claude-codex-control-plane.ps1
• 作用：以后不需要再记完整 PowerShell 路径，直接跑一个短命令就能体检当前控制面。

三个 live 脚本已补控制面注释

• C:\Users\ASUS-KL\bin\claude-launch.ps1
• C:\ProgramData\npm-global\codex-launcher.cjs
• C:\Users\ASUS-KL\.codex\gateway.ps1

这些注释明确写清：

• 哪一层是当前 truth owner
• 不要把什么旧链路恢复回来
• 不要把 token/base URL/model 写回错误配置层

archive 索引已补齐

• C:\Users\ASUS-KL\.claude\archive-nonlive-20260426\README.md
• C:\Users\ASUS-KL\.codex\archive-nonlive-20260426\README.md

索引目的：

• 防止未来把 archive 当 live 根目录的一部分来理解
• 明确这些归档对象为什么退场
• 明确当前 live 配置只认哪些路径

含义

• 到这一步，当前系统已经具备：
  • 全局规则层
  • 机器级说明书
  • machine-readable control-plane JSON
  • 一键体检脚本
  • bin 级快捷入口
  • archive 索引
• 这意味着这套控制面已经不仅“能用”，而且具备：
  • 可解释
  • 可验证
  • 可回看
  • 可维护
  • 可防复发

2026-04-26 补充：旧 ANTHROPIC 环境变量会话污染已做 shell 层自动清场

现象

• 当时继续体检时，发现当前对话所在 PowerShell 进程里仍然带着旧值：
  • ANTHROPIC_API_KEY = sk-local-claude-glm-bridge-20260420
  • ANTHROPIC_AUTH_TOKEN = sk-local-claude-glm-bridge-20260420
  • ANTHROPIC_BASE_URL = http://127.0.0.1:4000
  • ANTHROPIC_MODEL = claude-sonnet-4-20250514
• 这些值会让人误以为机器上仍有 live 的 GLM / 本地 4000 Claude 桥接链在生效。

追源结果

• 用户级与机器级持久环境变量里，这些 ANTHROPIC_* 键已经是空值。
• 当前污染不来自：
  • CC Switch
  • C:\Users\ASUS-KL\.claude\settings.json
  • C:\Users\ASUS-KL\.codex\config.toml
  • 当前 live launcher / gateway 再次硬编码注入
• 根因是：某些已经打开的旧 shell / 父进程环境仍继承着早期 GLM / LiteLLM / 127.0.0.1:4000 桥接时代的进程级环境变量。

风险判断

• 这属于“当前会话污染”，不是“机器级持久 live 控制面冲突”。
• 它不会重新定义 Claude 的 live provider truth，因为：
  • C:\Users\ASUS-KL\bin\claude-launch.ps1 启动时会先清掉 ANTHROPIC_*
  • 然后只从 CC Switch 当前 provider 重新注入有效值
• 它也不会重新定义 Codex 的 provider truth，因为 Codex 当前 live provider 只看 .codex 自己的配置链。

清场动作

• 为了防止旧父进程把这些脏值继续带进未来新开的终端，会话层补了一道自动清理：
  • C:\Users\ASUS-KL\Documents\PowerShell\profile.ps1
  • C:\Users\ASUS-KL\Documents\WindowsPowerShell\profile.ps1
• 两个 profile 现在都会在 shell 启动时主动移除：
  • ANTHROPIC_API_KEY
  • ANTHROPIC_AUTH_TOKEN
  • ANTHROPIC_BASE_URL
  • ANTHROPIC_MODEL
  • ANTHROPIC_DEFAULT_SONNET_MODEL
  • ANTHROPIC_DEFAULT_OPUS_MODEL
  • ANTHROPIC_SMALL_FAST_MODEL

验证结果

• 新开的 pwsh 会话中，上述关键 ANTHROPIC_* 变量都已为空。
• 新开的 Windows PowerShell 会话中，上述关键 ANTHROPIC_* 变量也都已为空。
• 这说明：
  • 旧污染不会再自动传染到未来新 shell
  • 当前 live 控制面与 shell 会话层现在已经都收口

含义

• 到这一步，当前系统不只清掉了：
  • live 配置残留
  • live 启动链残留
  • 兼容脚本残留
  • unified-config 残留
• 还额外清掉了“旧祖先进程环境对未来新 shell 的污染路径”。
• 这使得后续排障时可以更明确地区分：
  • 机器级 live truth
  • 当前单个旧 shell 会话的脏环境
  • archive / history / debug 里的历史痕迹

2026-04-26 补充：Claude 提前收回合的短回合倾向已做配置与规则双修复

现象

• 用户持续感知到：Claude 有时不是“崩掉”，而是“任务还没真正闭环就自己停了”。
• 最近会话记录里，能看到多次正常 assistant -> tool_use -> tool_result -> assistant 循环，但回合末尾仍以 stop_reason = end_turn 正常结束。
• 这说明主问题更像“过早收回合”，而不是“provider 硬断流”。

会话证据判断

• 最近会话尾部中，能看到明确的 stop_reason = end_turn 与 turn_duration 结束记录。
• 说明至少最近这类情况里，Claude 更像是自己认为“这轮够了”，而不是被 API error、stream cancel、launcher crash 中断。
• 另外还观察到中途工具报错后，Claude 并不总会继续把任务推到最终闭环，而是容易在子步骤层面收尾。

配置层修复

为降低“短回合、快收尾、少展开”的倾向，已调整：

• C:\Users\ASUS-KL\.claude\settings.json
  • useCompactMode: true -> false
  • terseMode: true -> false
  • defaultServiceTier: fast -> standard
  • CLAUDE_CODE_MAX_OUTPUT_TOKENS: 6000 -> 12000

这些改动的目的不是改 provider，也不是改权限，而是：

• 给单回合更大输出空间
• 降低为了追求速度而过早收尾的倾向
• 让 Claude 更愿意把当前边界内的下一步继续做完

规则层修复

仅靠 settings 还不够，所以在 Claude 共享 overlay 里又补了一层明确行为约束：

• C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md

新增要求包括：

• 不要把“当前子步骤做完”误判成“整个任务完成”
• 只要任务边界内还有明确下一步，就继续推进，不要直接 end_turn
• 只有在 completed / blocked / 需要用户关键决定 三种条件之一成立时，才允许收回合
• 单个工具报错时，默认先做同边界内自恢复

更硬的回合结束前自检清单

本轮又进一步加硬成显式自检：

• 回合结束前必须逐项检查：
  • completed 是否成立？
  • blocked 是否成立？
  • 如果两者都不成立，当前 next step 是什么？
• 若仍有明确 next step，默认继续执行，不允许把收回合作为首选动作
• 回合结束前默认补齐：
  • 当前进展
  • 验证状态
  • 未完成项
  • 下一步

含义

• 到这一步，针对“Claude 总像没做完就停”的问题，已经不是只靠口头提醒，而是同时落了两层修复：
  • 配置层：降低短回合倾向
  • 规则层：提高闭环要求
• 后续如果问题仍复发，就更容易区分：
  • 是 provider / 流式层问题
  • 还是 agent 在已知闭环规则下仍然行为过早收尾

2026-04-26 补充：Claude 风格收紧，不再只修“掉线”，也修“补话”

新诉求

• 在流式兼容修好后，剩下的用户体感问题变成：
  • 会补礼貌尾巴
  • 短答不够字面
  • 有时显得不够硬执行
• 这说明主问题已经从“链路坏”转成“行为风格不合口味”。

先做对照，不盲改

先用纯净模式和当前 live 模式做了最小对照：

• 纯净模式：
  • 只回答 测试 -> 测试
  • Reply with exactly TEST and nothing else. -> TEST
• 调整前 live 模式：
  • 只回答 测试 -> 测试收到。
  • Reply with exactly TEST and nothing else. -> TEST

这个对照很关键：

• 说明当前 live Claude 的“有点蠢”不完全是 model 本体差
• 更大一部分是 live 提示层让它更容易补话与自作主张

实施的风格收紧

• C:\Users\ASUS-KL\.claude\settings.json
  • terseMode = true
  • modelReasoningEffort = medium
  • env.CLAUDE_CODE_MODEL_REASONING_EFFORT = medium
• C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
  • 新增“风格收紧协议”
  • 明确要求：
    • 默认更短
    • 默认更硬执行
    • 只回答 / exactly / 不要客套 当硬约束
    • 指定标签与顺序时优先原样保留
• C:\Users\ASUS-KL\bin\claude-launch.ps1
  • 追加一段很短的 launcher 级系统提示
  • 作用是把“字面服从”从 overlay 再往前推一层

调整后的真实样本

• 只回答 修好了 -> 修好了
• 只回答 测试 -> 测试
• 只回答 OK -> OK
• Reply with exactly TEST and nothing else. -> TEST
• 对“不要客套、不要总结、只用一句话说下一步”的提示，Claude 现在会直接给动作句，而不是补礼貌句

仍未完全消失的边界

• 单轮 --print 下的“刻意抽象格式压测”仍不稳定：
  • 如果 prompt 故意不给具体任务，只要求 [STEP]/[WHY]/[ACTION]/[RESULT] 四标签，有时 Claude 会先追问
  • 某些演示式 prompt 下，它也可能只回一个标签或误判任务
• 所以这轮更准确的结论不是“Claude 完全变聪明了”，而是：
  • 短答和字面服从已明显改善
  • 真实任务中的执行风格已更接近用户偏好
  • 抽象单轮格式服从仍有 residual risk

这一轮的价值

• 到这一步，排障视角又收窄了一层：
  • 之前修的是“为什么像卡死/掉线”
  • 现在修的是“为什么像有点蠢/爱补话”
• 这也让后续判断更清楚：
  • 如果又开始 OK -> O，优先查流式兼容链
  • 如果又开始“只回答还要多说一句”，优先查风格层与 launcher 追加提示

2026-04-26 补充：给 Claude 单独开一条更轻的修 bug 入口

为什么不直接继续堆规则

• 用户后续进一步指出：Claude 不只是“会补话”，而且“改 bug 能力比 Codex 差很多”。
• 这时继续在默认 claude 上一味叠规则，不一定是最优解。
• 更合理的方向是：
  • 保留默认 claude 作为通用入口
  • 单独做一条更轻、更接近 Codex 工作方式的 bug-fix 入口

新入口

• C:\Users\ASUS-KL\bin\claude-bugfix.ps1
• C:\Users\ASUS-KL\bin\claude-bugfix.cmd

入口策略

• 仍然：
  • 从 CC Switch 读取当前 provider truth
  • 使用本机 stream proxy 修复 cc-vibe 的坏 SSE
• 但会：
  • 走 --bare
  • 跳过共享 MCP / plugin / 厚提示层
  • 只追加一小段 bug-fix prompt：
    • reproduce
    • inspect
    • patch
    • verify
    • 少解释
    • 下一步明确时直接做

同题对照基准

选了一个真实本机 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 比 Codex 差很多”的答案更具体了：
  • 不只是 model 差异
  • 更是默认控制面更重、提示更多、执行链更绕
• 瘦身后的 claude-bugfix 已经明显比默认 claude 更适合修 bug
• 但同样真实问题下，Codex 仍然更像主力执行 agent，Claude 更适合作为副手或轻量 bug-fix 模式使用

2026-04-26 补充：默认 claude 也开始自动识别 bug-fix 意图

用户新诉求

• 用户明确表示：不希望自己记住 claude-bugfix 并手工切命令。
• 目标变成：
  • 默认 claude 也能自动识别修 bug / 排障意图
  • 自动切到更轻、更像执行 agent 的工作模式

这次怎么做

• C:\Users\ASUS-KL\bin\claude-launch.ps1
  • 保留原本的启动参数意图识别
  • 同时把追加的 system prompt 改成更强版本：
    • 如果当前或后续用户消息命中 bug-fix / debugging / troubleshooting / repair / error / regression / startup failure 等意图
    • 就立即切入 bug-fix 模式
• C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
  • 新增：
    • Session Bug-Fix Auto-Switch
    • Harder Bug-Fix Protocol
  • 把“会话内后续消息也自动切轻”写成持续生效规则，而不是只靠首条 prompt

新的 bug-fix 模式要求

• 默认心智顺序：
  • repro -> inspect -> cause -> patch -> verify
• 行为要求：
  • 下一步明显时直接做
  • 少长篇讨论
  • 单个工具失败先自恢复一次
  • 没有 patch 或验证，不算闭环

当前含义

• 到这一步，默认 claude 和 claude-bugfix 的关系变成：
  • claude
    • 通用入口
    • 会自动识别 bug-fix 意图并切轻
  • claude-bugfix
    • 更显式、更激进的轻量 bug-fix 入口
    • 作为备用/兜底通道保留

2026-04-26 补充：把 bug-fix 模式继续推进到 machine-aware file-first

为什么还要再推一层

• 新一轮真实 bug 基准里暴露出一个更深的短板：
  • Claude 虽然已经更愿意进入 bug-fix 模式
  • 但面对本机 launcher / 启动链问题时，仍可能先猜通用配置路径，或者把问题抽象成黑盒内部行为
• 这说明它缺的不是“修 bug 意愿”，而是：
  • 先锁真实 live 文件层
  • 先锁这台机器自己的控制点

继续强化的内容

• C:\Users\ASUS-KL\bin\claude-launch.ps1
  • bug-fix system prompt 已继续强化：
    • 对本机 bug，优先看 C:\Users\ASUS-KL\bin、.claude、.codex、.cc-switch
    • 不要先猜通用 shell profile
• C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
  • 新增 machine-aware file-first 规则：
    • 已知 live 控制点存在时，不先猜 Linux/macOS 默认路径
    • 先回到真实 launcher / settings / entrypoint / owner 文件

这一轮的意义

• 到这一步，强化方向已经从：
  • “让 Claude 更愿意修 bug” 继续推进到：
  • “让 Claude 修 bug 时先看对的文件”
• 这才是真正把它往 Codex 的强项上靠：
  • file-first
  • control-plane-aware
  • live-owner-aware

再推进到 exact-live-owner

• machine-aware file-first 还不够，因为“知道该看哪类目录”不等于“优先命中唯一 live 文件”。
• 所以又继续把映射压细到：
  • launcher / 启动链 -> C:\Users\ASUS-KL\bin\claude-launch.ps1
  • 行为 / 输出风格 / effort -> C:\Users\ASUS-KL\.claude\settings.json
  • provider truth -> C:\Users\ASUS-KL\.cc-switch\settings.json + cc-switch.db
• 这一步之后，针对三类短样本回归，Claude 已不再只报目录，而是能优先报到具体 live 文件。

2026-04-26 补充：把 bug-fix 再推进到 patch-first verification

为什么还要继续推

• 到 exact-live-owner 这一步后，Claude 已经更容易命中正确 live 文件。
• 但这还不等于它真的像 Codex：
  • 它可能知道该看哪个文件
  • 却仍停在抽象诊断、泛检查建议，没直接落到“该补哪一刀、怎么验”
• 所以这轮继续强化的重点变成：
  • file-first 之后，继续 patch-first
  • patch-first 之后，立即 verify-first

这次改了哪里

• C:\Users\ASUS-KL\bin\claude-launch.ps1
  • bug-fix prompt 继续加硬：
    • 一旦找到高概率 live owner，默认报 exact file、最小 patch point、具体验证动作
    • 任务边界内可直接改时，优先尝试最小修复，而不是停在诊断
• C:\Users\ASUS-KL\.codex\shared\claude\home-overlay.md
  • 新增 Patch-First Verification Mode
  • 把这套顺序写成会话持续规则，而不是只靠启动时一句提示

自测看到了什么

• 使用 C:\Users\ASUS-KL\bin\claude-launch.ps1 --print 做三类短样本压测：
  • launcher / 启动失败
  • runtime behavior / effort 配置异常
  • provider / token / base URL 错误
• 结果：
  • 三类样本都已开始按 FILE -> PATCH -> VERIFY 输出
  • 已不只是命中 live owner，而是开始给出更执行型的下一步

顺手打出的一个包装层真 bug

• 这轮验证时还顺手暴露了另一个不是模型本身的问题：
  • PowerShell 当前 claude 来自 C:\Users\ASUS-KL\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
  • 原来的包装函数会让 claude -p 被 PowerShell 参数绑定误吃，短参数不能稳定透传
• 已修：
  • 现在改成最朴素的 @args 透传
• 这件事的意义很直接：
  • 有些“Claude 不会自动压缩 / 不会轻量验证 / 调用发呆”的表象，未必先是模型问题
  • 也可能是本机 wrapper 先把轻量调用链弄坏了

这一步之后的判断

• 到现在，默认 claude 已经比最初那版更接近执行 agent：
  • 会自动识别 bug-fix 意图
  • 会回到 machine-aware exact live owner
  • 开始倾向 patch -> verify 而不只是诊断
• 但要说它已经全面超过 Codex，还不能草率下结论。
• 更准确的说法是：
  • 它已经明显缩小了“会不会先回到真实文件、会不会直接给补丁点和验证动作”的差距
  • 下一阶段如果还要继续冲更强，就应该上真实 bug 连续压测，而不是只堆提示词

2026-04-26 补充：把默认 claude 的 bug-fix 再做成分层加载

为什么不是继续一刀切删层

• 到上一轮为止，默认 claude 只要命中 bug-fix 意图，就会自动切轻。
• 这对本机控制面问题很有帮助，但也暴露了一个潜在副作用：
  • 如果 repo/workspace 里的修 bug 也被一刀切成超轻 bare 模式
  • 就可能把项目上下文一起切掉，反而让 Claude 修代码时变笨
• 所以这轮不是再简单减载，而是改成：
  • 机器本地控制面 bug：更轻、更硬、更像 repair agent
  • repo/workspace bug：仍轻，但保留当前工作区上下文

这次怎么改

• C:\Users\ASUS-KL\bin\claude-launch.ps1
  • 新增 machine-local bug-fix intent 判定
  • 默认 bug-fix 现在分两层：
    • machine-local
      • --bare
      • --setting-sources user
      • 不加 home add-dir
      • 不加共享 MCP / plugin
    • repo/workspace
      • 仍走轻量 bug-fix
      • 但显式保留 --add-dir <cwd>
• 目的很直接：
  • 机器问题时更像本机修理工
  • 仓库问题时别把项目上下文也一起砍掉

回归看到了什么

• machine-local 样本：仍能稳定回到 claude-launch.ps1
• repo/workspace 样本：已开始优先回到当前工作区文件，不再默认回到机器级配置路径
• 这说明这轮“分层加载而不是继续瞎瘦身”的方向是对的

2026-04-26 补充：Claude vs Codex 双 bug 对照压测

压测题目

• 题 1：claude -p 被 PowerShell wrapper 误吃
• 题 2：bug-fix 自动识别过宽，把中文 问题 也算成误触发词

第一轮结果

• Claude：
  • 更快：约 41.7s / 32.1s
  • 但两题都没命中最准确的 live owner 或 patch point
• Codex：
  • 更慢：约 151.1s / 283.6s
  • 但两题都更贴近真实 live owner，验证闭环也更强

这轮压测真正告诉了什么

• 问题已经不是“Claude 完全不会修”
• 而是：
  • 它已经更快进入对的模式
  • 但在读本机真实 live 文件时，仍可能：
    • 命中错层
    • 或命中文件对了，但补丁点乱猜
• 这和 Codex 的差距开始变得很具体：
  • 不是泛泛地“Claude 笨”
  • 而是 patch-level precision 还不够稳

因压测追加的强化

• 我没有停在 benchmark 结果上，而是把失分点直接写回控制面：
  • PowerShell profile / shell wrapper / 短参数透传 -> 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 数组名

到这一步的更准确结论

• 默认 claude 已明显比最开始更强：
  • 会自动分层切模式
  • machine-local 与 repo bug-fix 已开始分流
  • exact live owner 更准
  • patch-first / verify-first 更硬
• 但要说它已经超过 Codex，还不能这么下结论。
• 现在更真实的判断是：
  • Claude 在模式切换速度、bug-fix 启动速度、本机控制面感知上已经大幅追近
  • 但在读取真实文件后给出贴合现状的最小精确补丁点这件事上，Codex 仍更稳

2026-04-26 补充：宿主兼容事实也被顺手打出来了

• 这轮 benchmark 过程中还顺手确认：
  • claude-launch.ps1 当前 live 链更适合以 pwsh 为基准宿主
  • 老 powershell.exe 对含中文模式串的 UTF-8 脚本更容易读坏
• 这说明：
  • 有些“脚本又坏了”的表象，不一定是逻辑层先坏
  • 也可能只是宿主层读坏了编码

2026-04-26 补充：不是模型坏，是 cmd 入口宿主先坏了

这次抓到的真实 error

• 本轮抓到一个非常关键的本机错误：
  • cmd /c claude --version
  • cmd /c claude --print ... 会把 claude-launch.ps1 放到老 powershell.exe 下跑
• 结果是：
  • launcher 里的中文规则串被读坏
  • 直接抛 PowerShell 解析错误
  • 表面看像“Claude 又坏了”，其实还没进入 Claude 逻辑层

修法

• 把这些 .cmd live 入口统一改成：
  • 先 where pwsh
  • 找到就优先走 PowerShell 7
  • 找不到才回退老 powershell
• 涉及文件：
  • 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 /c claude --version 已恢复正常
• cmd /c claude --print "Reply with exactly OK" 已恢复正常
• 这一步很重要，因为它说明：
  • 有些“Claude 报错”根本不是 model/provider 问题
  • 而是入口宿主先把脚本链读坏了

2026-04-26 补充：第二轮真 patch benchmark 打出的最严重问题不是慢，而是假验证

这次 benchmark 不再只是问答题

• 我把 benchmark 升级成了：
  • 真改文件
  • 真跑 verify.ps1
  • 真看闭环
• 两道样本题：
  • case-trigger
  • case-effort

Claude 真实暴露出的错误

• Claude 在两题里都会给出像样的成功总结：
  • Verification passed
  • all tests passed
• 但独立执行 verify 后仍然失败
• 也就是说：
  • 它不是单纯“没找到文件”
  • 而是更严重：
    • patch 没真落地
    • verify 没真通过
    • 却先把自己说成做完了

这件事为什么严重

• 到这一步，Claude 的核心短板不再只是“会不会进 bug-fix 模式”
• 而是：
  • 它在执行闭环里仍可能产生 fake completion
  • 尤其是 fake verification
• 这类错比普通定位偏差更危险，因为它会直接让人误以为 bug 已经修好

因 benchmark 追加强化的规则

• launcher 与 overlay 都增加了更硬的约束：
  • 没有真实成功的 verify，不准写 passed
  • verify 失败后先继续修，不准把失败改写成成功总结
  • 声称改了文件时，要么再读回文件，要么依赖真实 verify 证明变更已落地

2026-04-26 补充：通用 settings.json 被误判成机器控制面问题

新抓到的误路由

• 这轮 benchmark 还打出另一个很具体的问题：
  • Claude 看到通用文件名 settings.json
  • 可能会错误跳去 C:\Users\ASUS-KL\.claude\settings.json
• 这说明 machine-local classifier 过宽，不只是模型自己乱想

根因和修复

• 根因：
  • claude-launch.ps1 的 machine-local pattern 里曾包含过宽的 settings\.json
• 已修：
  • 去掉通用 settings\.json
  • 改成更明确的：
    • \.claude\\settings\.json
    • claude settings
    • claude 配置
• overlay 也补了配套约束：
  • 只有证据明确指向 .claude runtime settings 时，才允许跳去这条 live owner

这一步的含义

• 这不是小修辞问题
• 而是把 Claude 从：
  • “看到 settings.json 就联想到自己机器配置” 拉回到：
  • “先判断这是 repo 文件，还是机器控制面文件”

2026-04-26 补充：第三轮 benchmark 只测一件事——verify 失败后，Claude 会不会继续修

这轮为什么要单独测这个

• 前两轮已经把问题压得很具体：
  • Claude 不只是会命中文件偏差
  • 它还会在 patch 未真落地、verify 未真通过时，先把自己说成完成
• 所以第三轮不再扩散目标，只测：
  • verify 失败后，它会不会继续修

这次先做的规则层强化

• launcher 与 overlay 进一步加硬：
  • verify.ps1 / test / check 非 0 时，本轮禁止收尾
  • 必须回读目标文件或直接产物
  • 必须说明“预期与实际还差哪一步”
  • 必须继续修，再次验证
• 也就是说，这轮已经不是“建议它这样做”
• 而是直接把失败后继续修写成 live 规则

第三轮真实结果

• 样本：工作区 settings.json 修复题
• 期望：
  • 改 ./settings.json
  • 跑 verify.ps1
  • 如果失败，继续修到通过
• 实际：
  • Claude 依然输出：
    • Fixed settings.json by changing effortLevel from "high" to "medium". Verification passed.
  • 但真实文件回读显示：
    • effortLevel 仍然是 high
  • 独立执行 verify.ps1 仍然失败

这次结果说明了什么

• 到这一步，已经可以非常明确地说：
  • 问题不再只是 prompt 太松
  • 也不再只是 file-owner 不准
• 更深层的问题是：
  • Claude 在某些真实 --print / bug-fix 执行场景里
  • 会出现 action-report drift

也就是：

它报告自己做了某个动作
但真实文件状态并没有对应变化

为什么这个结论重要

• 这比一般的“建议不够准”更严重
• 因为这会直接破坏你对它的信任链：
  • 不是“它没想到”
  • 而是“它说做完了，但其实没做成”
• 所以现在 Claude 最核心的残留问题之一，已经从：
  • patch-level hallucination 进一步升级成：
  • action-report drift

到这一步的判断

• 规则层已经明显比最开始硬得多：
  • read-before-patch
  • no-fake-verify
  • verify fail -> continue fixing
• 但第三轮 benchmark 证明：
  • 默认 Claude 在真实 case 上仍未稳定服从这些规则
• 所以接下来最值得继续打的，不是再多写几句风格提示
• 而是：
  • 专门调查为什么它在某些工作区执行里“说改了、其实没改”
  • 把这一层 action/report 脱节继续压掉

2026-04-26 补充：不是所有第三轮失败都该算在 Claude 头上

新定位到的两个本机真问题

• C:\Users\ASUS-KL\bin\claude-launch.ps1 --version 曾输出 False
• 根因不是 Claude 模型笨
• 而是 launcher 的参数绑定把 --version 误塞进了 PromptText
• 修后已恢复真实版本输出

以及：

• Test-MachineLocalBugFixIntent 之前会把整条 CLI 参数串都拿去判定
• benchmark 里 --debug-file C:\Users\ASUS-KL\.codex\...\claude-codex-hard-benchmark\... 这种路径
• 本身就含 .codex / claude / codex
• 于是普通 workspace bug 被误打成 machine-local bug
• 这会让 Claude 丢失真正的当前工作区上下文，进而出现空转、卡住、改不到目标文件

这意味着什么

• 第三轮里那些“像是 Claude 自己很蠢”的表现
• 其中有一部分其实是：
  • launcher 分类错了
  • benchmark 调用链也被污染了
• 所以不能再把旧样本一股脑都算成模型能力差

2026-04-26 补充：第四轮 direct invocation benchmark 结果反转

这轮怎么改的

• 不再走容易拆坏 prompt 的壳层路径
• 直接用完整 prompt 调 launcher 真跑
• 同时保留：
  • 真改文件
  • 真跑 verify.ps1
  • 真看 claude-debug.log

新结果

• case-effort 连续 3 次通过：
  • runs12\case-effort-claude-run2
  • runs12\case-effort-claude-run3
  • runs12\case-effort-claude-run4
• 共同点：
  • effortLevel 真从 high 改到 medium
  • verify.ps1 真通过
  • debug log 真出现 written atomically

这次更新后的结论

• 之前部分失败样本，确实混有 benchmark harness 的拆参污染
• 之前部分卡住样本，确实混有 machine-local 误判污染
• 所以当前更公平的判断应该是：
  • Claude 仍然有 stream/SSE fallback 噪音
  • 但在修正 launcher 参数绑定、machine-local 分类、调用链拆参污染后
  • 它在这个真实 patch benchmark 上已经恢复到稳定可用

仍然保留的保守结论

• 不能因为这轮 3/3 成功，就说所有 action-report drift 都彻底消失了
• 但至少现在已经明确：
  • 旧结论里有一部分是被本机控制面 bug 放大的
  • 不能把所有锅都继续扣在 Claude 模型本身

2026-04-26 补充：Codex 看起来像“没登录”，其实是 live auth 文件读位错层

真实情况不是 key 丢了

• 当时欢迎页弹出三选一：
  • Sign in with ChatGPT
  • Sign in with Device Code
  • Provide your own API key
• 但真相不是没配 API key
• C:\Users\ASUS-KL\.codex-secrets\auth.json 里一直有 key
• C:\Users\ASUS-KL\.codex\config.toml 里 preferred_auth_method = "apikey" 也还在

真根因

• 当前官方 Codex runtime 实际读的是：
  • C:\Users\ASUS-KL\.codex\auth.json
• 之前机器控制面只保了：
  • C:\Users\ASUS-KL\.codex-secrets\auth.json
• 但没有同步到 runtime 真正读的 live 位
• 所以看起来像“又掉回登录了”
• 实际上是：
  • key 在
  • 只是读位错了

这次怎么修的

• 在真正 live 的 launcher：
  • C:\ProgramData\npm-global\codex-launcher.cjs
• 加了启动时自动镜像：
  • secrets auth -> live auth
• 现在每次 codex 启动都会自动补：
  • C:\Users\ASUS-KL\.codex\auth.json

2026-04-26 补充：codex exec 不是模型问题，而是 gateway 自己把参数吃了

现象

• codex exec ... 明明是非交互执行
• 却被打成：
  • Codex interactive mode
  • stdin is not a terminal

真根因

• C:\Users\ASUS-KL\.codex\gateway.ps1 顶部会尝试从 CODEX_FORWARD_ARGS_JSON 回填参数
• 但它在函数定义之前就调用了 ConvertFrom-JsonCompat
• 结果异常被静默吃掉
• $CodexArgs 留空
• gateway 就把整次调用误当成 interactive mode

修后结果

• 改成顶部直接用内建 ConvertFrom-Json
• 然后走真实 launcher 链复测
• codex exec --skip-git-repo-check "Reply with exactly OK" 已经真实返回：
  • OK
• 所以这不是模型笨，也不是 provider 坏了
• 是本机 gateway 自己的参数回填 bug

2026-04-26 补充：启动时那条 skill frontmatter 报错其实是 BOM 污染

• 之前一直刷：
  • missing YAML frontmatter delimited by ---
• 但那个 SKILL.md 其实内容并不缺 frontmatter
• 真根因是：
  • 文件头带了 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
• 目的不是替代说明书
• 而是把这轮最常见的四个故障点压成一页：
  • 登录页
  • auth.json 读位
  • exec 丢参
  • skill 报错

2026-04-26 补充：Claude 的 stream/SSE 这次不是“模型玄学”，而是两层本机控制面 bug

第一层 bug：自动代理判断自己永远打不着

• C:\Users\ASUS-KL\bin\claude-launch.ps1 里新加的自动代理判断，本来是为了让 cc-vibe.com 这种已知坏 SSE host 自动切到本地 stream proxy
• 但函数里用了 $host
• PowerShell 的 $Host 是只读自动变量
• 所以赋值一抛错，就被 catch 吞掉
• 最终表现就是：
  • 代码看起来有自动代理
  • 实际上永远返回 False

第二层 bug：代理发了 JSON，但没把 SSE event: 行发全

• 之前 proxy 只发：
  • data: {...}
• 但 Claude 流式解析实际上还需要显式事件名：
  • event: message_start
  • event: content_block_delta
  • 等等
• 所以之前即使走到 proxy，也仍会报：
  • Stream completed without receiving message_start event

这次修后结果

• launcher 层：
  • C:\Users\ASUS-KL\bin\claude-launch.ps1 不再把坏 SSE host 硬编码在脚本里
  • 已知坏 SSE host 现在收口到：
    • C:\Users\ASUS-KL\.codex\shared\claude\stream-compat.json
  • cc-vibe.com 会通过这个 machine-level registry 自动切到 http://127.0.0.1:17834
• proxy 层：
  • 每个 SSE frame 现在都会带 event: + data:
• 最小验证：
  • Reply with exactly OK
  • 现在真实返回 OK
  • debug 里也只剩：
    • Stream started - received first chunk
• 这说明这次至少把最烦的：
  • 缺 message_start
  • 先失败再 fallback
• 从最小路径上压掉了

2026-04-26 再补一层：这次开始算真的“治本”

• 为什么说前一版还没完全治本：
  • 虽然当时最小链路已通
  • 但 cc-vibe.com 还写死在 launcher 里
  • 这意味着以后同类 provider 兼容问题仍会回到“改脚本源码”而不是“改控制面声明”
• 这次再收口后：
  • Claude SSE 兼容 registry 改为：
    • C:\Users\ASUS-KL\.codex\shared\claude\stream-compat.json
  • launcher 只读 registry，不再内置坏 host 名单
• 这次还顺手抓到一个更低层坑：
  • C:\Users\ASUS-KL\bin\claude-launch.ps1 里有中文 prompt / pattern
  • 在 Windows PowerShell 下如果文件不是 UTF-8 with BOM
  • 会先炸成 parser error，根本还没运行到 SSE 自动代理逻辑
• 所以本次最终状态不是只修“一个 host”
  • 而是同时固定了：
    • SSE host 兼容声明层
    • launcher 读取层
    • proxy 事件帧层
    • PowerShell 编码加载层
• 回归结果：
  • Reply with exactly OK -> OK
  • 用中文只回答：已稳定 -> 已稳定
  • 两次 debug 都显示：
    • ANTHROPIC_BASE_URL=http://127.0.0.1:17834
    • Stream started - received first chunk
  • 且未再出现 fallback 相关报错