ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

opencodex 的 Claude Code 入站加固实战:思考签名往返、错误分类对齐与发布门控(Phase 4)

opencodex 的 Claude Code 入站加固实战:思考签名往返、错误分类对齐与发布门控(Phase 4) 【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载/v1/messages入站通道让 Claude Code 与 Codex 共享同一套 provider 栈OAuth 池、路由、密钥故障转移、视觉/联网 sidecar而本篇所基于的 040_phase4_hardening.md 正是该系列的收尾加固与发布阶段关闭前三个 Phase 遗留的协议保真差距、为入站流量打上可观测性标签、弃用历史代理 ccs-wrapper 并完成一次带文档/变更日志的发布。读完本文你将掌握 opencodex 在 Claude Code 入向上如何处理思考块签名往返、如何把上游错误映射为 Anthropic 错误分类法、如何验证取消/心跳/非流式等协议边界以及整个加固周期的测试门控与发布纪律。一、Phase 4 在整个 Claude Code inbound 单元中的定位本系列见 000_plan.md按四个 PABCD 周期推进每个周期一份 P 文档Phase主题工作类Phase 1核心入站/v1/messagescount_tokens010_phase1_core_inbound.mdC3Phase 2ocx claude启动器 网关模型发现/别名C2-C3Phase 3GUI Claude Code 区块 docs-site/README多语言C2Phase 4加固思考回放、错误对齐、协议边界、可观测性 ccs-wrapper 弃用 发布C3-C4Phase 4 的 Objective 一句话概括关闭 Phase 1-3 延期的保真缺口把新暴露面在可观测性中打标签弃用 ccs-wrapper并携带文档/变更日志发布一个版本。它的五个 Workstream 分别是思考往返策略、错误形状对齐、协议边界、可观测性与文档真实性、弃用与发布——本文按此骨架展开。二、Workstream 1思考thinking往返策略与 ocxr1 签名信封2.1 问题背景Phase 1 落地后思考thinking流被无签名地转发给 Claude Code当 Claude Code 把上一轮的thinking/redacted_thinking块回放给入站时这些块被直接丢弃。这在多数路由场景下是可接受的Claude Code 客户端本身不做签名密码学校验但对 Anthropic 系anthropic-family路由 provider 而言带签名的思考回放是硬性协议要求Anthropic 要求上一轮助手消息的 thinking/redacted_thinking 块必须带原签名逐字回放否则会收到400 Expected thinking or redacted_thinking, but found tool_use。2.2 复用 ocxr1 reasoning-envelope 机制040 给出的加固方向是当 ROUTED provider 属于 anthropic-family 时复用现有 reasoning-envelope.ts 的ocxr1信封机制与 bridge 签名捕获能力让带签名的思考以与 Codex 回放相同的方式存活于 Claude Code 回放。ocxr1信封的核心设计源码级证据前缀常量OCX_REASONING_PREFIX ocxr1:reasoning-envelope.ts信封体为ocxr1: base64(JSON)JSON 内可携带四个字段ReasoningEnvelope 定义sigAnthropic 思考块签名signature_delta捕获值red原始redacted_thinking块数据负载保序txt被隐藏的思考文本——签名签署的就是这段原文即使可见摘要被抑制回放仍需要它krcKiro 系模型的 KMS 加密推理 blobreasoningContentEvent对代理不透明但与签名一样需跨轮往返encodeReasoningEnvelopeL41与decodeReasoningEnvelopeL97都在 TranslatorBudget 预算约束下工作防止不可信的 base64 载荷造成内存膨胀解码器对非ocxr1:前缀的 OpenAI 原生加密 blob 原样放行。2.3 决策门demonstrate-or-document拒绝投机建设040 明确规定了一个决策门只有当真实故障被演示工具调用回合在回放时出现 400才构建 Anthropic-family 签名回放否则就把回放思考丢弃记录为预期行为intended policy。这是整个 Workstream 1 的风险控制核心——签名回放可能膨胀必须时间盒化。从 050_close.md 的处置记录看最终落地的是 v1 策略出站为 thinking 块先发thinking_delta再在content_block_stop前发一个合成signature_deltaCCR 先例E6 证据Claude Code 接受合成签名、不做客户端密码学校验入站回放的 thinking/redacted_thinking 块仍被丢弃Anthropic-family 签名回放未构建——040 的决策门保持成立。不过入站翻译器已经预埋了 ocxr1 的处理路径在 inbound.ts 的thinking块翻译中若收到的 signature 以ocxr1:开头会先尝试decodeReasoningEnvelope解码——解码失败抛AnthropicRequestError(malformed ocxr1 reasoning signature)若信封内携带了sig即试图把 OpenCodex 的推理连续性伪装成 Anthropic 签名则直接拒绝防止跨协议的签名伪造普通非信封签名则会被重新包进{sig}信封随推理项继续跨轮往返。出站侧在 outbound.ts 的思考块闭合逻辑中优先使用捕获到的真实签名否则退化为ocxr1:{txt}兜底信封。三、Workstream 2错误形状对齐error-shape parity3.1 Anthropic 错误分类表040 要求把上游/OpenAI 错误类型映射为 Anthropic 错误分类法invalid_request_error、authentication_error、permission_error、not_found_error、rate_limit_error、api_error、overloaded_error并在 429/529 上保留Retry-After表驱动、按状态逐一测试。该工作在实际实现中被提前到 Phase 1010 修正第 4 条并在 outbound.ts 的anthropicErrorType(status)中落地为完整官方表HTTP 状态Anthropic 错误类型400invalid_request_error401authentication_error402billing_error403permission_error404not_found_error409conflict_error413request_too_large429rate_limit_error504timeout_error529overloaded_error其余 5xx / 其余 4xxapi_error/invalid_request_erroranthropicErrorBody(status, message, type?, code?)统一产出{type:error, error:{type, message, code?}}形状L73-L75anthropicErrorResponse将其包装为标准 JSON ResponseL77-L82。3.2 瞬时 5xx 重分类为 529 overloaded_error这是最容易踩坑的一处Anthropic SDK 客户端对api_error5xx 兜底会直接判定致命错误而对overloaded_error529会启用内置退避重试。因此 outbound 状态机L397-L435对上游派生的瞬时状态isTransientUpstreamStatus判定见 upstream-retry.ts强制映射为overloaded_error而代理内部异常保持api_error——确定性 bug 不能被伪装成可重试错误。同样的原则贯穿整个入站错误链路claude-messages.ts非 2xx 响应先解析上游 body 文本提取真实 message再重塑为 Anthropic 信封Retry-After解析链上游头 →resolveClientRetryAfter→ 兜底2瞬时 5xx 或可重试 429 且上游未带头时瞬时 5xx 出站状态改写为529请求日志保留上游真实状态码日志上游真相客户端重试信号显式Retry-After: 0会被保留合法的即时重试指令优于兜底2。对应测试见 claude-529-mapping.test.ts且 050 处置表确认错误分类法 retry-after 透传 Anthropic 形状的 auth/origin 拒绝全部在 WP2 交付。3.3 auth/origin 拒绝也使用 Anthropic 形状requireApiAuth/origin 拒绝在/v1/messages*路由上从第一天起就复用这套错误信封010 修正第 4 条。一个具体例子claudeCode.enabled: false时返回403 permission_errorclaude-messages.tsDesktop 模型映射不可用返回503 api_error带Retry-After: 1L122-L126。四、Workstream 3协议边界protocol edges4.1anthropic-beta头与?betatrue忽略安全Claude Code 会向POST /v1/messages?betatrue发请求并携带anthropic-betaCSV 值与anthropic-version当前2023-06-01头。040 要求确认这些可安全忽略路由按url.pathname匹配查询串被忽略证据 G9anthropic-version与anthropic-beta按原样转发/接受beta 值视为开放列表G12未知 beta 请求仅在首次出现时记录一次。x-api-key准入与 CORS allow-headers 中也加入了X-Api-Key, Anthropic-Version, Anthropic-Beta010 修正第 9 条。4.2count_tokens保真估计值 vs provider 报告值入站count_tokens走字符估计路径estimateTokens 基于charsPerToken(modelId)按模型分档的字符/Token 比率。040 要求对比估计值与 provider 报告的input_tokens若漂移 2x 则调整charsPerToken选择。实际实现已对最大的失真源做了修正estimateClaudeRequestTokens 对协议内容位置消息 content 块、tool_result.content嵌套块中的 base64 附件image/document按有界逐附件估算——能嗅探图片尺寸时按max(256, ceil(w*h/750))Anthropic 图片计价约 pixels/750否则按解码字节数/512下限 256。原因写在注释里一张 2MB 截图约 270 万 base64 字符若按纯字符/Token 比率计算会虚报成几十万 Token真实成本约 1.6k直接击穿 2x 漂移上界。tool_use.input与工具 schema 中的 attachment 形状 JSON 不在此列——那些字节会被序列化进 function_call 参数/工具定义发给路由 provider必须继续按文本计数。4.3 取消传播客户端断开 → 上游中止040 要求客户端断开必须通过 SSE 变换传播为内部请求中止并验证中途杀流不泄漏上游连接。实现证据入站以abortSignal: req.signal传入handleResponsesclaude-messages.tsoutbound SSE 变换器的cancel(reason)钩子outbound.ts置cancelled true、释放所有 retained 预算与 thinking 缓冲、清理 ping 定时器并向上游reader.cancel(reason)传播。050 处置记录确认取消通过abortSignal: req.signal streamcancel()传播已交付。4.4 Stall 行为心跳 → ping维持 Claude Code 的空闲计时器桥接心跳转换为 Anthropicping事件防止 Claude Code 的空闲超时误杀长思考回合。具体机制outbound 变换器内置pingIntervalMs默认 20000outbound.ts定时发射 transport-onlyping语义帧message_start → content_block_* → message_delta → message_stop中允许ping出现在任意位置包括 message_start 之前——证据 G 系列已钉死这一契约response.heartbeat帧直接转发为pingL451-L452。040 的验证手段是人工 60s stall fixture在 60 秒无输出的上游上确认 ping 持续、Claude Code 不判定空闲超时。4.5 非流式原生透传边界决策与实现040 提出问题claude inbound → 原生 gpt 模型、stream:false的边缘——支持还是显式 400 带指引最终决策是支持050non-stream native passthrough JSON fallback — all shipped。实现分两层路由 providerrouted adapters 不支持非流式内部回合因此内部回放总是stream:true非流式客户端通过collectAnthropicMessage把翻译后的 Anthropic SSE 折叠为 message JSONoutbound.ts语义帧聚合、error 帧权威优先、tool 参数 JSON 拼接后解析原生 Anthropic 透传当 Claude Code 以订阅模式只设ANTHROPIC_BASE_URL、携带真实 claude.ai OAuth Bearer且请求的是无别名/无 modelMap 认领的真 claude/anthropic 模型时请求逐字转发到 api.anthropic.comclaude-messages.tsbeta/思考签名/计费身份保持原生。另外注意 EOF 边界上游在 terminal 帧前关闭流被判定为截断而非成功变换器以502overloaded_error的 Anthropic 错误帧 fail-closedL830-L834让客户端可以重试——这正是 040 要求的协议正确性优先于礼貌关闭的取舍。五、Workstream 4可观测性与文档真实性5.1surfaceclaude请求日志标签040 要求/v1/messages的请求日志行打标签如surfaceclaude使 Logs/Usage 可过滤。源码中该标签已实现logCtx.surface claudeclaude-messages.ts且当请求命中 Desktop 3P 别名时进一步细分为claude-desktopL732-L735。请求日志走常规 deferred-log 路径model/provider 在路由后填充。040 中的GUI Logs 增加过滤 chip仅当 trivial 才做被记录为 follow-up、不阻塞发布。5.2 docs-site troubleshooting 用真实错误文本040 要求 troubleshooting 章节使用来自 Workstream 2 的真实错误文本。落地成果位于 docs-site/src/content/docs/guides/claude-code.md涵盖Did 0 searchesweb_search_call 翻译成 server_tool_use 对、sidecar 未激活needsReauth排查、connectors 禁用shell 中误设ANTHROPIC_API_KEY、/model选择器不显示模型CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY1与 gateway-models.json 缓存、端口变更后环境陈旧、200k 上下文天花板与[1m]变体、bundled-skill 高 Token 占用claudeCode.blockedSkills默认[claude-api]、子代理路由到错误模型!-- ocx-route: --指令等。该文档同时同步翻译到 fr/ja/ko/ru/tr/zh-cn/zh-tw 七个语言目录。六、Workstream 5弃用与发布C4 care6.1 ccs-wrapper 弃用000_plan.md 已把 ccs-wrapper 定性为前身而非基础单文件 FastAPI 包装、模型别名过时、thinking 路由假流、当前未运行。040 要求在其 README 加横幅superseded by opencodexocx claude 指针且不修改该仓库代码。按 050 记录该弃用横幅因目标仓库不在本次单元范围内而被标记为 out of scopeseparate repo, when touched next。6.2 发布流程040 钉死的发布纪律版本号 bump CHANGELOG/release notes遵循仓库约定release: vX.Y.Z提交按 scripts/release.ts 的发布流执行 npm publish干净 shell 上对npm i -g路径做冒烟。scripts/release.ts 的用法签名源码注释bun scripts/release.ts version [--tag latest|preview] [--publish]版本 bump 提交/推送是真实的Release workflow 的 publish 步骤默认 dry-run--bump minor可从 tags npm channels 解析下一个版本。发布前测试门包含npm pack与 bin smoke040 测试计划第 4 条。七、测试计划与 Gate 标准C 门040 为整个加固周期定义了明确的 C 门测试矩阵错误映射表测试每一行分类法 Retry-After透传取消测试中止于流中段断言上游中止 日志 finalizeStall/ping fixture 测试人工 60s 停顿 心跳beta-header ignore 测试全量套件 typecheck GUI/docs 构建发布前npm pack bin smoke。Gate 标准三条任何一条不满足不得退出所有 workstream 决策尤其 Workstream 1 与 3 的非流式原生边界带着证据而非假设记录在案全新 full-gate 运行绿色发布产物核验ccs-wrapper 横幅在其自有仓库提交发布后冒烟干净机器/profile 上npm i -g bitkyc08/opencodex ocx claude完成一次路由回合。050 记录的 gate 实证2026-07-11 全新运行bun test ./tests/2126 pass / 3 skip / 1 fail该失败为 install-scripts 测试因 shell 无 node 的既有环境问题分支改动前同样失败bun x tsc --noEmitcleanGUI 与 docs-site build cleanPlaywright 视觉 QA含 ko 本地化、Claude ON 开关往返、9 条诚实 display_name 的别名列表与 e2e 流式回合mock openai-chat 上游 →/v1/messages?betatrue→ Anthropic SSE 序列断言均通过。八、风险与时间盒040 明确列出两项风险并给出对应纪律签名回放可能膨胀Workstream 1时间盒化——demonstrate-or-document不投机建设。这正是最终选择合成签名 v1 策略、把 signed replay 留到真实故障被演示的原因发布 协议边界同周期过宽若 Workstream 1-3 产生大 diff按blast-radius 规则把发布拆成独立 mini-cycle。九、落地结果与后续来自 050 处置记录各 Workstream 最终状态050_close.mdWorkstream状态1. 思考往返v1 策略交付合成signature_delta出站 回放思考丢弃Anthropic-family 签名回放未构建——决策门保持2. 错误对齐WP2 交付分类法 retry-after Anthropic 形状 auth/origin 拒绝3. 协议边界?betatrue路径匹配、心跳→ping、EOF 无 terminal fail-closed、取消传播、非流式 JSON 回退全部交付4. 可观测性日志行走常规 deferred-log 路径surfaceclaude标签 Logs 过滤 chip 记为 follow-up5. ccs-wrapper 横幅 发布按目标 out of scopeccs-wrapper 仓库排除、未要求发布已登记的 follow-up非阻塞surfaceclaude请求日志标签 GUI Logs 过滤 chipocxr1 信封驱动的 Anthropic-family 签名回放仅当真实回放失败被演示count_tokens与 provider 报告input_tokens的实时漂移检查ccs-wrapper 弃用横幅下次触碰时。同时真实 Claude Code CLI 冒烟发现的三个线上 bugrole:system折叠为 instructions、max_output_tokens等采样参数在 openai-responses 路由上的剥离、占位 Bearer 不转发而注入主 codex 登录态均已修复并留有回归测试。至此opencodex 的 Claude Code 入向通道完成了从能用到协议保真、错误可诊断、发布可复现的完整加固闭环——这正是 040 作为 C3-C4 发布面文档交付的核心价值。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐opencodex Claude Code 入站代理生产级加固错误分类、EOF 熔断、空闲心跳与可观测性闭环WP1–WP4opencodex Claude Code 入站代理生产级加固错误分类、EOF 熔断、空闲心跳与可观测性闭环WP1–WP4 opencodex 通过同端口opencodex Claude Desktop 3P 短别名规范基于 SHA-256 的 claude-{tier}-4-{code} 模型 ID 设计与入站解码实战opencodex Claude Desktop 3P 短别名规范基于 SHA 256 的 claude {tier} 4 {code} 模型 ID 设计与入opencodex 修复 Claude Code authMode 持久化管理 API 往返、live-apply 与 host-managed 路由防御实战opencodex 修复 Claude Code authMode 持久化管理 API 往返、live apply 与 host managed 路由防御实战创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表