CodexPlusPlus Rust/Tauri 迁移全解从 Python 到 Rust 静默启动器与 Tauri 管理台的分阶段重构实践【免费下载链接】CodexPlusPlusAn enhanced tool for CodexApp, striving to make Codex better to use and more comfortable 一个CodexApp的增强工具努力让Codex变得更好用更舒服项目地址: https://gitcode.com/gh_mirrors/co/CodexPlusPlus本文基于仓库docs/superpowers/plans/2026-05-16-rust-tauri-migration.md编写。该文档是一份完整的工程实施计划共 10 个任务、1000 行本篇文章以它为骨架结合当前仓库中已落地的 Rust 源码进行纵深解读帮助读者理解 CodexPlusPlus 从 Python 后端迁移到 Rust/Tauri 的完整思路、目录设计、接口契约与验证策略。迁移的出发点为什么要把 Python 后端换成 Rust 核心CodexPlusPlus 是一个 CodexApp 增强工具目标是让 Codex 更好用、更舒服。在早期版本中其核心能力CDP 注入、会话删除/撤销、Markdown 导出、Provider 同步、静默启动等由 Python 包codex_session_delete承担。原迁移计划的Goal写得很明确用 Rust 核心core、无窗口静默启动器silent launcher和 Tauri 管理工具management tool替换 Python 后端同时完整保留现有的 Codex App 注入行为。也就是说这次迁移不是功能重写而是行为对等的语言/架构迁移。计划为此定下两条铁律分片可验证verifiable slices在现有 Python 包旁并行构建 Rust workspace每个任务产出的都是可运行、可测试的软件并独立提交。先证明对等、后删除 Python只有当 Rust 行为与 Python 行为验证一致parity proven之后才切换安装入口并移除 Python。整个迁移的最终形态只有两个用户可见入口没有独立的 CLICodex—— 静默启动增强版 CodexCodex 管理工具—— 安装、卸载、更新、设置、日志与诊断的 Tauri 图形管理台。从当前仓库现状看这一迁移已经完成落地根目录 Cargo.toml 已是标准 workspaceresolver 2edition 2024成员为crates/codex-plus-core、crates/codex-plus-data、apps/codex-plus-launcher、apps/codex-plus-manager/src-tauriapps/codex-plus-launcher/src/main.rs已是完整的无窗口启动器crates/codex-plus-core下已积累 60 个功能模块。因此本文既能讲清计划的设计也能对照真实代码讲实现。技术栈选型与核心依赖计划锁定的技术栈如下这些在当前根 Cargo.toml 的[workspace.dependencies]中均可找到对应条目层选型说明语言/工具链Rust 1.95、Cargo workspace、edition 2024workspace 统一管理版本与依赖桌面框架Tauri 2 TypeScript/Vite管理工具前端为 Web 技术栈数据层rusqlitebundled特性SQLite 操作无需系统依赖网络/CDPreqwest、tokio-tungsteniteHTTP 请求与 WebSocketCDP 协议异步运行时tokiomacros、process、rt-multi-thread、time序列化serde/serde_json设置、状态、桥接消息错误处理anyhow、thiserror应用层/库层错误分离系统路径directories各平台数据目录解析打包Windows PowerShell 快捷方式生成、macOS app bundle 生成安装入口行为参考既有renderer-inject.js、既有 pytest 套件迁移期间的行为基准计划中给出的 workspace 根Cargo.toml骨架如下当前仓库在此基础上已扩展出aes-gcm、futures-util、sha2、toml、zip、zstd、winresource等更多依赖说明迁移后期又叠加了加密、压缩与 Windows 资源相关能力[workspace] resolver 2 members [ crates/codex-plus-core, crates/codex-plus-data, apps/codex-plus-launcher, apps/codex-plus-manager/src-tauri, ] [workspace.package] version 1.0.8 edition 2024 license MIT repository https://github.com/BigPizzaV3/CodexPlusPlus [workspace.dependencies] anyhow 1 base64 0.22 directories 6 fs2 0.4 reqwest { version 0.12, features [json, stream, rustls-tls], default-features false } rusqlite { version 0.32, features [bundled] } serde { version 1, features [derive] } serde_json 1 tempfile 3 thiserror 2 tokio { version 1, features [macros, process, rt-multi-thread, time] } tokio-tungstenite { version 0.26, features [rustls-tls-webpki-roots] } url 2 uuid { version 1, features [v4] }注意计划中的版本号1.0.8、MIT许可是当时的快照当前仓库实际为version 1.3.0、license AGPL-3.0-only依赖版本也略有演进但 workspace 结构与成员划分完全一致。计划还建议在.cargo/config.toml中注册两个便捷别名便于日常检查[alias] xtest test --workspace --all-targets xcheck check --workspace --all-targets目录结构workspace 如何承载核心库 数据库 两个入口计划对仓库结构的规划如下当前仓库已按此落地根Cargo.tomlworkspace 根成员位于crates/与apps/crates/codex-plus-core/共享的启动、CDP、桥接、设置、日志、诊断、路径解析、安装/更新原语crates/codex-plus-data/SQLite、备份、Markdown 导出、Provider 同步与文件系统数据操作apps/codex-plus-launcher/Codex快捷方式使用的无窗口静默启动器二进制apps/codex-plus-manager/Codex 管理工具使用的Tauri 管理台含src-tauri与前端src/assets/图标、赞助图与renderer-inject.js注入源文件供 Rust 打包使用tests/fixtures/Rust 集成测试共享的 SQLite、rollout、settings 夹具README.md/README_EN.md替换为 Rust/Tauri 安装与双入口说明setup.bat改为引导管理工具不再调用 Python。对照当前仓库crates/codex-plus-core/src/下确实包含cdp.rs、bridge.rs、settings.rs、status.rs、launcher.rs、ports.rs、proxy.rs、app_paths.rs、install/、update.rs、watcher.rs、routes.rs等全部计划模块crates/codex-plus-data/src/包含backup.rs、storage.rs、markdown.rs、provider_sync.rsassets/inject/renderer-inject.js作为注入脚本的唯一权威源文件保留在 assets/inject 目录。十个任务的分阶段实施路线计划明确每个任务都应产出可运行、可测试的软件并独立提交如果任务在执行中变大先拆子计划再写生产代码。下面按任务逐一解读设计与落地情况。Task 1Rust Workspace 骨架任务目标是搭出四个成员的编译骨架并用两个冒烟测试验证 workspace 链路crates/codex-plus-core仅含lib.rs与version.rs版本号通过env!(CARGO_PKG_VERSION)从 workspace 统一注入pub const VERSION: str env!(CARGO_PKG_VERSION); #[cfg(test)] mod tests { use super::VERSION; #[test] fn exposes_workspace_version() { assert!(!VERSION.is_empty()); } }crates/codex-plus-data仅含crate_ready()占位函数与其测试证明数据 crate 可编译。apps/codex-plus-launcher声明[[bin]] name codex-plus-plusmain.rs通过#[tokio::main]输出Codex launcher {版本}。当前仓库中 apps/codex-plus-launcher/src/main.rs 已从这段骨架演进为完整启动器见 Task 5但二进制名仍是codex-plus-plus。apps/codex-plus-managerpackage.jsontauri dev/tauri build/tsc --noEmit三个脚本、index.html、src/main.tsx最小 React 外壳以及src-tauri的lib.rs第一个 Tauri 命令backend_version与main.rs调用codex_plus_manager_lib::run()。骨架验证命令与提交cargo test --workspace --all-targets git add Cargo.toml .cargo/config.toml crates apps git commit -m feat: add Rust Tauri workspace skeleton计划特别注明若 Tauri context 文件缺失须在同任务内补齐生成的tauri.conf.json与图标后再提交——这正是当前 apps/codex-plus-manager/src-tauri/tauri.conf.json 与icons/目录存在的原因。Task 2共享模型、设置与状态文件本任务把 Python 侧的行为契约用 Rust 类型固化下来关键是serde 字段名必须与现有 JSON 键保持一致保证对等迁移。计划给出了两个方向的测试默认值行为与 Python 一致providerSyncEnabled、cliWrapperEnabled默认关闭cliWrapperApiKeyEnv默认CUSTOM_OPENAI_API_KEY反序列化兼容旧键名旧设置 JSON 中的 camelCase 键如providerSyncEnabled能被直接解析且空字符串的cliWrapperApiKeyEnv会回落到默认环境变量名。对应实现中BackendSettings的 serde 注解模式当前 crates/codex-plus-core/src/settings.rs 沿用了同一套#[serde(rename ..., default)]camelCase 映射只是字段集合已大幅扩展#[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)] pub struct BackendSettings { #[serde(rename providerSyncEnabled, default)] pub provider_sync_enabled: bool, #[serde(rename cliWrapperEnabled, default)] pub cli_wrapper_enabled: bool, #[serde(rename cliWrapperBaseUrl, default)] pub cli_wrapper_base_url: String, #[serde(rename cliWrapperApiKey, default)] pub cli_wrapper_api_key: String, #[serde(rename cliWrapperApiKeyEnv, default default_api_key_env, deserialize_with empty_as_default_api_key_env)] pub cli_wrapper_api_key_env: String, }计划要求SettingsStore提供load/save/update且保存采用临时文件 原子替换atomic temp-file writes的写策略目标路径为~/.codex-session-delete/settings.json避免写一半导致配置损坏。同样地LaunchStatus最新启动状态与StatusStore负责~/.codex-session-delete/latest-status.json的读写字段包括status、message、started_at_ms、debug_port、helper_port、codex_app。当前 crates/codex-plus-core/src/status.rs 正是这一设计的实现apps/codex-plus-launcher/src/main.rs中失败与成功路径都会写入LaunchStatus。本任务还定义了共享业务模型SessionRef、DeleteStatus、DeleteResultpub struct SessionRef { pub session_id: String, pub title: String, } #[serde(rename_all snake_case)] pub enum DeleteStatus { ServerDeleted, LocalDeleted, Partial, Failed, Undone, } pub struct DeleteResult { pub status: DeleteStatus, pub session_id: String, pub message: String, pub undo_token: OptionString, pub backup_path: OptionString, }DeleteResult中的undo_token与backup_path是删除可撤销机制的数据契约删除前先生成备份令牌与备份路径随结果返回/undo路由据此恢复。Task 3数据层对等SQLite、备份、Markdown、Provider 同步本任务把 Python 的数据操作整体移植到codex-plus-datacrate计划明确以四个 pytest 文件为行为参考tests/test_storage_adapter.py tests/test_backup_store.py tests/test_markdown_exporter.py tests/test_provider_sync.py需要覆盖的集成夹具fixture行为包括sessions/messages模式的删除与撤销undothreads模式的删除、相关表清理与 rollout 文件备份工作区移动同时更新 SQLitecwd与 rollout 首行元数据单会话/多会话的排序键sort key查询从 rollout JSONL 导出 MarkdownProvider 同步重写 rollout 首行的model_provider、SQLitethreads.model_provider、has_user_event与cwd。四个核心模块的 API 契约BackupStore与 Python 备份格式保持兼容的 JSON 备份存储提供new、write_backup、read_backup、path_forSQLiteStorageAdapter对接桥接层的数据方法包括delete_local、undo、find_archived_thread_by_title、move_codex_thread_workspace、codex_thread_sort_key、codex_thread_sort_keysmarkdown.rs对照codex_session_delete/markdown_exporter.pyprovider_sync.rs对照codex_session_delete/provider_sync.py并强调三个工程细节用~/.codex/tmp/provider-sync.lock做跨进程互斥变更前先备份可写状态失败时恢复 rollout 首行遇锁占用或 SQLite busy 时返回skipped 而非让启动失败即降级不阻塞策略。当前 crates/codex-plus-data/src 下的backup.rs、storage.rs、markdown.rs、provider_sync.rs与集成测试 crates/codex-plus-data/testsstorage_adapter.rs、provider_sync.rs、markdown.rs即为此任务的产物。启动器主程序中run_provider_sync通过tokio::task::spawn_blocking调用codex_plus_data::run_provider_sync(None)并用ProviderSyncStatus::Synced判定同步是否真正完成与计划启动前执行 Provider 同步的生命周期一致。Task 4CDP 桥接与注入运行时这是保留现有 Codex App 注入行为的核心任务。CodexElectron 应用以--remote-debugging-port暴露 Chrome DevTools ProtocolCDP端点Rust 侧通过 WebSocket 向其注入renderer-inject.js并在页面与 Rust 后端之间架起桥。计划要求桥接脚本在页面侧定义四个全局符号window.__codexSessionDeleteBridge window.__codexSessionDeleteResolve window.__codexSessionDeleteReject codexSessionDeleteV2注入前缀须包含两个标记window.__CODEX_SESSION_DELETE_HELPER__ window.__CODEX_PLUS_SPONSOR_IMAGES__CDP 实现分三层目标发现list_targets(debug_port)拉取http://127.0.0.1:{port}/json/listpick_page_target优先选择标题或 URL 含codex的页面目标否则回退到第一个 page target。协议调用通过 WebSocket 依次执行Runtime.enable、Runtime.removeBinding、Runtime.addBinding、Page.addScriptToEvaluateOnNewDocument、Runtime.evaluate。桥接循环接收Runtime.bindingCalled事件解析(path, payload)路由到 Rust 处理器再通过 evaluate 执行 resolve/reject 表达式把结果送回页面 Promise。资产加载用include_str!/include_bytes!把注入 JS 与赞助图编译进二进制计划特别强调迁移期间注入 JS 只保留一个权威文件路径即 assets/inject/renderer-inject.js避免资产漂移asset drift。当前 crates/codex-plus-core/src/cdp.rs、crates/codex-plus-core/src/bridge.rs、crates/codex-plus-core/src/assets.rs 即为落地模块对应测试见 crates/codex-plus-core/tests/cdp_bridge.rs。Task 5静默启动器运行时本任务把启动器从打印版本升级为完整启动生命周期。新增模块app_paths.rsCodex 应用路径解析、ports.rs回环端口选择、proxy.rs代理自动探测、launcher.rs启动编排。参考的 Python 测试为test_app_paths.py、test_launcher_cli.py、test_cdp.py。关键点路径解析Windows 识别打包版 Codex 可执行文件路径macOS 根据.app构造可执行文件支持--app-path覆盖。代理端口保留自动探测端口列表固定为7897, 7890, 10809, 10808, 1080并把探测结果注入 Codex 进程环境。Windows 打包应用激活activate_packaged_app使用 Rust Windows API 实现以cfg(windows)保护测试只验证命令构造不依赖真实打包应用。启动生命周期launch_and_inject(options) - LaunchHandle按序完成选端口 → 加载设置 → 若启用则执行 Provider 同步 → 启动 helper/桥接运行时 → 启动 Codex →重试注入→ 成败均写最新状态 → Codex 退出时关闭 helper 资源。启动器二进制在 Windows release 下配置为无控制台窗口。当前 apps/codex-plus-launcher/src/main.rs 首行正是#![cfg_attr(windows, windows_subsystem windows)]且实现了远比计划更细的运行时行为支持--helper-only只跑桥接 helper 服务、--app-path、--debug-port、--helper-port参数通过acquire_resilient_loopback_port_guard获取单实例守卫端口若已有实例运行则转而激活已存在的 Codex 窗口activate_existing_codex_app并写入Existing Codex instance activated状态而不是再启一份对WouldBlock/AddrInUse错误做 stale recovery检查 Codex 进程与 CDP 监听状态判断是否回收僵死 launcher启动失败写入diagnostic_log与LaunchStatus { status: failed }启动成功后异步检查更新notify_manager_when_update_available有新版时以--show-update拉起管理工具启动期间同步 Dream Skin 基础主题、Native Browser 兼容监视器、Remote Control 会话恢复等增强能力。这些细节说明迁移计划交付的是行为骨架后续迭代在 Rust 生态内继续演进而计划的模块划分与接口契约LaunchOptions、LaunchHooks、launch_and_inject始终被遵守。Task 6桥接路由对等routes.rs实现类型化分发器计划给出完整路由清单/settings/get /settings/set /user-scripts/list /user-scripts/set-enabled /user-scripts/set-script-enabled /user-scripts/reload /devtools/open /backend/status /backend/repair /ads /delete /undo /export-markdown /archived-thread /move-thread-workspace /thread-sort-key /thread-sort-keys分发器签名与未知路由的兜底响应是硬契约pub async fn handle_bridge_request( ctx: BridgeContext, path: str, payload: serde_json::Value, ) - serde_json::Value;{status:failed,session_id:,message:Unknown bridge path}当前 crates/codex-plus-core/src/routes.rs 中BridgeContext由三个 trait 对象组装——BridgeSettingsService设置读写、BridgeRuntimeService用户脚本、DevTools、管理台、广告、模型目录、Zed Remote、Upstream Worktree 等运行时能力、BridgeDataService删除/撤销/Markdown 导出/归档线程查找/会话共享。handle_bridge_request每次请求都会先写bridge.request诊断日志记录 path 与 payload 键名再按路由分发。路由清单在实现中还扩展了会话导入导出/session-export、/session-import对应session_share.rs与远程控制恢复等新能力。Task 7Tauri 管理控制台管理台由前端TypeScript/Vite/React与src-tauri两部分组成。计划要求的 Tauri 命令backend_version load_overview launch_codex_plus load_settings save_settings install_entrypoints uninstall_entrypoints repair_shortcuts check_update perform_update read_latest_logs copy_diagnostics reset_settings每个命令返回{ status, message, ...payload }结构的可序列化结果。当前 apps/codex-plus-manager/src-tauri/src/commands.rs 中定义了泛型CommandResultTstatusmessage#[serde(flatten)] payload与OverviewPayloadcodex_app、silent_shortcut、management_shortcut的PathState、latest_launch、current_version、update_status等并已将命令集扩展至百余个新增 Dream Skin 市场/社区、微信连接、Provider 导入、Grok 配置、Zed Remote、VLM 测试等。管理台的 UI 要求非常具体值得作为桌面运维工具的设计参考左侧导航Overview / Launch / Install / Update / Settings / Logs / Diagnostics布局纪律紧凑的操作型布局不做落地页 hero 构图卡片不嵌套卡片控件密集且可预期Overview 面板Codex 应用存在性、静默快捷方式、管理快捷方式、最近启动状态、当前版本、更新状态以及快速动作启动、修复快捷方式、打开日志Launch 页手动启动、应用路径覆盖、debug/helper 端口字段、后端修复Install 页安装、卸载、修复快捷方式、可选删除自有数据Update 页检查更新、发布摘要、进度、安装更新Settings 页Provider 同步、Codex 命令包装器设置、用户脚本摘要Logs 页最新日志查看器刷新 复制Diagnostics 页生成诊断报告并复制。当前 apps/codex-plus-manager/src-tauri/src/lib.rs 还实现了托盘tray菜单显示主窗口 / 应用 Dream Skin / 退出、主窗口1180x820最小960x720、manager-navigation-requested事件等前端源码位于 apps/codex-plus-manager/src其中App.tsx与components/目录承载了上述导航与页面。验证命令cd apps/codex-plus-manager npm install npm run check npm run buildTask 8安装、卸载、更新与守护watcher的 Rust 化平台安装器是迁移的最后一公里。Windows生成两个快捷方式Codex.lnk指向codex-plus-plus.exeCodex 管理工具.lnk指向codex-plus-plus-manager.exe与一条卸载注册表项macOS生成两个 app bundle——/Applications/Codex.app静默启动无窗口 launcher与/Applications/Codex 管理工具.app启动 Tauri 管理台更新器移植 GitHub Release 检查、版本解析、资产选择、下载与安装编排且只通过 Tauri 命令暴露不提供 CLIwatcher移植原有 watcher 行为让管理 UI 可以安装/移除/启用/禁用它同样不设独立 CLI。计划强调测试须验证脚本/元数据内容而非真实安装例如生成的 Windows 快捷方式脚本必须同时包含Codex.lnk与Codex 管理工具.lnkmacOS bundle 元数据须同时包含Codex.app与Codex 管理工具.app。当前实现见 crates/codex-plus-core/src/installmod.rs、windows.rs、macos.rs、crates/codex-plus-core/src/update.rs、crates/codex-plus-core/src/watcher.rs测试见 crates/codex-plus-core/tests/installers.rs 与 crates/codex-plus-core/tests/updater.rs。Task 9切换运行时资产与文档README 改为双入口用法双击 Codex静默启动增强版 Codex。 双击 Codex 管理工具安装、卸载、更新、设置、日志和诊断。删除对旧命令的引用python -m codex_session_delete launch/setup/updatesetup.bat改为打开或安装 Rust/Tauri 管理工具不再调用 Python 模块发布文档列明四个产物codex-plus-plus.exe、codex-plus-plus-manager.exe、Codex.app、Codex 管理工具.app文档回归测试保留为 pytestpython -m pytest -q tests/test_readme.py tests/test_setup_bat.py。Task 10Python 移除门禁这是迁移的收尾闸门全部通过后才允许删除 Python完整 Rust 验证cargo test --workspace --all-targetsnpm run checknpm run build剩余 Python 文档测试通过或先替换为 Rust/Node 等价测试手工冒烟清单Codex快捷方式启动 Codex 且不打开管理 UICodex App 内显示 Codex 注入菜单注入 UI 中 delete / undo / export / move / settings 路由均可用Codex 管理工具打开并显示 Overview 状态管理工具可修复快捷方式、读取最新日志更新检查在 mock 或真实 release 元数据下可用删除codex_session_delete/、pyproject.toml与仅验证 Python 内部的测试提交chore: remove Python backend after Rust migration。从计划到现状迁移的落地验证与演进结合当前仓库可以确认计划的每个任务都已有对应产出且在其接口契约上继续生长workspace 骨架根 Cargo.toml 四个成员与计划一致版本已演进到1.3.0共享模型/设置/状态crates/codex-plus-core/src/settings.rs 的 camelCase serde 映射、crates/codex-plus-core/src/status.rs 的LaunchStatus与StatusStore均已落地设置域还扩展出 RelayProfile、聚合中继等新配置数据层crates/codex-plus-data/src 四个模块齐备launcher 通过spawn_blocking调用以避免阻塞异步运行时CDP/桥接crates/codex-plus-core/src/cdp.rs、bridge.rs、assets.rs 与注入资产 assets/inject/renderer-inject.js 保持单一权威源静默启动器apps/codex-plus-launcher/src/main.rs 已实现单实例守卫、陈旧实例回收、失败诊断、更新提示、增强能力联动等完整运行时路由crates/codex-plus-core/src/routes.rs 的BridgeContextsettings/runtime/data 三服务与handle_bridge_request即为计划分发器的实现且扩展了会话共享、远程控制恢复等路由管理台apps/codex-plus-manager/src-tauri 的命令集、Overview 结构、托盘与导航事件均已实现前端在 apps/codex-plus-manager/src安装/更新/watchercrates/codex-plus-core/src/install、update.rs、watcher.rs 与配套测试齐全。计划自带的 Self-Review 也给出了两条质量准则值得任何大型语言迁移项目沿用Spec coverage计划覆盖 Rust 核心、数据操作、CDP 桥、静默启动器、Tauri 管理台、双桌面入口、安装/卸载/更新、watcher、文档、验证与 Python 移除全链路无占位符不留TODO/TBD宽泛任务必须指明确切文件、参考测试、预期 API 与验证命令命名一致性始终使用codex-plus-launcher表示无窗口启动器不引入独立的用户可见 CLI。结语一份可复用的行为对等迁移模板CodexPlusPlus 的 Rust/Tauri 迁移计划最有价值的地方不在于换成更快的语言而在于它的方法论在旧实现旁并行搭建新 workspace以既有测试套件为行为基准按骨架 → 数据 → 桥接 → 启动 → 路由 → UI → 安装 → 文档 → 移除的顺序分十步推进每一步都可编译、可测试、可独立提交最终以全量验证 手工冒烟清单作为删除 Python 的硬门禁。对于任何打算把 Python/Node 原型迁移到 Rust Tauri 的桌面工具项目这份计划的模块划分core / data / launcher / manager、接口契约serde 键名兼容、路由兜底、原子写状态文件与验证策略fixture 对等、锁降级、门禁清单都可以直接套用。而当前仓库的代码现状则证明按照这样的计划执行是可以真正落地、并在其上继续长出更丰富功能的。【免费下载链接】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 Rust/Tauri 迁移全解：从 Python 到 Rust 静默启动器与 Tauri 管理台的分阶段重构实践
CodexPlusPlus Rust/Tauri 迁移全解从 Python 到 Rust 静默启动器与 Tauri 管理台的分阶段重构实践【免费下载链接】CodexPlusPlusAn enhanced tool for CodexApp, striving to make Codex better to use and more comfortable 一个CodexApp的增强工具努力让Codex变得更好用更舒服项目地址: https://gitcode.com/gh_mirrors/co/CodexPlusPlus本文基于仓库docs/superpowers/plans/2026-05-16-rust-tauri-migration.md编写。该文档是一份完整的工程实施计划共 10 个任务、1000 行本篇文章以它为骨架结合当前仓库中已落地的 Rust 源码进行纵深解读帮助读者理解 CodexPlusPlus 从 Python 后端迁移到 Rust/Tauri 的完整思路、目录设计、接口契约与验证策略。迁移的出发点为什么要把 Python 后端换成 Rust 核心CodexPlusPlus 是一个 CodexApp 增强工具目标是让 Codex 更好用、更舒服。在早期版本中其核心能力CDP 注入、会话删除/撤销、Markdown 导出、Provider 同步、静默启动等由 Python 包codex_session_delete承担。原迁移计划的Goal写得很明确用 Rust 核心core、无窗口静默启动器silent launcher和 Tauri 管理工具management tool替换 Python 后端同时完整保留现有的 Codex App 注入行为。也就是说这次迁移不是功能重写而是行为对等的语言/架构迁移。计划为此定下两条铁律分片可验证verifiable slices在现有 Python 包旁并行构建 Rust workspace每个任务产出的都是可运行、可测试的软件并独立提交。先证明对等、后删除 Python只有当 Rust 行为与 Python 行为验证一致parity proven之后才切换安装入口并移除 Python。整个迁移的最终形态只有两个用户可见入口没有独立的 CLICodex—— 静默启动增强版 CodexCodex 管理工具—— 安装、卸载、更新、设置、日志与诊断的 Tauri 图形管理台。从当前仓库现状看这一迁移已经完成落地根目录 Cargo.toml 已是标准 workspaceresolver 2edition 2024成员为crates/codex-plus-core、crates/codex-plus-data、apps/codex-plus-launcher、apps/codex-plus-manager/src-tauriapps/codex-plus-launcher/src/main.rs已是完整的无窗口启动器crates/codex-plus-core下已积累 60 个功能模块。因此本文既能讲清计划的设计也能对照真实代码讲实现。技术栈选型与核心依赖计划锁定的技术栈如下这些在当前根 Cargo.toml 的[workspace.dependencies]中均可找到对应条目层选型说明语言/工具链Rust 1.95、Cargo workspace、edition 2024workspace 统一管理版本与依赖桌面框架Tauri 2 TypeScript/Vite管理工具前端为 Web 技术栈数据层rusqlitebundled特性SQLite 操作无需系统依赖网络/CDPreqwest、tokio-tungsteniteHTTP 请求与 WebSocketCDP 协议异步运行时tokiomacros、process、rt-multi-thread、time序列化serde/serde_json设置、状态、桥接消息错误处理anyhow、thiserror应用层/库层错误分离系统路径directories各平台数据目录解析打包Windows PowerShell 快捷方式生成、macOS app bundle 生成安装入口行为参考既有renderer-inject.js、既有 pytest 套件迁移期间的行为基准计划中给出的 workspace 根Cargo.toml骨架如下当前仓库在此基础上已扩展出aes-gcm、futures-util、sha2、toml、zip、zstd、winresource等更多依赖说明迁移后期又叠加了加密、压缩与 Windows 资源相关能力[workspace] resolver 2 members [ crates/codex-plus-core, crates/codex-plus-data, apps/codex-plus-launcher, apps/codex-plus-manager/src-tauri, ] [workspace.package] version 1.0.8 edition 2024 license MIT repository https://github.com/BigPizzaV3/CodexPlusPlus [workspace.dependencies] anyhow 1 base64 0.22 directories 6 fs2 0.4 reqwest { version 0.12, features [json, stream, rustls-tls], default-features false } rusqlite { version 0.32, features [bundled] } serde { version 1, features [derive] } serde_json 1 tempfile 3 thiserror 2 tokio { version 1, features [macros, process, rt-multi-thread, time] } tokio-tungstenite { version 0.26, features [rustls-tls-webpki-roots] } url 2 uuid { version 1, features [v4] }注意计划中的版本号1.0.8、MIT许可是当时的快照当前仓库实际为version 1.3.0、license AGPL-3.0-only依赖版本也略有演进但 workspace 结构与成员划分完全一致。计划还建议在.cargo/config.toml中注册两个便捷别名便于日常检查[alias] xtest test --workspace --all-targets xcheck check --workspace --all-targets目录结构workspace 如何承载核心库 数据库 两个入口计划对仓库结构的规划如下当前仓库已按此落地根Cargo.tomlworkspace 根成员位于crates/与apps/crates/codex-plus-core/共享的启动、CDP、桥接、设置、日志、诊断、路径解析、安装/更新原语crates/codex-plus-data/SQLite、备份、Markdown 导出、Provider 同步与文件系统数据操作apps/codex-plus-launcher/Codex快捷方式使用的无窗口静默启动器二进制apps/codex-plus-manager/Codex 管理工具使用的Tauri 管理台含src-tauri与前端src/assets/图标、赞助图与renderer-inject.js注入源文件供 Rust 打包使用tests/fixtures/Rust 集成测试共享的 SQLite、rollout、settings 夹具README.md/README_EN.md替换为 Rust/Tauri 安装与双入口说明setup.bat改为引导管理工具不再调用 Python。对照当前仓库crates/codex-plus-core/src/下确实包含cdp.rs、bridge.rs、settings.rs、status.rs、launcher.rs、ports.rs、proxy.rs、app_paths.rs、install/、update.rs、watcher.rs、routes.rs等全部计划模块crates/codex-plus-data/src/包含backup.rs、storage.rs、markdown.rs、provider_sync.rsassets/inject/renderer-inject.js作为注入脚本的唯一权威源文件保留在 assets/inject 目录。十个任务的分阶段实施路线计划明确每个任务都应产出可运行、可测试的软件并独立提交如果任务在执行中变大先拆子计划再写生产代码。下面按任务逐一解读设计与落地情况。Task 1Rust Workspace 骨架任务目标是搭出四个成员的编译骨架并用两个冒烟测试验证 workspace 链路crates/codex-plus-core仅含lib.rs与version.rs版本号通过env!(CARGO_PKG_VERSION)从 workspace 统一注入pub const VERSION: str env!(CARGO_PKG_VERSION); #[cfg(test)] mod tests { use super::VERSION; #[test] fn exposes_workspace_version() { assert!(!VERSION.is_empty()); } }crates/codex-plus-data仅含crate_ready()占位函数与其测试证明数据 crate 可编译。apps/codex-plus-launcher声明[[bin]] name codex-plus-plusmain.rs通过#[tokio::main]输出Codex launcher {版本}。当前仓库中 apps/codex-plus-launcher/src/main.rs 已从这段骨架演进为完整启动器见 Task 5但二进制名仍是codex-plus-plus。apps/codex-plus-managerpackage.jsontauri dev/tauri build/tsc --noEmit三个脚本、index.html、src/main.tsx最小 React 外壳以及src-tauri的lib.rs第一个 Tauri 命令backend_version与main.rs调用codex_plus_manager_lib::run()。骨架验证命令与提交cargo test --workspace --all-targets git add Cargo.toml .cargo/config.toml crates apps git commit -m feat: add Rust Tauri workspace skeleton计划特别注明若 Tauri context 文件缺失须在同任务内补齐生成的tauri.conf.json与图标后再提交——这正是当前 apps/codex-plus-manager/src-tauri/tauri.conf.json 与icons/目录存在的原因。Task 2共享模型、设置与状态文件本任务把 Python 侧的行为契约用 Rust 类型固化下来关键是serde 字段名必须与现有 JSON 键保持一致保证对等迁移。计划给出了两个方向的测试默认值行为与 Python 一致providerSyncEnabled、cliWrapperEnabled默认关闭cliWrapperApiKeyEnv默认CUSTOM_OPENAI_API_KEY反序列化兼容旧键名旧设置 JSON 中的 camelCase 键如providerSyncEnabled能被直接解析且空字符串的cliWrapperApiKeyEnv会回落到默认环境变量名。对应实现中BackendSettings的 serde 注解模式当前 crates/codex-plus-core/src/settings.rs 沿用了同一套#[serde(rename ..., default)]camelCase 映射只是字段集合已大幅扩展#[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)] pub struct BackendSettings { #[serde(rename providerSyncEnabled, default)] pub provider_sync_enabled: bool, #[serde(rename cliWrapperEnabled, default)] pub cli_wrapper_enabled: bool, #[serde(rename cliWrapperBaseUrl, default)] pub cli_wrapper_base_url: String, #[serde(rename cliWrapperApiKey, default)] pub cli_wrapper_api_key: String, #[serde(rename cliWrapperApiKeyEnv, default default_api_key_env, deserialize_with empty_as_default_api_key_env)] pub cli_wrapper_api_key_env: String, }计划要求SettingsStore提供load/save/update且保存采用临时文件 原子替换atomic temp-file writes的写策略目标路径为~/.codex-session-delete/settings.json避免写一半导致配置损坏。同样地LaunchStatus最新启动状态与StatusStore负责~/.codex-session-delete/latest-status.json的读写字段包括status、message、started_at_ms、debug_port、helper_port、codex_app。当前 crates/codex-plus-core/src/status.rs 正是这一设计的实现apps/codex-plus-launcher/src/main.rs中失败与成功路径都会写入LaunchStatus。本任务还定义了共享业务模型SessionRef、DeleteStatus、DeleteResultpub struct SessionRef { pub session_id: String, pub title: String, } #[serde(rename_all snake_case)] pub enum DeleteStatus { ServerDeleted, LocalDeleted, Partial, Failed, Undone, } pub struct DeleteResult { pub status: DeleteStatus, pub session_id: String, pub message: String, pub undo_token: OptionString, pub backup_path: OptionString, }DeleteResult中的undo_token与backup_path是删除可撤销机制的数据契约删除前先生成备份令牌与备份路径随结果返回/undo路由据此恢复。Task 3数据层对等SQLite、备份、Markdown、Provider 同步本任务把 Python 的数据操作整体移植到codex-plus-datacrate计划明确以四个 pytest 文件为行为参考tests/test_storage_adapter.py tests/test_backup_store.py tests/test_markdown_exporter.py tests/test_provider_sync.py需要覆盖的集成夹具fixture行为包括sessions/messages模式的删除与撤销undothreads模式的删除、相关表清理与 rollout 文件备份工作区移动同时更新 SQLitecwd与 rollout 首行元数据单会话/多会话的排序键sort key查询从 rollout JSONL 导出 MarkdownProvider 同步重写 rollout 首行的model_provider、SQLitethreads.model_provider、has_user_event与cwd。四个核心模块的 API 契约BackupStore与 Python 备份格式保持兼容的 JSON 备份存储提供new、write_backup、read_backup、path_forSQLiteStorageAdapter对接桥接层的数据方法包括delete_local、undo、find_archived_thread_by_title、move_codex_thread_workspace、codex_thread_sort_key、codex_thread_sort_keysmarkdown.rs对照codex_session_delete/markdown_exporter.pyprovider_sync.rs对照codex_session_delete/provider_sync.py并强调三个工程细节用~/.codex/tmp/provider-sync.lock做跨进程互斥变更前先备份可写状态失败时恢复 rollout 首行遇锁占用或 SQLite busy 时返回skipped 而非让启动失败即降级不阻塞策略。当前 crates/codex-plus-data/src 下的backup.rs、storage.rs、markdown.rs、provider_sync.rs与集成测试 crates/codex-plus-data/testsstorage_adapter.rs、provider_sync.rs、markdown.rs即为此任务的产物。启动器主程序中run_provider_sync通过tokio::task::spawn_blocking调用codex_plus_data::run_provider_sync(None)并用ProviderSyncStatus::Synced判定同步是否真正完成与计划启动前执行 Provider 同步的生命周期一致。Task 4CDP 桥接与注入运行时这是保留现有 Codex App 注入行为的核心任务。CodexElectron 应用以--remote-debugging-port暴露 Chrome DevTools ProtocolCDP端点Rust 侧通过 WebSocket 向其注入renderer-inject.js并在页面与 Rust 后端之间架起桥。计划要求桥接脚本在页面侧定义四个全局符号window.__codexSessionDeleteBridge window.__codexSessionDeleteResolve window.__codexSessionDeleteReject codexSessionDeleteV2注入前缀须包含两个标记window.__CODEX_SESSION_DELETE_HELPER__ window.__CODEX_PLUS_SPONSOR_IMAGES__CDP 实现分三层目标发现list_targets(debug_port)拉取http://127.0.0.1:{port}/json/listpick_page_target优先选择标题或 URL 含codex的页面目标否则回退到第一个 page target。协议调用通过 WebSocket 依次执行Runtime.enable、Runtime.removeBinding、Runtime.addBinding、Page.addScriptToEvaluateOnNewDocument、Runtime.evaluate。桥接循环接收Runtime.bindingCalled事件解析(path, payload)路由到 Rust 处理器再通过 evaluate 执行 resolve/reject 表达式把结果送回页面 Promise。资产加载用include_str!/include_bytes!把注入 JS 与赞助图编译进二进制计划特别强调迁移期间注入 JS 只保留一个权威文件路径即 assets/inject/renderer-inject.js避免资产漂移asset drift。当前 crates/codex-plus-core/src/cdp.rs、crates/codex-plus-core/src/bridge.rs、crates/codex-plus-core/src/assets.rs 即为落地模块对应测试见 crates/codex-plus-core/tests/cdp_bridge.rs。Task 5静默启动器运行时本任务把启动器从打印版本升级为完整启动生命周期。新增模块app_paths.rsCodex 应用路径解析、ports.rs回环端口选择、proxy.rs代理自动探测、launcher.rs启动编排。参考的 Python 测试为test_app_paths.py、test_launcher_cli.py、test_cdp.py。关键点路径解析Windows 识别打包版 Codex 可执行文件路径macOS 根据.app构造可执行文件支持--app-path覆盖。代理端口保留自动探测端口列表固定为7897, 7890, 10809, 10808, 1080并把探测结果注入 Codex 进程环境。Windows 打包应用激活activate_packaged_app使用 Rust Windows API 实现以cfg(windows)保护测试只验证命令构造不依赖真实打包应用。启动生命周期launch_and_inject(options) - LaunchHandle按序完成选端口 → 加载设置 → 若启用则执行 Provider 同步 → 启动 helper/桥接运行时 → 启动 Codex →重试注入→ 成败均写最新状态 → Codex 退出时关闭 helper 资源。启动器二进制在 Windows release 下配置为无控制台窗口。当前 apps/codex-plus-launcher/src/main.rs 首行正是#![cfg_attr(windows, windows_subsystem windows)]且实现了远比计划更细的运行时行为支持--helper-only只跑桥接 helper 服务、--app-path、--debug-port、--helper-port参数通过acquire_resilient_loopback_port_guard获取单实例守卫端口若已有实例运行则转而激活已存在的 Codex 窗口activate_existing_codex_app并写入Existing Codex instance activated状态而不是再启一份对WouldBlock/AddrInUse错误做 stale recovery检查 Codex 进程与 CDP 监听状态判断是否回收僵死 launcher启动失败写入diagnostic_log与LaunchStatus { status: failed }启动成功后异步检查更新notify_manager_when_update_available有新版时以--show-update拉起管理工具启动期间同步 Dream Skin 基础主题、Native Browser 兼容监视器、Remote Control 会话恢复等增强能力。这些细节说明迁移计划交付的是行为骨架后续迭代在 Rust 生态内继续演进而计划的模块划分与接口契约LaunchOptions、LaunchHooks、launch_and_inject始终被遵守。Task 6桥接路由对等routes.rs实现类型化分发器计划给出完整路由清单/settings/get /settings/set /user-scripts/list /user-scripts/set-enabled /user-scripts/set-script-enabled /user-scripts/reload /devtools/open /backend/status /backend/repair /ads /delete /undo /export-markdown /archived-thread /move-thread-workspace /thread-sort-key /thread-sort-keys分发器签名与未知路由的兜底响应是硬契约pub async fn handle_bridge_request( ctx: BridgeContext, path: str, payload: serde_json::Value, ) - serde_json::Value;{status:failed,session_id:,message:Unknown bridge path}当前 crates/codex-plus-core/src/routes.rs 中BridgeContext由三个 trait 对象组装——BridgeSettingsService设置读写、BridgeRuntimeService用户脚本、DevTools、管理台、广告、模型目录、Zed Remote、Upstream Worktree 等运行时能力、BridgeDataService删除/撤销/Markdown 导出/归档线程查找/会话共享。handle_bridge_request每次请求都会先写bridge.request诊断日志记录 path 与 payload 键名再按路由分发。路由清单在实现中还扩展了会话导入导出/session-export、/session-import对应session_share.rs与远程控制恢复等新能力。Task 7Tauri 管理控制台管理台由前端TypeScript/Vite/React与src-tauri两部分组成。计划要求的 Tauri 命令backend_version load_overview launch_codex_plus load_settings save_settings install_entrypoints uninstall_entrypoints repair_shortcuts check_update perform_update read_latest_logs copy_diagnostics reset_settings每个命令返回{ status, message, ...payload }结构的可序列化结果。当前 apps/codex-plus-manager/src-tauri/src/commands.rs 中定义了泛型CommandResultTstatusmessage#[serde(flatten)] payload与OverviewPayloadcodex_app、silent_shortcut、management_shortcut的PathState、latest_launch、current_version、update_status等并已将命令集扩展至百余个新增 Dream Skin 市场/社区、微信连接、Provider 导入、Grok 配置、Zed Remote、VLM 测试等。管理台的 UI 要求非常具体值得作为桌面运维工具的设计参考左侧导航Overview / Launch / Install / Update / Settings / Logs / Diagnostics布局纪律紧凑的操作型布局不做落地页 hero 构图卡片不嵌套卡片控件密集且可预期Overview 面板Codex 应用存在性、静默快捷方式、管理快捷方式、最近启动状态、当前版本、更新状态以及快速动作启动、修复快捷方式、打开日志Launch 页手动启动、应用路径覆盖、debug/helper 端口字段、后端修复Install 页安装、卸载、修复快捷方式、可选删除自有数据Update 页检查更新、发布摘要、进度、安装更新Settings 页Provider 同步、Codex 命令包装器设置、用户脚本摘要Logs 页最新日志查看器刷新 复制Diagnostics 页生成诊断报告并复制。当前 apps/codex-plus-manager/src-tauri/src/lib.rs 还实现了托盘tray菜单显示主窗口 / 应用 Dream Skin / 退出、主窗口1180x820最小960x720、manager-navigation-requested事件等前端源码位于 apps/codex-plus-manager/src其中App.tsx与components/目录承载了上述导航与页面。验证命令cd apps/codex-plus-manager npm install npm run check npm run buildTask 8安装、卸载、更新与守护watcher的 Rust 化平台安装器是迁移的最后一公里。Windows生成两个快捷方式Codex.lnk指向codex-plus-plus.exeCodex 管理工具.lnk指向codex-plus-plus-manager.exe与一条卸载注册表项macOS生成两个 app bundle——/Applications/Codex.app静默启动无窗口 launcher与/Applications/Codex 管理工具.app启动 Tauri 管理台更新器移植 GitHub Release 检查、版本解析、资产选择、下载与安装编排且只通过 Tauri 命令暴露不提供 CLIwatcher移植原有 watcher 行为让管理 UI 可以安装/移除/启用/禁用它同样不设独立 CLI。计划强调测试须验证脚本/元数据内容而非真实安装例如生成的 Windows 快捷方式脚本必须同时包含Codex.lnk与Codex 管理工具.lnkmacOS bundle 元数据须同时包含Codex.app与Codex 管理工具.app。当前实现见 crates/codex-plus-core/src/installmod.rs、windows.rs、macos.rs、crates/codex-plus-core/src/update.rs、crates/codex-plus-core/src/watcher.rs测试见 crates/codex-plus-core/tests/installers.rs 与 crates/codex-plus-core/tests/updater.rs。Task 9切换运行时资产与文档README 改为双入口用法双击 Codex静默启动增强版 Codex。 双击 Codex 管理工具安装、卸载、更新、设置、日志和诊断。删除对旧命令的引用python -m codex_session_delete launch/setup/updatesetup.bat改为打开或安装 Rust/Tauri 管理工具不再调用 Python 模块发布文档列明四个产物codex-plus-plus.exe、codex-plus-plus-manager.exe、Codex.app、Codex 管理工具.app文档回归测试保留为 pytestpython -m pytest -q tests/test_readme.py tests/test_setup_bat.py。Task 10Python 移除门禁这是迁移的收尾闸门全部通过后才允许删除 Python完整 Rust 验证cargo test --workspace --all-targetsnpm run checknpm run build剩余 Python 文档测试通过或先替换为 Rust/Node 等价测试手工冒烟清单Codex快捷方式启动 Codex 且不打开管理 UICodex App 内显示 Codex 注入菜单注入 UI 中 delete / undo / export / move / settings 路由均可用Codex 管理工具打开并显示 Overview 状态管理工具可修复快捷方式、读取最新日志更新检查在 mock 或真实 release 元数据下可用删除codex_session_delete/、pyproject.toml与仅验证 Python 内部的测试提交chore: remove Python backend after Rust migration。从计划到现状迁移的落地验证与演进结合当前仓库可以确认计划的每个任务都已有对应产出且在其接口契约上继续生长workspace 骨架根 Cargo.toml 四个成员与计划一致版本已演进到1.3.0共享模型/设置/状态crates/codex-plus-core/src/settings.rs 的 camelCase serde 映射、crates/codex-plus-core/src/status.rs 的LaunchStatus与StatusStore均已落地设置域还扩展出 RelayProfile、聚合中继等新配置数据层crates/codex-plus-data/src 四个模块齐备launcher 通过spawn_blocking调用以避免阻塞异步运行时CDP/桥接crates/codex-plus-core/src/cdp.rs、bridge.rs、assets.rs 与注入资产 assets/inject/renderer-inject.js 保持单一权威源静默启动器apps/codex-plus-launcher/src/main.rs 已实现单实例守卫、陈旧实例回收、失败诊断、更新提示、增强能力联动等完整运行时路由crates/codex-plus-core/src/routes.rs 的BridgeContextsettings/runtime/data 三服务与handle_bridge_request即为计划分发器的实现且扩展了会话共享、远程控制恢复等路由管理台apps/codex-plus-manager/src-tauri 的命令集、Overview 结构、托盘与导航事件均已实现前端在 apps/codex-plus-manager/src安装/更新/watchercrates/codex-plus-core/src/install、update.rs、watcher.rs 与配套测试齐全。计划自带的 Self-Review 也给出了两条质量准则值得任何大型语言迁移项目沿用Spec coverage计划覆盖 Rust 核心、数据操作、CDP 桥、静默启动器、Tauri 管理台、双桌面入口、安装/卸载/更新、watcher、文档、验证与 Python 移除全链路无占位符不留TODO/TBD宽泛任务必须指明确切文件、参考测试、预期 API 与验证命令命名一致性始终使用codex-plus-launcher表示无窗口启动器不引入独立的用户可见 CLI。结语一份可复用的行为对等迁移模板CodexPlusPlus 的 Rust/Tauri 迁移计划最有价值的地方不在于换成更快的语言而在于它的方法论在旧实现旁并行搭建新 workspace以既有测试套件为行为基准按骨架 → 数据 → 桥接 → 启动 → 路由 → UI → 安装 → 文档 → 移除的顺序分十步推进每一步都可编译、可测试、可独立提交最终以全量验证 手工冒烟清单作为删除 Python 的硬门禁。对于任何打算把 Python/Node 原型迁移到 Rust Tauri 的桌面工具项目这份计划的模块划分core / data / launcher / manager、接口契约serde 键名兼容、路由兜底、原子写状态文件与验证策略fixture 对等、锁降级、门禁清单都可以直接套用。而当前仓库的代码现状则证明按照这样的计划执行是可以真正落地、并在其上继续长出更丰富功能的。【免费下载链接】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），仅供参考