一个核心、三个入口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），仅供参考
企业数字化 ERP 产品动态
相关推荐
HTTP状态码实战：从理论到生产环境的排查与设计 HTTP 状态码这东西，说穿了就是客户端和服务器之间最朴素的通信语言。一个请求丢过去，对方用三位的数字告诉你是成功、是跳转、是请求有问题、还是服务器自己扛不住了。前面几篇把状态码的分类和语义讲得差不多了，这篇我打算把所有东西拉回真实… · 2026/9/26 20:27:45
Flask+ECharts数据可视化大屏：多页面切换与实时渲染实战 简介：这是一套基于Python与Flask框架构建的轻量级数据可视化大屏展示系统，面向企业数据监控、业务分析场景，也适合作为前端工程化实战练手项目。系统支持多页面切换与实时数据渲染，内置数据看板、空气质量监测、计算机性能指标等模… · 2026/9/26 20:27:45
昇腾Atlas 300V 24G部署YOLOv5：从模型转换到多路视频流实战 去年年初我做视频结构化项目，需要在服务器上跑YOLOv5目标检测，当时手里只有一块消费级显卡，视频路数一多就被压得喘不过气。后来收了一张Atlas 300V 24G，本想着“多一张卡多一路算力”，结果第一次点亮就折腾了整整一个… · 2026/9/26 20:27:38
小白程序员也能入局：大模型应用开发入门与高薪机遇全解析 大模型应用开发需求井喷，薪资高，是传统后端开发者的理想升级路径。文章详细介绍了市场需求、薪资待遇、岗位定义（侧重应用落地而非模型研究）、核心技能栈（Python、LangChain、Hugging Face等）以及后端开发者… · 2026/9/26 21:50:58
小白程序员必看：大模型如何颠覆医疗行业，投资机会全解析 本文深入剖析AI医疗产业链，从基础设施到应用场景，详细拆解AI影像、AI制药等细分赛道的投资价值。文章指出，AI医疗凭借数据密集、知识密集等特点，成为大模型最擅长应用的领域之一，未来十年最具想象力的赛道。同时&#… · 2026/9/26 21:50:44
开源代码审查协议：基于Git+CLI+本地LLM的可审计协作范式 1. 这不是又一个“AI代码审查”玩具，而是一套可嵌入开发流程的开源协作协议你有没有遇到过这样的场景：团队里新同学提交了PR，你点开diff页面，盯着那200行新增代码看了三分钟，心里盘算着——是现在花40分钟逐行写评论&a… · 2026/9/26 21:50:38
Beyond Compare字体优化指南：高分屏下提升代码对比可读性 1. 字体看不清不是小问题：Beyond Compare里那些被忽略的视觉疲劳陷阱刚打开Beyond Compare对比两个JSON配置文件，左边是生产环境的参数，右边是测试环境的——密密麻麻的等号、引号、缩进全挤在一起，眼睛盯了三分钟才确认第47行少了… · 2026/9/26 21:50:31
WPS分类汇总必须先排序：行序驱动的分组原理与避坑指南 简介：本资源是一份面向WPS表格初学者与办公人员的实操型教学文档，聚焦「数据分类汇总」这一高频办公需求，解决日常统计场景中如员工餐费分人汇总、销售数据按区域归总等实际问题。文档以真实订餐管理案例切入，系统讲解分类汇总前必… · 2026/9/26 21:50:31
AI智能体低代码编排：教育场景下的可组装式Agent实践 1. 这不是“造AI”，而是把AI能力拆解成可组装的乐高积木 “央视点赞！南开大学10天造了8000个AI智能体”——这个标题刚刷出来时，我正调试一个需要3周才跑通的RAG流程，第一反应是：这数字是不是漏了个小数点？… · 2026/9/26 21:50:31
数据库课后习题答案别硬背：当测试用例集刷，效率翻倍 简介：万常选版《数据库原理与设计》课后习题答案资源，覆盖第2至6章及第9章，适合正在学习关系模型、数据库建模、关系数据理论与模式求精的本科生、自学者作为复习与自测材料。压缩包共7个文件，含3个doc参考答案、2个sql示例脚本、… · 2026/9/26 0:00:21
OpenClaw 替代品？Hermes Agent 踩坑实录：macOS 飞书接入 TaoToken 配置 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/26 0:00:40
向下兼容与向上兼容：接口设计中的兼容性策略与工程实践 一次版本升级事故，是很多团队绕不过去的坎。线上环境里，服务端明明已经上线了新版接口，老的移动端还在照着旧文档传参数。请求一到网关，校验直接拒绝，用户操作失败，客服群炸了锅，开发群里开始互… · 2026/9/26 0:00:46
