CodexPlusPlus 原生 Edge / Chrome 请求标识兼容机制全解析实验特性的启用、指纹校验与恢复协议【免费下载链接】CodexPlusPlusAn enhanced tool for CodexApp, striving to make Codex better to use and more comfortable 一个CodexApp的增强工具努力让Codex变得更好用更舒服项目地址: https://gitcode.com/gh_mirrors/co/CodexPlusPlus本文围绕 CodexPlusPlus 的原生 Edge / Chrome 请求标识兼容实验特性展开完整讲解该实验选项在 Windows 平台下的启用方式、共享设置语义、浏览器扩展对、运行时 SHA-256 指纹校验、监控状态机、文件级恢复协议以及测试与发布验收要求帮助读者理解它如何在不动摇浏览器执行链的前提下让本地用户对受控标签页请求施加标识要求并掌握其安全边界与故障恢复机制。一、功能定位这是适配不是替代CodexPlusPlus 的这份兼容能力见 docs/native-browser-identification.md本质上是针对 Windows 平台一个已固定的原生浏览器服务pinned native browser service的适配层它让本地用户可以要求请求标识而不必等待该服务云端发布策略对此要求放行。需要特别澄清几个关键边界浏览器执行仍然走原始 Edge / Chrome 扩展 随附的原生运行时本特性不会安装另一个浏览器内核它不伪造ChatGPT 登录态也不会因此获得访问其他已认证服务的权限它仅适配指定 Windows 稳定版扩展对与随附运行时指纹其他浏览器、Beta 扩展、未知运行时一律回退到原始判定或直接判定不兼容从源码模块注释看crates/codex-plus-core/src/native_browser.rs该模块明确不实现浏览器执行、云端身份或审批决策。因此可以把该特性理解为一个纯本地、限定运行时版本的请求标识注入适配器。二、启用方式与设置语义2.1 操作路径在 CodexPlusPlus Manager 的增强面板中打开 Codex 增强模式设置找到原生 Edge / Chrome 请求标识兼容实验开关仅 Windows 平台显示见 apps/codex-plus-manager/src/App.tsx打开开关时先弹出确认对话框nativeBrowserConsent内容明确告知受控标签页目标网站可能收到带会话标识的x-browser-agent请求头、扩展会保留开启状态、关闭兼容选项不关闭扩展已保存的标识、仅适配指定 Windows 原生运行时、保存后不会自动重启见 apps/codex-plus-manager/src/native-browser-settings.tsx确认后保存。关键语义与原文档一致且经源码印证设置默认关闭设置结构体中默认值为false见 crates/codex-plus-core/src/settings.rs 与 L629已有保存值会被保留主增强总开关master switch同样控制该选项的激活前端disabled{!masterEnabled}见 apps/codex-plus-manager/src/App.tsx保存不会即时修补正在运行的服务或重启应用必须由下一次 Codex launcher 启动时抓取设置快照并在已存在受支持运行时的情况下、于启动 Codex 之前应用兼容launcher 在启动流程中调用hooks.start_native_browser_compatibility(settings)见 crates/codex-plus-core/src/launcher.rs安装本版本后必须重启旧版 launcher对已运行实例做重新激活并不会启动另一个运行时属主start_monitor被设计为单例属主见 crates/codex-plus-core/src/native_browser.rs。2.2 共享设置键Edge 与 Chrome 共享同一个既有设置键codexAppNativeBrowserRequireIdentification。这意味着如果此前 Edge 专属构建里已启用过该设置那么本合并构建启动后同样放行受支持的 Chrome 配对而不会为 Chrome 另建一个独立 opt-in持久标识披露见下一节对两个浏览器都适用。该设置键在 Rust 端通过#[serde(rename codexAppNativeBrowserRequireIdentification, default)]映射crates/codex-plus-core/src/settings.rs。2.3 持久效果与不可逆性启用后产生持久效果原生受控标签页请求可携带x-browser-agent: ChatGPT/session-id请求头到达目标网站。原生扩展会保留标识开启状态——即便你关闭 CodexPlusPlus 的该选项或恢复服务文件也不会关闭扩展已保存的标识。站点限制、企业策略、原生操作审批与用户停止处理仍全部留在原始执行路径上相关确认文案也出现在前端 consent 中见 apps/codex-plus-manager/src/native-browser-settings.tsx。这解释了为什么文档反复强调验收需在全新环境进行已在启用过的 Edge 配置上测试通过并不能证明首次启用的正确性。三、兼容性矩阵与运行时指纹3.1 浏览器扩展对适配器仅接受以下 Windows 稳定版扩展对仅凭版本号标签不被接受浏览器族扩展 IDedgeodlomjlbamekndcpllcnffbgeohgkmjhchromehehggadaopoacecdllhhajmbjkdcmajg源码中这份判定同时出现在两处Rust 侧RuntimeContract::pinned()crates/codex-plus-core/src/native_browser.rs与注入的 JS helperassets/native-browser/require-identification.mjs。两个扩展 ID 均登记在已固定服务的生产扩展注册表中本地检查到的 Edge 与 Chrome 扩展包在版本1.26.901.11451下后台脚本逐字节相同。需要强调的是这属于静态协议证据并不能证明某个已连接的客户端确实加载了这份磁盘副本——因此运行时 helper 会在每次决策时检查实际客户端信息。3.2 运行时组件 SHA-256 指纹适配器只认下列随附运行时的指纹对应RuntimeContract::pinned()中的常量见 crates/codex-plus-core/src/native_browser.rs组件SHA-256Browser service3e6fd4a8cf09f57549d63f2c9cbfa2abf42f0a6b0c09c3d6605fe07c8ba09e4aNative workeref53f8f0d957b7cf437020499b6b9d880dee381214788930107b549237f7949cNode executablebe14417b6c4b4a5af06be7c16bda58730f26b912c3e8c6489d12392ef08f35bfRuntime manifestba3691b0717b6df8064c3841a75c784e8af9633c7b47f2fdb56d8de099efe6fcCUA entry point992174a5e637645aeb444adfdb1bae688e997bb84d7db07532f68e358e60f278服务文件路径为bin/node_modules/oai/browser-desktop/scripts/browser-service.mjs最大允许 32 MiBMAX_SERVICE其余组件逐个哈希比对见 crates/codex-plus-core/src/native_browser.rs。交叉配对、Beta 扩展、其他浏览器与未知运行时都会回退到原始判定或失败于兼容性检查。3.3 描述符一致性要求生成的unified-computer-use/.mcp.json描述符必须满足多项一致性约束才能启用原生 Node 路径command必须落在运行时缓存目录内且严格为16位hex / bin/node.exe三段结构selected_key的校验见 crates/codex-plus-core/src/native_browser.rsNODE_REPL_NODE_PATH、CUA_REPL_NODE_REPL_PATH必须与上述 Node / worker 路径一致NODE_REPL_TRUSTED_SERVICES中的browser必须指向oai/browser-desktop/service原始浏览器服务CUA_REPL_ENABLED_SURFACES必须为browser入口参数必须唯一指向bin/node_modules/oai/cua-repl/bin/cua-repl.mjs多个描述符指向不同运行时歧义时拒绝启用测试ambiguous_descriptors_refuse_enablement覆盖此场景见 crates/codex-plus-core/src/native_browser.rs。任何歧义描述符、未知哈希、链接路径junction/symlink/reparse point见plain_pathcrates/codex-plus-core/src/native_browser.rs或外部文件变更都会阻止启用。整个过程中不下载、不分发任何远程运行时。3.4 客户端级复核注入的cppNativeIdentificationReaderassets/native-browser/require-identification.mjs在被调用时会做两层校验首检客户端必须是extension类型、family/扩展 ID 匹配上述配对、agentRequestHeaderEnabled为布尔、具备扩展实例 ID、当前 turn 具备 session_id 与 turn_id否则直接走原始 fallbackI/O 后复检读取本地控制文件必须为普通文件、非符号链接、大小 ≤ 1024 字节后再核对一次客户端对象、family、扩展 ID、实例 ID、turn 元数据以及控制文件schema 1且requireIdentification true拒绝跨 I/O 的客户端或浏览器配对变化防止先检查后替换竞态。控制文件由 Rust 侧在~/.codex-session-delete/native-browser-identification/control.json原子写入{schema:1,requireIdentification:true/false}见 crates/codex-plus-core/src/native_browser.rs。四、监控状态机与轮询策略launcher 属主启动后运行一个后台监控任务并维护状态文件status.json。可观测状态包括状态含义waiting_for_runtime尚无原生运行时描述符可用prepared服务已为新原生 worker 准备就绪。注意这不是 worker 已加载的确认也不代表浏览器已成功接受blocked兼容性或恢复检查失败具体原因可在 Manager 中查看restored服务已恢复但扩展保留的标识状态不变stalelauncher 长时间未提供新状态超过 90 秒即视为过期见read_statuscrates/codex-plus-core/src/native_browser.rs前端将这些状态映射为中文标签如等待原生插件生成运行时服务已准备等待新原生工作进程加载状态已过期等并可在blocked时展示具体原因apps/codex-plus-manager/src/native-browser-status.ts。轮询策略见start_monitor_with_contract循环crates/codex-plus-core/src/native_browser.rs启动后 30 秒内且状态为waiting_for_runtime时以500 ms有界间隔重试等待描述符或不完整运行时出现此后稳定为每 15 秒一次空闲时监控任务只比对文件身份、大小与修改时间observation结合 WindowsGetFileInformationByHandle的文件索引/卷序列号做指纹而非反复哈希可执行内容见 crates/codex-plus-core/src/native_browser.rs实际服务写入仍强制走完整指纹校验观察缓存绝不授权写入测试idle_observation_does_not_rewrite_control_or_reconcile印证crates/codex-plus-core/src/native_browser.rs。文档同时给出一个重要局限这种监控无法保证在第一个 worker 加载新生成缓存之前完成拦截它不会强制 worker 重载、不修改 Desktop 生成的描述符、也不附加到 worker 的调试器上。启用后的验收流程对于晚创建的缓存应等到prepared然后新建一个原生工具上下文或重启 Codex 后再进行验收Manager 不会自动重启它。已经通过兼容性判定的请求不会因更改设置而被撤销——原生操作审批始终保持独立。五、恢复协议与安全边界5.1 备份与原子替换原始服务字节、精确候选字节、原始修改时间与日志存放在~/.codex-session-delete/native-browser-identification即state_root位于 Desktop 运行时缓存清理范围之外见BrowserPaths::currentcrates/codex-plus-core/src/native_browser.rs。恢复目录内包含original.mjs原始服务字节candidate-sha256.mjs按候选哈希命名的适配版本journal.json{schema, originalSha, candidateSha, modifiedSecs, modifiedNanos}恢复日志crates/codex-plus-core/src/native_browser.rscontrol.jsonrequireIdentification开关控制文件owner.lock/monitor.lock排他锁文件。写入机制的特征均有测试覆盖见 crates/codex-plus-core/src/native_browser.rs排他事务锁owner.lockfs2排他锁保证同一时刻只有一个兼容事务同步备份与原子替换MoveFileExWMOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH见atomic_write_with_modifiedcrates/codex-plus-core/src/native_browser.rs恢复的字节与修改时间在同一个临时文件句柄上准备好之后再替换不会在发布恢复内容后重新打开目标来补写元数据这避免了内容已恢复、时间戳不一致的窗口恢复前对所有已知缓存做预检restore_all先枚举全部待恢复项并逐一验证再执行任何写入见 crates/codex-plus-core/src/native_browser.rs绝不故意覆盖用户冲突变更Windows 目录句柄pin_parents以FILE_SHARE_READ | FILE_SHARE_WRITE且不带 DELETE 共享打开每个祖先目录在事务期间阻止父目录被重命名测试pinned_parent_cannot_be_renamed_during_transactioncrates/codex-plus-core/src/native_browser.rs。5.2 关闭与恢复关闭该选项并重启 Codex 与 Codex 后新 launcher 会禁用 helper 控制文件并恢复所有已知候选。已处于原始状态的文件保持其修改时间已删除的缓存不会被重建备份会保留。若恢复报告冲突应保留备份与受影响的运行时用于诊断不要删除日志。5.3 有序退出协议与 Manager 重启路径有序的 launcher 退出现在会禁用 helper、恢复服务字节与原始修改时间然后才释放monitor.lock属主锁见start_monitor_with_contract的退出分支crates/codex-plus-core/src/native_browser.rs。该流程会等待一个已经开始的文件系统事务结束在清理完成前第二个兼容监控者不能取得属主权。属主在锁文件中同步写入代际专属完成回执MonitorReceipt{schema, generation, state}state 必须为restoredcrates/codex-plus-core/src/native_browser.rs。已释放的锁若带有活跃、失败或不可读的回执不会被当作成功清理测试manager_rejects_incomplete_receipts_and_legacy_enabled_statecrates/codex-plus-core/src/native_browser.rs。Manager 的 Windows 重启路径wait_for_monitor_shutdowncrates/codex-plus-core/src/native_browser.rs行为如下记录现有 launcher 进程标识先停止 Codex最多等待10 秒等待原生清理完成再最多等待10 秒等待同样的 launcher 进程退出不按进程名终止 launcher若任一等待失败重启流程中止不会强制终止 launcher 或启动另一实例。5.4 异常路径与残余风险强制进程终止、崩溃和旧版 Manager 可能绕过上述退出路径——它们不能作为恢复已完成的证据。恢复日志会保留给下一个兼容 launcher 做对账。新版 Manager无法为未实现属主协议的旧 launcher 补做有序清理只有在既有控制与恢复记录显示无残留启用适配器或候选服务时缺失属主回执才会被接受。最后是安全边界声明这不是针对同用户写权限进程的安全边界——特别是能同时替换恢复记录与文件的恶意进程可以破坏本地完整性。因此未来的适配器版本必须保留对此前受支持原始服务指纹的恢复能力。六、页面准备失败报错归属与界限Unable to prepare popup request headers. Retry the browser command.这条消息来自原始扩展自身的 popup 脚本准备阶段在浏览器发现之后。需要注意它不是更早的 API-Key 身份失败它本身不能区分网络中断或缺失 header-rule 权限原始扩展会把多种注入失败与超时折叠进这一条消息。本地测试观测两个浏览器都能读取新建的普通页面Edge 能读取新建的 Bilibili 首页但已存在的 Bilibili 首页与 Chrome Web Store 页面仍会 popup 准备失败。这不能证明任意页面对两个浏览器都可用也不代表失败页面已恢复其具体注入失败原因仍未解决。本集成不会抑制该检查、禁用请求标识、自动导航已有标签页或以替换原生浏览器执行来掩盖问题——它保留了原始错误路径的可见性。七、测试策略与发布验收7.1 Rust 测试普通 Rust 测试使用合成夹具synthetic fixtures绝不执行随附的专有代码crates/codex-plus-core/src/native_browser.rs 的测试模块。Windows 回归测试覆盖独立拼写的路径分隔符正/反斜杠任意组合windows_descriptor_accepts_independent_separator_stylescrates/codex-plus-core/src/native_browser.rs拒绝真正冲突的路径越界、..、非缓存根、歧义描述符等descriptor_rejects_conflicting_or_malformed_runtime_pathscrates/codex-plus-core/src/native_browser.rs事务、代际时间戳、并发属主互斥、外部变更保护、恢复预检、journal 防伪、monitor 停机恢复等全链路行为。7.2 显式忽略的固定运行时夹具测试该测试读取本地提供的固定运行时及其真实生成的描述符先只读校验原始选择再将描述符与运行时重定位到临时目录执行转换与恢复$env:CPP_NATIVE_BROWSER_FIXTURE C:\path\to\pinned\cua_node\runtime $env:CPP_NATIVE_BROWSER_DESCRIPTOR C:\path\to\unified-computer-use\version\.mcp.json cargo test -p codex-plus-core native_browser::tests::pinned_fixture_transaction_recovery_and_external_change --lib -- --ignored --exact使用要求crates/codex-plus-core/src/native_browser.rsCPP_NATIVE_BROWSER_FIXTURE必须是该描述符实际选中的16 字符运行时目录而非独立重定位的离线副本重定位动作由测试自身完成测试永不写入提供的运行时测试全程验证启用→prepared→禁用→restored→字节与修改时间完全一致→模拟缓存重建与中断部署→外部修改拒绝→恢复。7.3 Node 测试Node 测试只执行第一方标识 helpercppNativeIdentificationReader使用隔离控制文件与桩化的元数据/fallbackapps/codex-plus-manager/src/native-browser-helper.test.ts不执行云端身份、站点策略或原生审批实现。测试覆盖Edge/Chrome 配对元数据接受、原始 fallback 保留、I/O 后客户端变更拒绝、控制文件非法类型拒绝等。7.4 发布验收清单发布验收仍然要求在重启后分别对 Edge 与 Chrome 各做一遍人类测试页面创建、已有标签页访问、输入/点击/重载、实际标识请求头、显式站点/审批拒绝、物理停止、turn 清理、关闭/重启恢复。仅测试一个已启用过的 Edge 配置无法证明首次启用正确性因为扩展保留标识。早前在已启用配置上的 Edge 成功也不能证明 launcher 已实际部署兼容修正后的合并构建需要全新的原生端到端验收 launcher 状态验证。文档明确不暗示任何 macOS 或其他跨平台验收。八、实现链路速查从源码出发把文档中的关键结论落到具体文件关注点仓库位置核心实现发现、准备、恢复、监控、状态机crates/codex-plus-core/src/native_browser.rs注入的本地标识 helperassets/native-browser/require-identification.mjs设置键codexAppNativeBrowserRequireIdentificationcrates/codex-plus-core/src/settings.rslauncher 启动快照与属主启动crates/codex-plus-core/src/launcher.rs前端开关、确认对话框、状态视图apps/codex-plus-manager/src/native-browser-settings.tsx、apps/codex-plus-manager/src/native-browser-status.ts、apps/codex-plus-manager/src/App.tsxNode 侧 helper 测试apps/codex-plus-manager/src/native-browser-helper.test.ts九、总结CodexPlusPlus 的原生 Edge / Chrome 请求标识兼容实验是一个高约束、可回滚的本地适配方案通过共享设置键、严格扩展对白名单、五组件 SHA-256 指纹、描述符一致性校验与客户端 I/O 前后双检把标识要求的判定稳定地锚定在受支持的 Windows 运行时上再借助排他锁、原子替换、代际回执与 10 秒级清理等待把启用与恢复都做成可验证的事务。理解它的状态机waiting_for_runtime→prepared/blocked/restored/stale、持久效果边界扩展保留标识不可被本选项撤销与验收前提全新环境 重启后分浏览器验收是安全使用这一实验特性的前提。【免费下载链接】CodexPlusPlusAn enhanced tool for CodexApp, striving to make Codex better to use and more comfortable 一个CodexApp的增强工具努力让Codex变得更好用更舒服项目地址: https://gitcode.com/gh_mirrors/co/CodexPlusPlus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CodexPlusPlus 原生 Edge / Chrome 请求标识兼容机制全解析实验特性的启用、指纹校验与恢复协议【免费下载链接】CodexPlusPlusAn enhanced tool for CodexApp, striving to make Codex better to use and more comfortable 一个CodexApp的增强工具努力让Codex变得更好用更舒服项目地址: https://gitcode.com/gh_mirrors/co/CodexPlusPlus本文围绕 CodexPlusPlus 的原生 Edge / Chrome 请求标识兼容实验特性展开完整讲解该实验选项在 Windows 平台下的启用方式、共享设置语义、浏览器扩展对、运行时 SHA-256 指纹校验、监控状态机、文件级恢复协议以及测试与发布验收要求帮助读者理解它如何在不动摇浏览器执行链的前提下让本地用户对受控标签页请求施加标识要求并掌握其安全边界与故障恢复机制。一、功能定位这是适配不是替代CodexPlusPlus 的这份兼容能力见 docs/native-browser-identification.md本质上是针对 Windows 平台一个已固定的原生浏览器服务pinned native browser service的适配层它让本地用户可以要求请求标识而不必等待该服务云端发布策略对此要求放行。需要特别澄清几个关键边界浏览器执行仍然走原始 Edge / Chrome 扩展 随附的原生运行时本特性不会安装另一个浏览器内核它不伪造ChatGPT 登录态也不会因此获得访问其他已认证服务的权限它仅适配指定 Windows 稳定版扩展对与随附运行时指纹其他浏览器、Beta 扩展、未知运行时一律回退到原始判定或直接判定不兼容从源码模块注释看crates/codex-plus-core/src/native_browser.rs该模块明确不实现浏览器执行、云端身份或审批决策。因此可以把该特性理解为一个纯本地、限定运行时版本的请求标识注入适配器。二、启用方式与设置语义2.1 操作路径在 CodexPlusPlus Manager 的增强面板中打开 Codex 增强模式设置找到原生 Edge / Chrome 请求标识兼容实验开关仅 Windows 平台显示见 apps/codex-plus-manager/src/App.tsx打开开关时先弹出确认对话框nativeBrowserConsent内容明确告知受控标签页目标网站可能收到带会话标识的x-browser-agent请求头、扩展会保留开启状态、关闭兼容选项不关闭扩展已保存的标识、仅适配指定 Windows 原生运行时、保存后不会自动重启见 apps/codex-plus-manager/src/native-browser-settings.tsx确认后保存。关键语义与原文档一致且经源码印证设置默认关闭设置结构体中默认值为false见 crates/codex-plus-core/src/settings.rs 与 L629已有保存值会被保留主增强总开关master switch同样控制该选项的激活前端disabled{!masterEnabled}见 apps/codex-plus-manager/src/App.tsx保存不会即时修补正在运行的服务或重启应用必须由下一次 Codex launcher 启动时抓取设置快照并在已存在受支持运行时的情况下、于启动 Codex 之前应用兼容launcher 在启动流程中调用hooks.start_native_browser_compatibility(settings)见 crates/codex-plus-core/src/launcher.rs安装本版本后必须重启旧版 launcher对已运行实例做重新激活并不会启动另一个运行时属主start_monitor被设计为单例属主见 crates/codex-plus-core/src/native_browser.rs。2.2 共享设置键Edge 与 Chrome 共享同一个既有设置键codexAppNativeBrowserRequireIdentification。这意味着如果此前 Edge 专属构建里已启用过该设置那么本合并构建启动后同样放行受支持的 Chrome 配对而不会为 Chrome 另建一个独立 opt-in持久标识披露见下一节对两个浏览器都适用。该设置键在 Rust 端通过#[serde(rename codexAppNativeBrowserRequireIdentification, default)]映射crates/codex-plus-core/src/settings.rs。2.3 持久效果与不可逆性启用后产生持久效果原生受控标签页请求可携带x-browser-agent: ChatGPT/session-id请求头到达目标网站。原生扩展会保留标识开启状态——即便你关闭 CodexPlusPlus 的该选项或恢复服务文件也不会关闭扩展已保存的标识。站点限制、企业策略、原生操作审批与用户停止处理仍全部留在原始执行路径上相关确认文案也出现在前端 consent 中见 apps/codex-plus-manager/src/native-browser-settings.tsx。这解释了为什么文档反复强调验收需在全新环境进行已在启用过的 Edge 配置上测试通过并不能证明首次启用的正确性。三、兼容性矩阵与运行时指纹3.1 浏览器扩展对适配器仅接受以下 Windows 稳定版扩展对仅凭版本号标签不被接受浏览器族扩展 IDedgeodlomjlbamekndcpllcnffbgeohgkmjhchromehehggadaopoacecdllhhajmbjkdcmajg源码中这份判定同时出现在两处Rust 侧RuntimeContract::pinned()crates/codex-plus-core/src/native_browser.rs与注入的 JS helperassets/native-browser/require-identification.mjs。两个扩展 ID 均登记在已固定服务的生产扩展注册表中本地检查到的 Edge 与 Chrome 扩展包在版本1.26.901.11451下后台脚本逐字节相同。需要强调的是这属于静态协议证据并不能证明某个已连接的客户端确实加载了这份磁盘副本——因此运行时 helper 会在每次决策时检查实际客户端信息。3.2 运行时组件 SHA-256 指纹适配器只认下列随附运行时的指纹对应RuntimeContract::pinned()中的常量见 crates/codex-plus-core/src/native_browser.rs组件SHA-256Browser service3e6fd4a8cf09f57549d63f2c9cbfa2abf42f0a6b0c09c3d6605fe07c8ba09e4aNative workeref53f8f0d957b7cf437020499b6b9d880dee381214788930107b549237f7949cNode executablebe14417b6c4b4a5af06be7c16bda58730f26b912c3e8c6489d12392ef08f35bfRuntime manifestba3691b0717b6df8064c3841a75c784e8af9633c7b47f2fdb56d8de099efe6fcCUA entry point992174a5e637645aeb444adfdb1bae688e997bb84d7db07532f68e358e60f278服务文件路径为bin/node_modules/oai/browser-desktop/scripts/browser-service.mjs最大允许 32 MiBMAX_SERVICE其余组件逐个哈希比对见 crates/codex-plus-core/src/native_browser.rs。交叉配对、Beta 扩展、其他浏览器与未知运行时都会回退到原始判定或失败于兼容性检查。3.3 描述符一致性要求生成的unified-computer-use/.mcp.json描述符必须满足多项一致性约束才能启用原生 Node 路径command必须落在运行时缓存目录内且严格为16位hex / bin/node.exe三段结构selected_key的校验见 crates/codex-plus-core/src/native_browser.rsNODE_REPL_NODE_PATH、CUA_REPL_NODE_REPL_PATH必须与上述 Node / worker 路径一致NODE_REPL_TRUSTED_SERVICES中的browser必须指向oai/browser-desktop/service原始浏览器服务CUA_REPL_ENABLED_SURFACES必须为browser入口参数必须唯一指向bin/node_modules/oai/cua-repl/bin/cua-repl.mjs多个描述符指向不同运行时歧义时拒绝启用测试ambiguous_descriptors_refuse_enablement覆盖此场景见 crates/codex-plus-core/src/native_browser.rs。任何歧义描述符、未知哈希、链接路径junction/symlink/reparse point见plain_pathcrates/codex-plus-core/src/native_browser.rs或外部文件变更都会阻止启用。整个过程中不下载、不分发任何远程运行时。3.4 客户端级复核注入的cppNativeIdentificationReaderassets/native-browser/require-identification.mjs在被调用时会做两层校验首检客户端必须是extension类型、family/扩展 ID 匹配上述配对、agentRequestHeaderEnabled为布尔、具备扩展实例 ID、当前 turn 具备 session_id 与 turn_id否则直接走原始 fallbackI/O 后复检读取本地控制文件必须为普通文件、非符号链接、大小 ≤ 1024 字节后再核对一次客户端对象、family、扩展 ID、实例 ID、turn 元数据以及控制文件schema 1且requireIdentification true拒绝跨 I/O 的客户端或浏览器配对变化防止先检查后替换竞态。控制文件由 Rust 侧在~/.codex-session-delete/native-browser-identification/control.json原子写入{schema:1,requireIdentification:true/false}见 crates/codex-plus-core/src/native_browser.rs。四、监控状态机与轮询策略launcher 属主启动后运行一个后台监控任务并维护状态文件status.json。可观测状态包括状态含义waiting_for_runtime尚无原生运行时描述符可用prepared服务已为新原生 worker 准备就绪。注意这不是 worker 已加载的确认也不代表浏览器已成功接受blocked兼容性或恢复检查失败具体原因可在 Manager 中查看restored服务已恢复但扩展保留的标识状态不变stalelauncher 长时间未提供新状态超过 90 秒即视为过期见read_statuscrates/codex-plus-core/src/native_browser.rs前端将这些状态映射为中文标签如等待原生插件生成运行时服务已准备等待新原生工作进程加载状态已过期等并可在blocked时展示具体原因apps/codex-plus-manager/src/native-browser-status.ts。轮询策略见start_monitor_with_contract循环crates/codex-plus-core/src/native_browser.rs启动后 30 秒内且状态为waiting_for_runtime时以500 ms有界间隔重试等待描述符或不完整运行时出现此后稳定为每 15 秒一次空闲时监控任务只比对文件身份、大小与修改时间observation结合 WindowsGetFileInformationByHandle的文件索引/卷序列号做指纹而非反复哈希可执行内容见 crates/codex-plus-core/src/native_browser.rs实际服务写入仍强制走完整指纹校验观察缓存绝不授权写入测试idle_observation_does_not_rewrite_control_or_reconcile印证crates/codex-plus-core/src/native_browser.rs。文档同时给出一个重要局限这种监控无法保证在第一个 worker 加载新生成缓存之前完成拦截它不会强制 worker 重载、不修改 Desktop 生成的描述符、也不附加到 worker 的调试器上。启用后的验收流程对于晚创建的缓存应等到prepared然后新建一个原生工具上下文或重启 Codex 后再进行验收Manager 不会自动重启它。已经通过兼容性判定的请求不会因更改设置而被撤销——原生操作审批始终保持独立。五、恢复协议与安全边界5.1 备份与原子替换原始服务字节、精确候选字节、原始修改时间与日志存放在~/.codex-session-delete/native-browser-identification即state_root位于 Desktop 运行时缓存清理范围之外见BrowserPaths::currentcrates/codex-plus-core/src/native_browser.rs。恢复目录内包含original.mjs原始服务字节candidate-sha256.mjs按候选哈希命名的适配版本journal.json{schema, originalSha, candidateSha, modifiedSecs, modifiedNanos}恢复日志crates/codex-plus-core/src/native_browser.rscontrol.jsonrequireIdentification开关控制文件owner.lock/monitor.lock排他锁文件。写入机制的特征均有测试覆盖见 crates/codex-plus-core/src/native_browser.rs排他事务锁owner.lockfs2排他锁保证同一时刻只有一个兼容事务同步备份与原子替换MoveFileExWMOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH见atomic_write_with_modifiedcrates/codex-plus-core/src/native_browser.rs恢复的字节与修改时间在同一个临时文件句柄上准备好之后再替换不会在发布恢复内容后重新打开目标来补写元数据这避免了内容已恢复、时间戳不一致的窗口恢复前对所有已知缓存做预检restore_all先枚举全部待恢复项并逐一验证再执行任何写入见 crates/codex-plus-core/src/native_browser.rs绝不故意覆盖用户冲突变更Windows 目录句柄pin_parents以FILE_SHARE_READ | FILE_SHARE_WRITE且不带 DELETE 共享打开每个祖先目录在事务期间阻止父目录被重命名测试pinned_parent_cannot_be_renamed_during_transactioncrates/codex-plus-core/src/native_browser.rs。5.2 关闭与恢复关闭该选项并重启 Codex 与 Codex 后新 launcher 会禁用 helper 控制文件并恢复所有已知候选。已处于原始状态的文件保持其修改时间已删除的缓存不会被重建备份会保留。若恢复报告冲突应保留备份与受影响的运行时用于诊断不要删除日志。5.3 有序退出协议与 Manager 重启路径有序的 launcher 退出现在会禁用 helper、恢复服务字节与原始修改时间然后才释放monitor.lock属主锁见start_monitor_with_contract的退出分支crates/codex-plus-core/src/native_browser.rs。该流程会等待一个已经开始的文件系统事务结束在清理完成前第二个兼容监控者不能取得属主权。属主在锁文件中同步写入代际专属完成回执MonitorReceipt{schema, generation, state}state 必须为restoredcrates/codex-plus-core/src/native_browser.rs。已释放的锁若带有活跃、失败或不可读的回执不会被当作成功清理测试manager_rejects_incomplete_receipts_and_legacy_enabled_statecrates/codex-plus-core/src/native_browser.rs。Manager 的 Windows 重启路径wait_for_monitor_shutdowncrates/codex-plus-core/src/native_browser.rs行为如下记录现有 launcher 进程标识先停止 Codex最多等待10 秒等待原生清理完成再最多等待10 秒等待同样的 launcher 进程退出不按进程名终止 launcher若任一等待失败重启流程中止不会强制终止 launcher 或启动另一实例。5.4 异常路径与残余风险强制进程终止、崩溃和旧版 Manager 可能绕过上述退出路径——它们不能作为恢复已完成的证据。恢复日志会保留给下一个兼容 launcher 做对账。新版 Manager无法为未实现属主协议的旧 launcher 补做有序清理只有在既有控制与恢复记录显示无残留启用适配器或候选服务时缺失属主回执才会被接受。最后是安全边界声明这不是针对同用户写权限进程的安全边界——特别是能同时替换恢复记录与文件的恶意进程可以破坏本地完整性。因此未来的适配器版本必须保留对此前受支持原始服务指纹的恢复能力。六、页面准备失败报错归属与界限Unable to prepare popup request headers. Retry the browser command.这条消息来自原始扩展自身的 popup 脚本准备阶段在浏览器发现之后。需要注意它不是更早的 API-Key 身份失败它本身不能区分网络中断或缺失 header-rule 权限原始扩展会把多种注入失败与超时折叠进这一条消息。本地测试观测两个浏览器都能读取新建的普通页面Edge 能读取新建的 Bilibili 首页但已存在的 Bilibili 首页与 Chrome Web Store 页面仍会 popup 准备失败。这不能证明任意页面对两个浏览器都可用也不代表失败页面已恢复其具体注入失败原因仍未解决。本集成不会抑制该检查、禁用请求标识、自动导航已有标签页或以替换原生浏览器执行来掩盖问题——它保留了原始错误路径的可见性。七、测试策略与发布验收7.1 Rust 测试普通 Rust 测试使用合成夹具synthetic fixtures绝不执行随附的专有代码crates/codex-plus-core/src/native_browser.rs 的测试模块。Windows 回归测试覆盖独立拼写的路径分隔符正/反斜杠任意组合windows_descriptor_accepts_independent_separator_stylescrates/codex-plus-core/src/native_browser.rs拒绝真正冲突的路径越界、..、非缓存根、歧义描述符等descriptor_rejects_conflicting_or_malformed_runtime_pathscrates/codex-plus-core/src/native_browser.rs事务、代际时间戳、并发属主互斥、外部变更保护、恢复预检、journal 防伪、monitor 停机恢复等全链路行为。7.2 显式忽略的固定运行时夹具测试该测试读取本地提供的固定运行时及其真实生成的描述符先只读校验原始选择再将描述符与运行时重定位到临时目录执行转换与恢复$env:CPP_NATIVE_BROWSER_FIXTURE C:\path\to\pinned\cua_node\runtime $env:CPP_NATIVE_BROWSER_DESCRIPTOR C:\path\to\unified-computer-use\version\.mcp.json cargo test -p codex-plus-core native_browser::tests::pinned_fixture_transaction_recovery_and_external_change --lib -- --ignored --exact使用要求crates/codex-plus-core/src/native_browser.rsCPP_NATIVE_BROWSER_FIXTURE必须是该描述符实际选中的16 字符运行时目录而非独立重定位的离线副本重定位动作由测试自身完成测试永不写入提供的运行时测试全程验证启用→prepared→禁用→restored→字节与修改时间完全一致→模拟缓存重建与中断部署→外部修改拒绝→恢复。7.3 Node 测试Node 测试只执行第一方标识 helpercppNativeIdentificationReader使用隔离控制文件与桩化的元数据/fallbackapps/codex-plus-manager/src/native-browser-helper.test.ts不执行云端身份、站点策略或原生审批实现。测试覆盖Edge/Chrome 配对元数据接受、原始 fallback 保留、I/O 后客户端变更拒绝、控制文件非法类型拒绝等。7.4 发布验收清单发布验收仍然要求在重启后分别对 Edge 与 Chrome 各做一遍人类测试页面创建、已有标签页访问、输入/点击/重载、实际标识请求头、显式站点/审批拒绝、物理停止、turn 清理、关闭/重启恢复。仅测试一个已启用过的 Edge 配置无法证明首次启用正确性因为扩展保留标识。早前在已启用配置上的 Edge 成功也不能证明 launcher 已实际部署兼容修正后的合并构建需要全新的原生端到端验收 launcher 状态验证。文档明确不暗示任何 macOS 或其他跨平台验收。八、实现链路速查从源码出发把文档中的关键结论落到具体文件关注点仓库位置核心实现发现、准备、恢复、监控、状态机crates/codex-plus-core/src/native_browser.rs注入的本地标识 helperassets/native-browser/require-identification.mjs设置键codexAppNativeBrowserRequireIdentificationcrates/codex-plus-core/src/settings.rslauncher 启动快照与属主启动crates/codex-plus-core/src/launcher.rs前端开关、确认对话框、状态视图apps/codex-plus-manager/src/native-browser-settings.tsx、apps/codex-plus-manager/src/native-browser-status.ts、apps/codex-plus-manager/src/App.tsxNode 侧 helper 测试apps/codex-plus-manager/src/native-browser-helper.test.ts九、总结CodexPlusPlus 的原生 Edge / Chrome 请求标识兼容实验是一个高约束、可回滚的本地适配方案通过共享设置键、严格扩展对白名单、五组件 SHA-256 指纹、描述符一致性校验与客户端 I/O 前后双检把标识要求的判定稳定地锚定在受支持的 Windows 运行时上再借助排他锁、原子替换、代际回执与 10 秒级清理等待把启用与恢复都做成可验证的事务。理解它的状态机waiting_for_runtime→prepared/blocked/restored/stale、持久效果边界扩展保留标识不可被本选项撤销与验收前提全新环境 重启后分浏览器验收是安全使用这一实验特性的前提。【免费下载链接】CodexPlusPlusAn enhanced tool for CodexApp, striving to make Codex better to use and more comfortable 一个CodexApp的增强工具努力让Codex变得更好用更舒服项目地址: https://gitcode.com/gh_mirrors/co/CodexPlusPlus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
