一个核心、三个入口Codex Provider Sync 的 Node Core Electron 架构深度拆解【免费下载链接】codex-provider-syncSynchronize Codex session provider metadata across rollout files and SQLite state.项目地址: https://gitcode.com/gh_mirrors/co/codex-provider-syncCodex Provider Sync是一款 Codex 会话元数据同步工具切换 Provider 后它负责把会话文件与 SQLite 聊天索引中的 Provider 信息对齐回当前配置。这个项目最有意思的地方在于它的架构——一个 Node Core 核心 三个用户入口Windows 桌面版、Local Web、CLI用 Electron 承载桌面体验却不让界面代码碰任何业务逻辑。为什么必须是单一核心在深入架构之前先理解这个项目要对抗的诱惑功能重复实现。这个项目早期同时维护了 Node 和 .NET 两套桌面实现都理解同一套同步业务。结果就是同一套锁、备份、恢复、SQLite 规则要写两份两个入口的行为容易漂移发布流水线也被拆成两套世界。因此项目在 ADR-0002Node Core 是唯一业务权威 中做出了关键裁决CLI、Local Web UI 和 Electron Desktop 必须通过稳定 Public API 调用同一 CoreNode Core 负责所有同步、备份、恢复和数据安全规则其他入口只负责各自的交互方式。这个决策带来一个非常清爽的依赖关系完整路线见 vNext 架构基线文档层职责明确禁止React RendererUI、交互、表单、展示直接操作文件、SQLite、shellPreload最小、类型化、白名单 API暴露原始 Electron/Node APIElectron Main窗口、生命周期、安全策略、进程监督执行长时间核心业务Core Utility Process执行 Node Core、进度、取消创建窗口、操作 RendererNode Core所有业务与数据安全规则依赖 Electron、DOM、ReactCLI / Web Adapter参数解析、HTTP、输出格式复制核心业务一句话总结React 负责看见什么、如何交互Electron 负责窗口和桌面能力Node Core 负责数据怎么安全地变。一个核心Node Core 怎么组织Node Core 的业务用例位于packages/core/src/application/每个文件对应一个完整用户操作provider-sync.js —— 同步只对齐 rollout 会话文件与 SQLite 中的 Providerprovider-switch.js —— 切换修改 config 根级 Provider 后复用同步backups.js / restore.js —— 受管备份查询与恢复operation-runtime.js —— Plan 生命周期、并发控制与取消而成熟的存储算法rollout 流式扫描、原地覆盖、SQLite 事务、写入前备份仍保留在根src/目录通过端口层静态接入不为了目录整齐而重写。当前模块归属见 Node Core 当前架构文档。所有入口共享的输入/输出类型则统一放在 packages/contracts/src/dto.ts防止 CLI、Web、Electron 各自理解一套不同的结果结构。写入前的 Plan → Confirm → Apply 模型Core 最重要的安全设计是任何写入都分为 Prepare 和 Apply 两步。读取当前状态 → 生成不可变 Plan → 展示影响范围和警告 → 用户确认 → 重新校验 Revision/Snapshot → 执行写入 → 验证与结果报告Plan 是一个随机不透明 ID默认 TTL 10 分钟、进程内单次消费Apply 时不得盲信几秒前的扫描结果必须重新核对 Profile Revision、config 哈希、文件快照等任一变化就返回STALE_STATE要求用户刷新后重新确认修改前自动创建备份默认保留 2 份无需修改则不备份。这意味着无论你在桌面版点按钮、在浏览器里操作还是用 CLI 脚本执行预览 → 确认 → 落盘的安全路径完全一致。三个入口同一份逻辑三种打开方式入口一Windows 桌面版Electron桌面版是日常双击即用的完整产品支持概览、聊天记录、备份恢复、诊断修复等页面用户无需安装 Node.js。桌面版最值得拆解的是进程结构ADR-0005Renderer (React) → Preload (Typed Bridge) → Main (IPC Router Supervisor) → Utility Process (Core Runtime Host) → Node Core为什么要把 Node Core 放进 Utility Process因为 rollout 扫描、SQLite 操作、备份复制可能长时间运行——放在 Main 会卡住窗口生命周期放在 Renderer 会破坏安全边界。utilityProcess是 Electron 自带的 Node 运行时加载的仍然是同一个codex-provider-sync/core包不是 Sidecar也不是第二套核心。Main 中的 Supervisor 负责懒启动、协议版本握手、请求路由、进度转发、崩溃归类Core 进程崩溃时所有 pending 请求统一归类为CORE_RUNTIME_CRASHED而不是让 UI 假死。核心宿主实现见 apps/desktop/src/runtime/host.tsIPC 路由见 apps/desktop/src/main/ipc-router.ts。安全边界同样严格ADR-0004Renderer 只能通过 Preload 暴露的白名单方法如getStatus、prepareSync、applySync调用核心拿不到fs、sqlite、ipcRenderer等任何原始能力。入口二Local Web UI安装 npm 包后运行codex-provider web默认只监听本机127.0.0.1:8791浏览器完成配对后即可操作适合不想装桌面版的跨平台环境。HTTP 服务端实现src/web-server.js浏览器端入口apps/web/src/main.tsx使用指南Web UI 中文指南Local Web 的 UI 层复用与桌面版相同的 React 应用包HTTP 适配器只负责配对、DTO 映射和路由不解释业务规则。入口三CLI / 脚本 / WSLCLI 是最古老的入口也是 npm 发布包的直接产物npm install -g dailin521/codex-provider-sync codex-provider status codex-provider sync命令入口src/cli.js唯一受支持的 Core 导入面src/public-api.jsCLI 指南与 JSON 输出/退出码约定CLI 中文指南CLI 的特别之处在于它可以在同一进程中连续 Prepare/Apply即预览后直接执行无需等待 UI 确认但消费的仍是同一个 Core Plan 与同一套并发控制。共享 UI一套页面服务两个宿主三个入口共享的还不只是 Core还有界面。packages/app-ui/提供概览、同步、切换、历史、备份恢复等全部页面组件App 根组件Electron Renderer 和 Local Web 分别通过packages/core-client/中的 IPC 客户端 和 HTTP 客户端 接入——UI 代码对请求是走 IPC 还是 HTTP完全无感知。这正是三个入口带来的复利修一个 bug、加一个功能一处改动三个入口同时受益。快速上手从哪开始读这个仓库想做什么去哪里理解总体架构路线docs/VNEXT_ELECTRON_NODE_ARCHITECTURE_ZH.md看当前模块真实归属与约束docs/architecture/NODE_CORE_ARCHITECTURE_ZH.md查架构决策ADR 0001–0046docs/adr/找业务用例实现packages/core/src/application/看桌面进程通信apps/desktop/src/main/ 与 apps/desktop/src/runtime/跑防漂移门禁仓库根目录执行npm run architecture:check与npm test项目根 package.json 采用 npm workspaces 组织apps/*cli、desktop、web与packages/*core、contracts、core-client、app-ui 等依赖方向由 scripts/verify-workspace-boundaries.js 强制校验——core禁止依赖 Electron/React/DOMrenderer禁止依赖node:*从工程层面锁死了架构边界。小结这个架构给中小项目的三条启示让唯一权威写在 ADR 里不是口头约定而是 ADR-0002 这样的正式决策 自动化边界检查防止双核心悄悄复活。把长任务隔离到独立进程Electron Utility Process 方案让窗口永远流畅也让核心崩溃与 UI 崩溃互不牵连。入口只是适配器CLI 解析参数、Web 处理 HTTP、Electron 管理窗口业务规则一处实现、处处一致——选择入口只影响操作方式不影响同步结果。这就是 Codex Provider Sync 的一个核心、三个入口用最少的重复代码交付三种体验一致的产品入口。【免费下载链接】codex-provider-syncSynchronize Codex session provider metadata across rollout files and SQLite state.项目地址: https://gitcode.com/gh_mirrors/co/codex-provider-sync创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 一个核心、三个入口：Codex Provider Sync 的 Node Core + Electron 架构深度拆解
一个核心、三个入口Codex Provider Sync 的 Node Core Electron 架构深度拆解【免费下载链接】codex-provider-syncSynchronize Codex session provider metadata across rollout files and SQLite state.项目地址: https://gitcode.com/gh_mirrors/co/codex-provider-syncCodex Provider Sync是一款 Codex 会话元数据同步工具切换 Provider 后它负责把会话文件与 SQLite 聊天索引中的 Provider 信息对齐回当前配置。这个项目最有意思的地方在于它的架构——一个 Node Core 核心 三个用户入口Windows 桌面版、Local Web、CLI用 Electron 承载桌面体验却不让界面代码碰任何业务逻辑。为什么必须是单一核心在深入架构之前先理解这个项目要对抗的诱惑功能重复实现。这个项目早期同时维护了 Node 和 .NET 两套桌面实现都理解同一套同步业务。结果就是同一套锁、备份、恢复、SQLite 规则要写两份两个入口的行为容易漂移发布流水线也被拆成两套世界。因此项目在 ADR-0002Node Core 是唯一业务权威 中做出了关键裁决CLI、Local Web UI 和 Electron Desktop 必须通过稳定 Public API 调用同一 CoreNode Core 负责所有同步、备份、恢复和数据安全规则其他入口只负责各自的交互方式。这个决策带来一个非常清爽的依赖关系完整路线见 vNext 架构基线文档层职责明确禁止React RendererUI、交互、表单、展示直接操作文件、SQLite、shellPreload最小、类型化、白名单 API暴露原始 Electron/Node APIElectron Main窗口、生命周期、安全策略、进程监督执行长时间核心业务Core Utility Process执行 Node Core、进度、取消创建窗口、操作 RendererNode Core所有业务与数据安全规则依赖 Electron、DOM、ReactCLI / Web Adapter参数解析、HTTP、输出格式复制核心业务一句话总结React 负责看见什么、如何交互Electron 负责窗口和桌面能力Node Core 负责数据怎么安全地变。一个核心Node Core 怎么组织Node Core 的业务用例位于packages/core/src/application/每个文件对应一个完整用户操作provider-sync.js —— 同步只对齐 rollout 会话文件与 SQLite 中的 Providerprovider-switch.js —— 切换修改 config 根级 Provider 后复用同步backups.js / restore.js —— 受管备份查询与恢复operation-runtime.js —— Plan 生命周期、并发控制与取消而成熟的存储算法rollout 流式扫描、原地覆盖、SQLite 事务、写入前备份仍保留在根src/目录通过端口层静态接入不为了目录整齐而重写。当前模块归属见 Node Core 当前架构文档。所有入口共享的输入/输出类型则统一放在 packages/contracts/src/dto.ts防止 CLI、Web、Electron 各自理解一套不同的结果结构。写入前的 Plan → Confirm → Apply 模型Core 最重要的安全设计是任何写入都分为 Prepare 和 Apply 两步。读取当前状态 → 生成不可变 Plan → 展示影响范围和警告 → 用户确认 → 重新校验 Revision/Snapshot → 执行写入 → 验证与结果报告Plan 是一个随机不透明 ID默认 TTL 10 分钟、进程内单次消费Apply 时不得盲信几秒前的扫描结果必须重新核对 Profile Revision、config 哈希、文件快照等任一变化就返回STALE_STATE要求用户刷新后重新确认修改前自动创建备份默认保留 2 份无需修改则不备份。这意味着无论你在桌面版点按钮、在浏览器里操作还是用 CLI 脚本执行预览 → 确认 → 落盘的安全路径完全一致。三个入口同一份逻辑三种打开方式入口一Windows 桌面版Electron桌面版是日常双击即用的完整产品支持概览、聊天记录、备份恢复、诊断修复等页面用户无需安装 Node.js。桌面版最值得拆解的是进程结构ADR-0005Renderer (React) → Preload (Typed Bridge) → Main (IPC Router Supervisor) → Utility Process (Core Runtime Host) → Node Core为什么要把 Node Core 放进 Utility Process因为 rollout 扫描、SQLite 操作、备份复制可能长时间运行——放在 Main 会卡住窗口生命周期放在 Renderer 会破坏安全边界。utilityProcess是 Electron 自带的 Node 运行时加载的仍然是同一个codex-provider-sync/core包不是 Sidecar也不是第二套核心。Main 中的 Supervisor 负责懒启动、协议版本握手、请求路由、进度转发、崩溃归类Core 进程崩溃时所有 pending 请求统一归类为CORE_RUNTIME_CRASHED而不是让 UI 假死。核心宿主实现见 apps/desktop/src/runtime/host.tsIPC 路由见 apps/desktop/src/main/ipc-router.ts。安全边界同样严格ADR-0004Renderer 只能通过 Preload 暴露的白名单方法如getStatus、prepareSync、applySync调用核心拿不到fs、sqlite、ipcRenderer等任何原始能力。入口二Local Web UI安装 npm 包后运行codex-provider web默认只监听本机127.0.0.1:8791浏览器完成配对后即可操作适合不想装桌面版的跨平台环境。HTTP 服务端实现src/web-server.js浏览器端入口apps/web/src/main.tsx使用指南Web UI 中文指南Local Web 的 UI 层复用与桌面版相同的 React 应用包HTTP 适配器只负责配对、DTO 映射和路由不解释业务规则。入口三CLI / 脚本 / WSLCLI 是最古老的入口也是 npm 发布包的直接产物npm install -g dailin521/codex-provider-sync codex-provider status codex-provider sync命令入口src/cli.js唯一受支持的 Core 导入面src/public-api.jsCLI 指南与 JSON 输出/退出码约定CLI 中文指南CLI 的特别之处在于它可以在同一进程中连续 Prepare/Apply即预览后直接执行无需等待 UI 确认但消费的仍是同一个 Core Plan 与同一套并发控制。共享 UI一套页面服务两个宿主三个入口共享的还不只是 Core还有界面。packages/app-ui/提供概览、同步、切换、历史、备份恢复等全部页面组件App 根组件Electron Renderer 和 Local Web 分别通过packages/core-client/中的 IPC 客户端 和 HTTP 客户端 接入——UI 代码对请求是走 IPC 还是 HTTP完全无感知。这正是三个入口带来的复利修一个 bug、加一个功能一处改动三个入口同时受益。快速上手从哪开始读这个仓库想做什么去哪里理解总体架构路线docs/VNEXT_ELECTRON_NODE_ARCHITECTURE_ZH.md看当前模块真实归属与约束docs/architecture/NODE_CORE_ARCHITECTURE_ZH.md查架构决策ADR 0001–0046docs/adr/找业务用例实现packages/core/src/application/看桌面进程通信apps/desktop/src/main/ 与 apps/desktop/src/runtime/跑防漂移门禁仓库根目录执行npm run architecture:check与npm test项目根 package.json 采用 npm workspaces 组织apps/*cli、desktop、web与packages/*core、contracts、core-client、app-ui 等依赖方向由 scripts/verify-workspace-boundaries.js 强制校验——core禁止依赖 Electron/React/DOMrenderer禁止依赖node:*从工程层面锁死了架构边界。小结这个架构给中小项目的三条启示让唯一权威写在 ADR 里不是口头约定而是 ADR-0002 这样的正式决策 自动化边界检查防止双核心悄悄复活。把长任务隔离到独立进程Electron Utility Process 方案让窗口永远流畅也让核心崩溃与 UI 崩溃互不牵连。入口只是适配器CLI 解析参数、Web 处理 HTTP、Electron 管理窗口业务规则一处实现、处处一致——选择入口只影响操作方式不影响同步结果。这就是 Codex Provider Sync 的一个核心、三个入口用最少的重复代码交付三种体验一致的产品入口。【免费下载链接】codex-provider-syncSynchronize Codex session provider metadata across rollout files and SQLite state.项目地址: https://gitcode.com/gh_mirrors/co/codex-provider-sync创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考