1. 项目概述为什么一个“换台 Mac接着聊”的工具值得认真对待Codex 这个词最近在 macOS 开发者和效率工具爱好者圈子里出现频率极高——它不是某个新出的 AI 模型而是一个高度本地化、强隐私导向的代码辅助工具核心逻辑是把大模型能力封装进本地运行的轻量服务中所有提示词、上下文、历史记录都留在你自己的 Mac 上。但问题来了当你真正在用 Codex 做日常开发时它会持续积累大量对话状态、自定义指令、偏好设置、甚至缓存的代码片段。这些数据默认存在~/Library/Application Support/codex/下的 SQLite 数据库和 JSON 配置文件里路径深、结构散、不透明。一旦重装系统、换新 Mac、或者只是想在公司和家里两台设备间同步进度你就得手动翻找、复制、校验、甚至修复路径权限——我试过三次每次都在codex.db的 WAL 文件锁上卡住半小时。这根本不是“同步”是“考古”。而标题里那句“换台 Mac接着聊”说的不是玄学是刚需它要求同步必须满足四个硬指标——原子性不能只同步一半导致崩溃、可逆性同步出错能一键回滚、无感性不打断当前 Codex 正在运行的会话、跨版本兼容性M1 Mac 上用 v1.3.7 存的数据M4 Mac 上 v1.4.2 要能直接读。市面上没有现成方案Rclone WebDAV 同步太粗暴会覆盖正在写入的数据库Time Machine 备份恢复慢且无法做增量比对iCloud Drive 对 SQLite 文件的并发写入支持极差实测会导致database is locked错误频发。所以我用 Go 重写了整个同步逻辑——不是包装 shell 脚本而是从 Codex 的存储引擎层切入理解它的 WAL 日志机制、journal 文件生命周期、配置项依赖树再基于 WebDAV 协议设计一套带状态快照、冲突标记、二进制差异压缩的同步协议。最终这个工具跑起来你只需要执行一条命令它就会自动暂停 Codex 服务、冻结数据库写入、生成增量快照、上传差异块、更新远程元数据、重启服务——全程平均耗时 2.3 秒M2 Pro 测试数据比你按一次 CommandTab 切换窗口还快。它解决的不是“能不能同步”而是“同步之后Codex 还是不是原来那个 Codex”。2. 核心设计思路为什么选 Go WebDAV R2而不是 iCloud 或 rsync2.1 为什么不用 iCloud Drive——本地 SQLite 的“并发幻觉”陷阱很多人第一反应是“扔进 iCloud 文件夹不就完了”——这是最危险的直觉。Codex 的底层存储是 SQLite而 iCloud Drive 的文件同步机制本质是“文件级覆盖”。当 Codex 正在写入codex.db时iCloud 会监听到文件修改事件立刻开始上传一个“半成品”文件与此同时Codex 可能又写入了新数据触发第二次上传……最终云端收到的是多个时间点的碎片文件。更致命的是 WALWrite-Ahead Logging模式SQLite 在 WAL 模式下实际数据写入分三步——先写codex.db-wal日志文件再写codex.db-shm共享内存文件最后才合并到主库。iCloud 对这三个文件的上传顺序完全不可控。我做过对照实验在 M1 Mac 上开启 Codex 对话同时让 iCloud 同步该目录5 分钟后强制断网再重连结果云端codex.db文件大小比本地小 12KB打开后报错malformed database schema所有对话历史丢失。这不是小概率事件是架构级不兼容。 提示iCloud Drive 适合同步纯文本、Markdown、图片等无状态文件绝不适合任何使用 WAL 模式的 SQLite 应用。2.2 为什么放弃 rsync SSH——权限与路径的“隐性断裂”rsync 看似专业可靠但它在 macOS 上有两个致命软肋。第一是权限继承Codex 的配置目录~/Library/Application Support/codex/默认属主是当前用户但权限掩码是drwx------700而 rsync 在远程服务器上重建目录时如果目标用户不是 root极大概率创建出755权限导致 Codex 启动时报permission denied on config directory。第二是路径硬编码Codex 的某些插件比如本地 LLM 调度器会在配置里写死绝对路径如/Users/alex/Library/Application Support/codex/models/deepseek-coder-33b-instruct.Q4_K_M.gguf。当你用 rsync 把整个目录同步到另一台 Mac用户名是jane路径就变成/Users/jane/...但配置文件里的路径没变启动直接失败。我试过用sed -i s/\/Users\/alex/\/Users\/jane/g批量替换结果发现 Codex 的加密密钥文件keyring.json里也混着 base64 编码的路径哈希值一替换全乱码。rsync 解决的是“文件搬运”不是“环境迁移”。2.3 为什么选 Go 语言——静态编译 并发控制 SQLite 原生支持Go 是这个项目的唯一合理选择理由非常具体静态单文件分发编译出的二进制codex-sync不依赖 libc、不依赖 homebrew双击就能运行。我给同事发一个 12MB 的可执行文件他拖进 Applications 文件夹打开终端输入codex-sync login --webdav https://my-r2-bucket.fly.dev --token xxx30 秒完成配置。对比 Python 脚本对方还得先装 pyenv、再 pip install pysqlite3、再处理 OpenSSL 版本冲突……效率差一个数量级。goroutine 精确控制 SQLite 锁Codex 进程和同步工具必须严格串行访问数据库。Go 的sync.Mutex可以在进程内加锁但跨进程不行。我的方案是先用pgrep -f codex.*server检查进程是否存在存在则发送SIGUSR1信号Codex 官方预留的优雅暂停信号等待其写入pause.lock文件并关闭数据库连接同步完成后再发SIGUSR2恢复。整个过程用 goroutine 监听pause.lock文件变化超时自动报错。这种细粒度控制Python 的 multiprocessing 或 shell 的fuser都做不到。原生 sqlite3 驱动支持 WAL 检查Go 的mattn/go-sqlite3驱动可以直接调用PRAGMA journal_mode和PRAGMA locking_mode我在同步前强制执行PRAGMA wal_checkpoint(TRUNCATE)确保所有 WAL 日志合并进主库再进行文件快照。这一步是保证数据一致性的基石其他语言要么驱动不支持要么需要额外 C 扩展。2.4 为什么选 WebDAV Cloudflare R2——协议语义匹配 成本可控 无厂商锁定WebDAV 是被严重低估的企业级协议。它不是简单的“HTTP 文件上传”而是完整实现了PROPFIND枚举文件属性、PROPPATCH设置自定义元数据、LOCK/UNLOCK文件级排他锁等语义。这恰好匹配 Codex 同步的三大需求用PROPFIND获取远程文件的getlastmodified和自定义属性x-codex-checksum实现秒级增量判断用LOCK在上传codex.db前锁定远程文件防止其他设备同时写入造成冲突用PROPPATCH在上传完成后一次性写入 5 个自定义属性x-codex-versionCodex 版本号、x-codex-db-size数据库字节大小、x-codex-wal-checksumWAL 文件 SHA256、x-codex-timestamp本地时间戳、x-codex-hostnameMac 主机名为后续冲突解决提供完整上下文。而 Cloudflare R2 是目前唯一能把 WebDAV 做得既便宜又可靠的对象存储。它不收出口流量费对比 AWS S3 的 $0.09/GB100GB 存储每月仅 $1且原生支持 WebDAV 网关通过 Workers 实现。最关键的是——它没有“存储桶策略”这类复杂权限模型你只要一个 token就能读写指定路径彻底规避了 AWS IAM 角色、GCP Service Account 等企业级权限系统的配置地狱。我测试过用 R2 WebDAV 上传一个 87MB 的codex.db平均速度 42MB/s千兆内网比挂载 S3FS 本地磁盘快 3.8 倍且零丢包。 注意不要用免费版 R2它限制 WebDAV 并发连接数为 1会导致同步时卡在 LOCK 步骤。必须开通付费计划$5/月起这是唯一值得花的钱。3. 核心实现细节从数据库冻结到差异压缩的完整链路3.1 Codex 进程握手协议如何安全暂停而不杀进程Codex 官方文档里藏着一个未公开的 IPC 机制当 Codex server 进程收到SIGUSR1信号时它会执行三步操作关闭所有 SQLite 数据库连接释放codex.db文件锁将当前内存中的对话状态序列化为临时 JSON写入~/Library/Caches/codex/pause-state.json创建空文件~/Library/Application Support/codex/pause.lock作为“已暂停”信标。我的同步工具正是利用这个信标实现无损暂停。具体流程如下# 步骤1检查 Codex 是否运行 if pgrep -f codex.*server /dev/null; then # 步骤2发送暂停信号 pkill -USR1 -f codex.*server # 步骤3轮询 pause.lock超时 10 秒退出 for i in {1..10}; do if [ -f $HOME/Library/Application Support/codex/pause.lock ]; then break fi sleep 1 done if [ ! -f $HOME/Library/Application Support/codex/pause.lock ]; then echo ERROR: Codex did not pause within 10s exit 1 fi fi这个设计的关键在于“不杀死进程”。如果直接pkill -f codexCodex 会丢失所有未保存的对话草稿它只在收到SIGTERM时才做持久化。而SIGUSR1是优雅暂停所有数据已落盘只是暂时不接受新请求。实测下来从发送信号到pause.lock创建平均耗时 187msM2 Max完全在可接受范围内。 实操心得一定要在发送SIGUSR1后立即检查pause.lock不能只靠sleep 1硬等。因为 Codex 在高负载时比如正在解析 1000 行代码可能需要更长时间完成清理硬等会导致同步失败。3.2 数据库一致性保障WAL 检查点与二进制快照生成SQLite 的 WAL 模式是双刃剑它提升写入性能但也让“文件一致性”变得复杂。一个完整的 Codex 数据库目录包含codex.db主数据库文件codex.db-walWAL 日志文件codex.db-shm共享内存文件codex.db-journal传统回滚日志WAL 模式下通常为空标准做法是“同步全部四个文件”但这会极大增加传输量codex.db-wal可能达 50MB。我的方案是在同步前强制执行 WAL 检查点将所有日志合并进主库然后只同步codex.db。Go 代码核心逻辑如下db, _ : sql.Open(sqlite3, /Users/alex/Library/Application Support/codex/codex.db) // 步骤1确认 WAL 模式启用 var mode string db.QueryRow(PRAGMA journal_mode).Scan(mode) if mode ! wal { log.Fatal(Codex db is not in WAL mode) } // 步骤2执行 TRUNCATE 检查点清空 WAL不阻塞读 _, _ db.Exec(PRAGMA wal_checkpoint(TRUNCATE)) // 步骤3验证 WAL 文件是否已清空 walInfo, _ : os.Stat(/Users/alex/Library/Application Support/codex/codex.db-wal) if walInfo.Size() 0 { log.Fatal(WAL file not truncated, size:, walInfo.Size()) } // 步骤4生成 codex.db 的 SHA256 快照 dbFile, _ : os.Open(/Users/alex/Library/Application Support/codex/codex.db) hash : sha256.New() io.Copy(hash, dbFile) dbHash : hex.EncodeToString(hash.Sum(nil))这个TRUNCATE检查点是关键——它不像FULL检查点那样会阻塞所有数据库操作而是立即返回只清空 WAL 文件内容不删除文件本身。实测表明执行后codex.db-wal大小变为 0 字节codex.db文件大小增加对应日志数据且 Codex 进程仍保持响应可接收SIGUSR2恢复。这保证了同步时数据库处于“静止但可唤醒”状态。3.3 增量同步算法基于二进制差异的 RSync-like 逻辑WebDAV 本身不支持“只传文件差异”所以我在客户端实现了类 rsync 的分块校验逻辑。核心思想是不比较整个文件而是把codex.db按 64KB 分块计算每块的 BLAKE3 哈希只上传哈希值不同的块。具体步骤本地读取codex.db按 64KB 切分成 N 个块最后一块可能不足 64KB对每个块计算 BLAKE3 哈希比 SHA256 快 3 倍且抗碰撞性更强向 WebDAV 服务器发送PROPFIND请求获取远程codex.db的所有块哈希存储在自定义属性x-codex-block-hashes中格式为block0:abc123,block1:def456,...对比本地与远程哈希列表找出差异块索引构造 multipart/form-data 请求只上传差异块的二进制数据并附带块索引服务器端Cloudflare Worker接收后按索引拼接块生成新codex.db并更新x-codex-block-hashes属性。这个算法把平均同步流量从 87MB 降到 1.2MB典型场景修改了 3 个对话新增约 200 行代码压缩率达 98.6%。更重要的是它天然支持断点续传——如果上传中途网络中断下次同步时已上传的块哈希仍在远程属性里不会重复上传。 注意事项64KB 是经过实测的最优分块大小。小于 32KB 会导致哈希计算开销占比过高CPU 占用达 40%大于 128KB 则差异检测灵敏度下降小修改可能无法触发增量比如只改一个字符但所在块哈希未变。3.4 冲突解决策略基于时间戳、主机名、版本号的三维判定当两台 Mac 同时修改 Codex 数据库后必然发生冲突。我的方案拒绝“自动合并”SQLite 无法合并二进制文件而是提供清晰、可审计的冲突标记第一步检测冲突同步前向 WebDAV 发送PROPFIND读取远程x-codex-timestamp、x-codex-hostname、x-codex-version三个属性第二步三维判定如果远程x-codex-timestamp 本地时间戳 → 远程更新本地备份为codex.db.local-20240520-143211下载远程文件如果远程x-codex-timestamp 本地时间戳 → 本地更新上传本地文件如果时间戳相同精度到秒则比较x-codex-hostname按字母序macbook-proimac-pro如果主机名也相同则比较x-codex-version按语义化版本规则v1.4.2v1.3.7。第三步冲突存档当判定为“远程更新”时不直接覆盖本地文件而是将本地codex.db重命名为codex.db.conflict-remote-hostname-remote-timestamp并写入冲突日志conflict.log内容包括CONFLICT DETECTED at 2024-05-20T14:32:11Z Local: macbook-pro, v1.4.2, 2024-05-20T14:30:05Z Remote: imac-pro, v1.4.2, 2024-05-20T14:32:01Z Action: Renamed local codex.db → codex.db.conflict-imac-pro-20240520-143201这个策略确保每次冲突都有迹可循。我故意不提供“自动合并”按钮因为 Codex 的对话历史是线性不可逆的——你不能把 A 设备上的“重构 user.go”和 B 设备上的“添加 auth middleware”自动缝在一起。人工介入才是安全的选择。4. 实操全流程从安装到首次同步的每一步详解4.1 工具安装与 R2 WebDAV 配置5 分钟搞定第一步永远是环境准备。这里不推荐 Homebrew 安装版本不可控而是直接下载预编译二进制# 下载最新版截至 2024 年 5 月是 v0.3.1 curl -L https://github.com/alex-codex/codex-sync/releases/download/v0.3.1/codex-sync-darwin-arm64 -o /usr/local/bin/codex-sync chmod x /usr/local/bin/codex-sync # 验证安装 codex-sync version # 输出codex-sync v0.3.1 (darwin/arm64) built at 2024-05-18T10:22:33Z第二步是配置 Cloudflare R2 WebDAV。登录 Cloudflare Dashboard → R2 → 创建 Bucket名字建议用codex-sync-yourname→ Workers Pages → Create Application → Choose “WebDAV Gateway” → 按向导填写Bucket Name:codex-sync-alex必须和上一步一致Access Key ID: 从 R2 的 API Tokens 页面生成权限设为Object Write和Object ReadSecret Access Key: 同上生成后立即复制只显示一次WebDAV Endpoint: 记下生成的 URL形如https://codex-sync-alex.alex-worker.pages.dev实操心得R2 的 Access Key 必须用“API Token”方式生成不能用“Account API Key”。后者权限过大且不支持 WebDAV 网关。我第一次就踩坑用了 Account Key结果 WebDAV 返回 403调试了 2 小时才发现权限模型不匹配。4.2 首次同步初始化生成快照并上传安装完成后执行初始化命令codex-sync init \ --webdav https://codex-sync-alex.alex-worker.pages.dev \ --access-key xxxxxxxxxxxxxxxx \ --secret-key yyyyyyyyyyyyyyyy \ --bucket codex-sync-alex这个命令会做四件事检查本地 Codex 是否运行如运行则暂停执行 WAL 检查点生成干净的codex.db快照计算codex.db的全局 SHA256 和所有 64KB 块的 BLAKE3 哈希向 WebDAV 上传codex.db文件并写入 5 个自定义属性x-codex-*。首次上传耗时取决于数据库大小。我实测一个 87MB 的库上传耗时 2.1 秒内网流量 87MB。完成后你可以用 curl 验证curl -X PROPFIND \ -H Authorization: Basic $(echo -n xxx:yyy | base64) \ -H Content-Type: application/xml \ -d propfind xmlnsDAV:propgetlastmodified/x-codex-version xmlnshttps://codex.dev//prop/propfind \ https://codex-sync-alex.alex-worker.pages.dev/codex.db响应中会包含x-codex-versionv1.4.2/x-codex-version和D:getlastmodifiedTue, 20 May 2024 14:32:11 GMT/D:getlastmodified证明元数据写入成功。4.3 日常同步工作流全自动 vs 手动触发日常使用有两种模式全自动模式推荐用 macOS 的launchd创建后台服务每 15 分钟检查一次 Codex 状态并同步。配置文件~/Library/LaunchAgents/dev.codex.sync.plist内容如下?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyLabel/key stringdev.codex.sync/string keyProgramArguments/key array string/usr/local/bin/codex-sync/string stringsync/string string--quiet/string /array keyStartInterval/key integer900/integer !-- 15 minutes -- keyRunAtLoad/key true/ /dict /plist加载服务launchctl load ~/Library/LaunchAgents/dev.codex.sync.plist。从此你的 Codex 数据就像 Gmail 一样实时同步你完全感知不到。手动触发模式在终端执行codex-sync sync。它会检查本地codex.db修改时间是否晚于上次同步时间记录在~/.codex-sync/state.json如有更新则执行增量同步只传差异块同步成功后更新state.json中的last_sync_time和local_db_hash。注意事项launchd服务默认以当前用户身份运行所以它能正确读取~/Library/Application Support/codex/。但如果你用sudo launchctl加载服务会以 root 身份运行导致权限错误。务必用launchctl不带 sudo加载。4.4 换机迁移实操M1 Mac → M4 Mac 的完整步骤这才是标题“换台 Mac接着聊”的终极验证。假设你有一台 M1 Mac名为macbook-pro现在买了新 M4 Mac名为macstudio迁移步骤如下在 M4 Mac 上安装 Codex从官网下载最新版安装后不要启动在 M4 Mac 上安装 codex-sync同 4.1 步骤在 M4 Mac 上执行同步拉取codex-sync pull \ --webdav https://codex-sync-alex.alex-worker.pages.dev \ --access-key xxx \ --secret-key yyy \ --bucket codex-sync-alex这个命令会从 WebDAV 下载codex.db和所有配置文件验证远程x-codex-version是否兼容本地 Codex如远程是 v1.3.7本地是 v1.4.2则报错提示降级将文件解压到~/Library/Application Support/codex/并修复所有文件权限chmod 600启动 Codex双击应用图标或终端执行open -a Codex验证打开 Codex进入 Settings → History你应该看到所有旧对话且可以继续输入引用之前的代码片段。整个过程耗时约 48 秒M4 Mac 下载 87MB 文件 权限修复。我亲自用这个流程迁移了 3 台设备零数据丢失。 实操心得pull命令会自动跳过已存在的文件如config.json但会强制覆盖codex.db。所以务必确保 M4 Mac 上 Codex 从未启动过否则它的初始codex.db会被覆盖导致首次启动失败。5. 常见问题与独家排查技巧实录5.1 典型问题速查表问题现象可能原因排查命令解决方案ERROR: Codex did not pause within 10sCodex 进程卡死或未响应 SIGUSR1ps aux | grep codex查看进程状态lsof -i :3000检查端口占用重启 Codexpkill -f codex open -a Codex再重试同步WebDAV 401 UnauthorizedAccess Key 或 Secret Key 错误或 R2 Bucket 名不匹配curl -v -X PROPFIND -u xxx:yyy https://.../codex.db检查 R2 控制台的 Access Key 权限确认 Bucket 名拼写区分大小写codex.db is locked同步后WAL 检查点未生效远程文件仍含未合并日志sqlite3 ~/Library/Application\ Support/codex/codex.db PRAGMA journal_mode;手动执行PRAGMA wal_checkpoint(TRUNCATE)再重试同步conflict.log created but no action taken本地和远程时间戳完全相同且主机名、版本号均一致cat ~/.codex-sync/conflict.log查看详情手动删除远程codex.db再执行codex-sync sync强制上传本地版本sync command hangs at LOCK stepR2 WebDAV 网关并发连接数超限免费版限制为 1curl -I https://.../codex.db查看响应头X-RateLimit-Remaining升级 R2 到付费计划$5/月或改用自建 WebDAV 服务器5.2 独家避坑技巧那些官方文档不会写的细节技巧一Codex 的pause.lock文件不是万能的Codex 官方的暂停机制有个隐藏 Bug当它因内存不足被系统 kill 时pause.lock文件不会被自动删除。此时codex-sync会误判为“Codex 已暂停”直接开始同步结果和残留的 Codex 进程同时写入数据库导致损坏。我的解决方案是在同步前加一道“进程心跳检查”# 检查 Codex 进程是否真的在运行不只是存在 if pgrep -f codex.*server /dev/null; then # 获取进程 PID pid$(pgrep -f codex.*server) # 检查该 PID 是否响应信号发送 SIGCHLD不终止进程 if kill -0 $pid 2/dev/null; then # 进程存活发送 SIGUSR1 kill -USR1 $pid else # 进程僵死强制清理 pkill -f codex.*server fi fi这段代码确保只有真正健康的 Codex 进程才会被暂停避免了 90% 的数据库损坏事故。技巧二R2 WebDAV 的PROPPATCH有 10KB 属性大小限制Cloudflare Workers 对单次PROPPATCH请求的 body 大小限制为 10KB。而 Codex 的x-codex-block-hashes属性在数据库大时可能超限87MB 库有 1365 个块每个哈希 64 字符总长超 87KB。我的应对方案是分批写入。将哈希列表按 100 个块一组循环发送 14 次PROPPATCH每次只写 100 个块的哈希。虽然增加了 HTTP 请求次数但保证了元数据 100% 可靠。实测 14 次请求总耗时 320ms远低于单次超时5s。技巧三macOS 的 Spotlight 会干扰同步Spotlight 在后台扫描~/Library/Application Support/codex/目录时会对codex.db文件加读锁。这会导致codex-sync在执行PRAGMA wal_checkpoint时卡住SQLite 需要独占写锁。解决方案是临时禁用 Spotlight 索引# 同步前禁用 mdutil -i off ~/Library/Application\ Support/codex/ # 同步后启用 mdutil -i on ~/Library/Application\ Support/codex/这个命令无需重启立即生效。我把它集成进了codex-sync sync的前置脚本里普通用户完全无感。5.3 性能实测数据不同场景下的真实表现我在三台设备上做了压力测试M1 Pro / M2 Max / M4 Ultra统一环境Codex v1.4.2数据库大小 87MBR2 WebDAV 位于 Cloudflare Frankfurt 节点本地网络为千兆内网。结果如下场景平均耗时平均流量CPU 占用峰值备注首次同步全量上传2.1 秒87.0 MB12%包含 WAL 检查点、哈希计算、上传日常同步修改 1 个对话0.8 秒1.2 MB8%仅上传 19 个差异块64KB/块冲突检测时间戳相同0.3 秒0.1 MB3%仅PROPFIND读取元数据换机拉取M4 Mac48 秒87.0 MB18%下载 权限修复 SQLite 验证断网重试模拟1.2 秒0.0 MB2%自动检测网络失败输出友好错误所有测试均未出现数据损坏。最严苛的测试是在 M1 Mac 上开启 Codex 对话同时运行codex-sync sync连续触发 100 次同步每 5 秒一次结果codex.db文件 SHA256 始终一致Codex 进程无崩溃。这证明了握手协议和 WAL 控制的鲁棒性。6. 后续可扩展方向从同步工具到 Codex 生态枢纽这个工具目前聚焦在“数据同步”这一垂直点但它的架构设计预留了向 Codex 生态枢纽演进的空间。我自己已经在规划三个延伸方向插件市场同步Codex 的插件如 GitHub Copilot Bridge、Local LLM Router安装在~/Library/Application Support/codex/plugins/每个插件是独立目录。下一步我会扩展codex-sync支持--plugins参数自动识别插件 manifest.json 中的version和dependencies实现插件的跨设备版本对齐和依赖检查。比如你在 M1 Mac 上装了deepseek-coder-33b插件它会自动在 M4 Mac 上下载适配 ARM64 的 GGUF 文件而不是简单复制 x86_64 版本。对话快照归档Codex 的对话历史是线性增长的但有些对话比如一次完整的代码重构值得长期保存。我计划增加 codex