opencodex 发布可部署性加固：从 dev 分支脏工作区到 npm 2.6.14 的发布门禁实战

【免费下载链接】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 仓库 devlog 中的发布加固记录devlog/_fin/260701_deployability-hardening/00_plan.md完整还原一次真实发布周期的处理流程当 dev 分支携带未完成的重构、版本号回退和未覆盖的新头部时如何通过版本修复、测试补齐与干净工作区验证安全地把2.6.13推进到2.6.14。读完本文你将掌握一套可复用的发布前可部署性检查方法论以及 opencodex 中客户端指纹client fingerprint头部的实际实现与测试方式。背景发布表面Release Surface与脏工作区问题opencodex 的发布面向两个直接可见的表面Surfacerelease 表面package.json中的版本号即 npm 上对外发布的产品版本请求指纹表面src/adapters/anthropic.ts中构造的请求头headers它决定了代理发出的请求在 Anthropic 服务端看起来是否是第一方客户端。2026-07-01 的这次加固C4 类发布表面问题核心目标是让dev分支相对已发布的origin/mainnpmlatest 2.6.13具备可部署性同时不把工作区中未完成、脏状态的指纹重构一并卷入发布。问题在于开发分支上正在进行一项跨多文件的client-fingerprint重构工作区处于 dirty 状态。如果直接发布既可能带上半成品代码也可能因为版本号问题导致发布失败或降级发布。发现的两个发布阻塞项Blockers对git diff origin/main..HEAD的审查发现两个必须处理的阻塞项1. 版本回归RELEASE BLOCKERdev分支的package.json版本是2.6.4而origin/main是2.6.13npm 上的latest标签同样是2.6.13。原因是在更早的会话中 dev 工作区的package.json被重置过且从未重新提升版本。后果很直接从这个工作树发布要么失败要么会发布一个更低的版本号。在 npm 语义下从 2.6.13 回退到 2.6.4 发布是危险的降级发布必须修复。2. 未测试的头部变更Untested swept headers提交1302a18给src/adapters/anthropic.ts引入了两个新请求头但没有配套测试Accept按流式条件取值——流式请求为text/event-stream否则为application/jsonUser-Agent固定为anthropic-ai/sdk/0.74.0。这两个头部是第一方指纹加固的一部分它们与client-fingerprint.ts/CLAUDE_CODE_HEADERS中固定的 SDK 版本0.74.0一致并且在isOAuth分支之前设置因此同时作用于 OAuth 和 API-key 两条路径。意图明确但缺少测试覆盖——这在发布门禁中属于未覆盖的变更不能直接放行。已在 dev 上验证的意图变更不重新触碰这次发布并非只修问题计划同时保留 dev 上已经验证、无需回退的变更WP1anthropic reasoning-none 门提交5ac3573 配套测试WP2openai-chat 流被截断时的 EOF fail-closed提交3ac5dc2 配套测试WP4server.ts部分拆分——gui-staticadapter-resolve行为保持不变WP5codex-catalog golden oracle 测试为未来拆分提供的安全网。这些变更通过已确认、不重刷的方式进入发布候选避免无谓的重做引入新风险。明确排除在外的范围Out of scope正在进行的指纹重构故意不纳入本次发布包括client-fingerprint.tsX-Stainless-Arch/OS/Package-Version/Runtime-Version 追加、google.ts、kiro-wire.ts、kiro.ts、oauth/anthropic.ts、oauth/google-antigravity.ts、oauth/kimi.ts、tests/google-antigravity-wire.test.ts。这些属于用户正在进行的工作并非本次发布候选的必需内容。这一范围切割决策是发布加固的核心思想只发布经过验证的增量把未完成的工作留在工作区。修复落地WP1候选提交 717d2ff版本修复2.6.4 → 2.6.14package.json版本从2.6.4提升到2.6.14下一个未使用的版本号。当时的 npm dist-tags 状态为latest2.6.13、preview2.6.11-preview.20260630因此2.6.14高于两者可以安全发布。顺带一提当前仓库package.json的版本已演进到2.60.0本文记录的是 2026-07-01 这一发布周期。测试补齐client fingerprint 断言在tests/client-fingerprint.test.ts中新增两组断言双路径覆盖OAuth 与 API-key 两种认证模式下请求头都必须包含Acceptapplication/json与User-Agentanthropic-ai/sdk/0.74.0流式协商流式请求的Accept必须是text/event-stream。红绿验证已确认删除Accept头部会导致 2 个测试失败——这正是未测试变更被补上测试后的直接效果。源码印证头部到底是怎么组装的在 src/adapters/anthropic.ts 的buildRequest中头部组装逻辑与文档描述完全一致const headers: Recordstring, string { Content-Type: application/json, anthropic-version: 2023-06-01, Accept: parsed.stream ? text/event-stream : application/json, User-Agent: anthropic-ai/sdk/0.74.0, }; if (isOAuth) { headers[Authorization] Bearer ${provider.apiKey}; headers[anthropic-beta] ANTHROPIC_OAUTH_BETA; Object.assign(headers, CLAUDE_CODE_HEADERS); headers[X-Claude-Code-Session-Id] claudeCodeSessionId(provider.apiKey); headers[x-client-request-id] crypto.randomUUID(); } else { if (anthropicKeyUsesBearer(provider)) headers[Authorization] Bearer ${provider.apiKey}; else headers[x-api-key] provider.apiKey; }注意Accept和User-Agent位于isOAuth判断之前——这就是文档所说作用于两条路径的代码依据。而CLAUDE_CODE_HEADERS定义在 src/adapters/client-fingerprint.ts包含X-App: cli、X-Stainless-Retry-Count: 0、X-Stainless-Runtime: node、X-Stainless-Lang: js、X-Stainless-Timeout: 600以及后续 WP2 追加的X-Stainless-Arch取process.arch、X-Stainless-OS取process.platform、X-Stainless-Package-Version: 0.74.0、X-Stainless-Runtime-Version取process.version。该文件的注释明确解释了为什么需要这些指纹携带有效 OAuth token 但头部签名为空或暴露身份的 UA如字面量 antigravity的请求会被上游视为非第一方签名而代理必须让请求指纹与凭证来源匹配。其中claudeCodeSessionId()用 token 的 SHA-256 哈希派生出稳定的 v4 形状 UUID保证同一会话内跨轮次稳定、且绝不回显原始 token。测试侧tests/clients/client-fingerprint.test.ts 正是 WP1 补的两组断言Acceptapplication/jsonUser-Agentanthropic-ai/sdk/0.74.0双路径断言以及流式请求Accepttext/event-stream断言同文件还验证了 API-key 模式不携带X-App、X-Claude-Code-Session-Id等 Claude Code CLI 头部见 L113-L118。验证流程强制使用干净的临时工作树文档强调了一个关键实践脏的主工作区会掩盖回归问题因此验证必须在候选 SHA 上以分离 HEAD 的干净工作树进行git worktree add --detach /tmp/ocx-verify-717d2ff 717d2ff bun install --frozen-lockfile bun run privacy:scan # passed bun x tsc --noEmit # exit 0 bun test ./tests/ # 977 pass / 0 fail / 5123 expect, 93 files2 次稳定运行基线是 975 个通过新增指纹断言后 2 达到 977与补测的 2 个断言一一对应。验证完成后移除临时工作树。这套命令与仓库 package.json 中定义的脚本一一对应privacy:scanscripts/privacy-scan.ts 扫描 token、邮箱、home 路径等隐私泄露、typecheckbun x tsc --noEmit、testscripts/test.ts。发布前的完整门禁还包括prepublishOnlyaudit typecheck GUI 构建与npm pack --dry-run。WP2评审后加固与用户变更折叠WP1 的 gpt-5.5 评审结论为 SHIP-WITH-NITS带瑕疵发布。随后用户确认之前推迟的工作区变更是他们自己的作品必须进入本次发布于是进入 WP2候选提交f34f742并清掉 WP1 评审中的一个 MEDIUM 问题openai-chat EOF MEDIUM 修复一个不带尾部换行的最终finish_reason/usage 帧滞留在buffer中读取器在 EOF 时永远不会解析它导致一个完整流被误判为失败。修复方式是在终端信号检查之前增加尾部缓冲冲洗trailing-buffer flush而真正被截断的内容中间帧仍然 fail-closed。3 个配套测试红绿验证。openai-responsesstripUnsupportedHostedTools在 OAuth 透传前移除原生 slug 拒绝的 hosted tools如 codex-spark 场景下的image_generation。2 个配套测试。client-fingerprint追加X-Stainless的 Arch/OS/Package-Version/Runtime-Version。googleantigravity UA 组装位置调整运行时x-goog-api-client移除改为仅 onboarding 使用 测试更新修复一处多余 7 空格缩进。oauthanthropic 工具前缀proxy_→custom_antigravity onboarding UA x-goog-api-clientkimi CLI0.14.0kimi_code_cli平台。kiro指纹盐fingerprint saltKIRO_IDE_VERSION对齐。WP2 验证干净工作树 f34f742bun test ./tests/ # 982 pass / 0 fail / 5134 expect, 93 files2 次稳定运行 bun x tsc --noEmit # exit 0 bun run privacy:scan # passed bun run prepublishOnly # GUI build package prep, exit 0 npm pack --dry-run # bitkyc08-opencodex-2.6.14.tgz, 131 files, validnpm pack --dry-run产出bitkyc08-opencodex-2.6.14.tgz131 个文件包内容与package.json的files字段bin、src、gui/dist、assets/banner.png等吻合。openai-chat EOF 修复的源码依据WP2 的 MEDIUM 修复在 src/adapters/openai-chat.ts 中可以看到现行实现流读取循环结束后先检查buffer.length 0并调用handleDataLine(buffer)冲洗尾部缓冲再进入终端信号判断sawFinish。若没有finish_reason且存在未完成的 tool call则默认保持 fail-closed 策略upstream stream ended mid tool call without a terminal signal — possible truncation仅当 provider 显式开启openaiChatEofTolerance且工具调用参数是完整 JSON 对象时才放行。这印证了文档中真正截断的中间帧仍 fail-closed的表述。可复用的发布加固方法论从这次 2.6.13 → 2.6.14 的发布周期中可以提炼出四条可直接复用的实践发布前强制 diff 审查以git diff origin/main..HEAD为审查入口区分必须修复的阻塞项与已验证的意图变更避免在发布候选里混入未知增量。版本号先行发布前确认package.json版本高于origin/main与 npmlatestdist-tag杜绝降级发布。未测试变更不放行任何进入发布候选的代码变更必须有配套测试红绿验证删除断言 → 测试失败是证明测试有效性的标准手段。干净工作树验证脏工作区会掩盖回归验证必须在git worktree add --detach的干净候选 SHA 上执行跑完privacy:scantsc --noEmit 全量bun testprepublishOnlynpm pack --dry-run后才算通过。总结opencodex 的 2.6.14 发布周期展示了可部署性如何被当作一等公民对待版本回归被拦截、未覆盖的指纹头部被补上双路径测试、未完成的重构被明确排除、验证在干净的临时工作树中完成并在评审后把用户工作安全折叠进发布。这套范围切割 测试补齐 干净验证 分阶段评审的流程对任何基于 Git 分支模型发布 npm 包的团队都具有直接的参考价值。赞分享【免费下载链接】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 发布工程实战从 v2.1.8 发布计划解读版本门禁、CI 验证与 npm 可信发布流水线opencodex 发布工程实战从 v2.1.8 发布计划解读版本门禁、CI 验证与 npm 可信发布流水线 本文以仓库中的 v2.1.8 发布计划 httpopencodex 发布与部署门禁加固实战Service 门径漂移修复、输入注入防护与 dry-run 发布证明opencodex 发布与部署门禁加固实战Service 门径漂移修复、输入注入防护与 dry run 发布证明 本文基于仓库 devlog 记录 020_wopencodex 预览通道Preview受控发布实战从 preview 分支到 npm dist-tag 的端到端流程opencodex 预览通道Preview受控发布实战从 preview 分支到 npm dist tag 的端到端流程 导读 本文以 opencodex上一篇ColorControl与LG电视网络连接问题排查从入门到精通下一篇Jellium Desktop字幕语言设置教程快速配置多语言字幕创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考