教程 on XEDCZQ的博客

Mac 使用 CCSwitch 切换中转站后恢复 Codex 历史记录

Thu, 11 Jun 2026 00:00:00 +0800

Mac 使用 CCSwitch 切换中转站后恢复 Codex 历史记录

这篇笔记记录在 Mac 上使用 CCSwitch 切换 Codex 中转站或模型提供方后，历史对话突然不显示时的排查和恢复方法。

先说结论：历史文件通常仍保存在 Mac 本机，只是切换 Provider 后，当前环境可能无法直接查询旧 Provider 下的线程。

本文使用第三方命令行工具 codex-threadripper 重新扫描和同步本地线程。它不是 OpenAI 官方工具，安装和执行前建议先确认软件来源，并完整备份 ~/.codex。

问题现象

使用 CCSwitch 切换 Codex 的中转站、model_provider 或 base_url 后，可能出现以下情况：

Codex 可以正常启动和回答问题。
新创建的对话可以正常保存。
切换前的历史对话不再显示。
~/.codex 目录仍然存在，磁盘空间也没有明显减少。

这类情况不一定代表历史文件被删除。Codex 的本地线程数据可能带有 Provider、模型来源或环境相关信息；切换配置后，新环境看到的线程集合可能和旧环境不同。

恢复思路

完整流程可以概括为：

备份 ~/.codex
 -> 使用 CCSwitch 切换到目标中转站
 -> 确认 Codex 可以正常运行
 -> 使用 codex-threadripper 扫描并同步线程
 -> 重新打开 Codex
 -> 检查历史记录和工具状态

不要在没有备份的情况下直接修改或删除 Codex 本地数据库。历史文件还在时，通常还有恢复空间；原始数据一旦被覆盖，处理会麻烦很多。

安装 codex-threadripper

codex-threadripper 是用于扫描和处理 Codex 本地历史线程的第三方命令行工具。根据你使用的包管理方式，可以选择 Homebrew 或 npm。

使用 Homebrew 安装

brew tap wangnov/tap
brew install codex-threadripper

使用 npm 全局安装

npm i -g codex-threadripper

安装后先检查命令是否可用：

codex-threadripper --help

如果 Homebrew 或 npm 提示找不到包，说明当前软件源中没有该工具，或者工具名称、仓库地址已经变化。此时不要使用来源不明的二进制文件，先确认项目仓库和发布页面。

Mac 推荐恢复流程

备份 Codex 本地数据

先退出正在运行的 Codex，再执行备份：

cp -R ~/.codex ~/.codex_backup_$(date +%Y%m%d_%H%M%S)

确认备份目录已经生成：

ls -ld ~/.codex_backup_*

备份内容可能包含账户信息、配置和历史对话，不要上传到公开网盘、公共仓库或发送给不可信的人。

使用 CCSwitch 切换目标中转站

在 CCSwitch 中切换到需要使用的目标中转站或模型提供方，然后重新打开 Codex，确认：

Codex 可以正常启动。
当前 Provider 可以正常鉴权。
可以发送一条测试消息并收到回复。

先保证新环境本身可用，再同步历史记录。否则 Provider 配置问题和历史索引问题会混在一起，不容易判断故障位置。

执行线程同步

在 Mac 终端运行：

codex-threadripper sync

如果工具没有自动识别 Codex 数据目录，可以显式指定：

codex-threadripper --codex-home "$HOME/.codex" sync

其中 $HOME/.codex 会在 macOS 上解析为：

/Users/你的用户名/.codex

同步过程中不要同时启动多个 Codex 实例，也不要中途删除 ~/.codex 中的数据库或线程文件。

重新加载 Codex

同步完成后，完全退出并重新启动 Codex，然后从当前版本提供的历史记录或恢复线程入口查看对话。

Codex 不同版本的历史入口可能不同。若某个参数或交互指令不可用，先查看当前安装版本支持的命令：

codex --help

部分版本或界面可能提供历史列表、恢复会话、线程列表或搜索入口，应以当前客户端实际显示为准。

查看同步状态

可以使用第三方工具检查当前线程状态：

codex-threadripper status

如果该版本支持 Provider 分组，状态输出会按 custom、openai 等来源列出线程，便于确认旧记录是否已经被扫描和合并。

如何判断恢复成功

可以从以下几个方面检查：

切换前的历史线程重新出现在 Codex 中。
打开旧线程后，用户消息和 Codex 回复顺序完整。
新 Provider 下可以继续创建和保存对话。
codex-threadripper status 能扫描到预期线程。
重启 Codex 后，恢复的线程仍然可见。

常见问题排查

找不到 codex-threadripper 命令

先检查安装路径：

which codex-threadripper
codex-threadripper --help

如果通过 npm 安装，还需要确认 npm 全局可执行目录已经加入 PATH。

同步后仍然看不到旧对话

按下面顺序检查：

确认同步时使用的是实际 Codex 目录 ~/.codex。
确认执行同步前已经切换到目标 Provider。
完全退出 Codex 后重新启动，而不是只关闭窗口。
使用 status 检查工具是否扫描到旧线程。
检查旧数据是否位于其他 CODEX_HOME 目录或备份目录。
查看同步命令输出中是否有数据库锁、权限或格式不兼容错误。

同步时提示数据库被占用

先退出 Codex 和其他可能访问 ~/.codex 的进程，再重试。不要在数据库正在写入时强制复制或修改索引。

切回旧 Provider 后历史又出现

这通常说明原始历史数据没有丢失，而是不同 Provider 环境下的线程可见范围或索引不同。此时更应该先备份，再决定是否执行同步，而不是删除旧配置。

回滚方法

如果同步后出现异常，先退出 Codex。保留当前异常目录用于排查，然后将备份恢复为 ~/.codex。

恢复前务必确认备份目录名称。下面只是示例：

mv ~/.codex ~/.codex_after_sync
cp -R ~/.codex_backup_20260611_120000 ~/.codex

不要直接照抄示例中的时间戳，应替换为你实际生成的备份目录。

安全提醒

~/.codex 可能包含登录状态、Provider 配置、API Key 引用和对话内容。
不要把完整目录提交到 Git。
不要把数据库文件发送给陌生人排查。
使用第三方线程工具前，先检查来源、安装脚本和发布文件。
每次同步前都保留一份未修改的原始备份。

小结

使用 CCSwitch 切换 Codex 中转站后，历史记录消失通常不等于本地数据被删除，更可能是 Provider 配置变化后旧线程没有被当前环境读取。处理这类问题时，最重要的顺序是：先备份，再切换并验证 Provider，最后同步线程和检查结果。

codex-threadripper 可以作为第三方恢复手段，但命令和包来源可能随版本变化。实际操作时，应先通过 --help 核对当前版本，再对 ~/.codex 做任何写入操作。

个人博客建站流程（踩坑）

Tue, 26 May 2026 11:30:00 +0800

个人博客建站流程

个人博客上线的完整记录，一个很不理想的“踩坑流程”。

这里把关键决策、问题原因和修复方式都写清楚，后面自己重搭时可以直接复用也当作教程发布。

主流建站路线

免服务器路线

适合技术新手、轻量展示需求、希望快速上线的人。

典型方案：

GitHub Pages + Hugo / Hexo
成本低，甚至可以接近 0 成本
不需要维护服务器

官网参考：

传统服务器路线

适合想要完全掌控、后续可能扩展动态功能的人。

典型方案：

购买云服务器 + 域名
自建 Nginx + 静态站，或部署 WordPress/Typecho

官网参考：

我最终选择的是传统服务器路线，因为我已经买了 1 年的云服务器，不想浪费。

我的实际方案

云服务器：华为云 ECS（已购 1 年）
域名：阿里云购买 xedczq.cn
站点：静态博客（Hugo 生成 + Nginx 提供服务）

官网参考：

我当时的想法很简单：

服务器用已有的（省钱）
域名选便宜的（继续省钱）

后面事实证明，这两个“省钱决策”都没有错，但会带来额外的网络和备案流程复杂度。

域名购买与解析

我在阿里云买完 xedczq.cn 后，第一时间把 DNS 解析到了华为云服务器 IP，目的是先验证公网可达。

这一步我建议先做三个最小验证：

本地 nslookup 域名 是否解析到目标 IP
服务器端服务是否真的监听在对外端口（80/443）
安全组与防火墙端口是否放行

ICP 备案

我遇到的第一个硬问题就是：ICP备案。

什么情况下需要 ICP 备案

通常需要备案的场景：

服务器在中国大陆机房
域名要在中国大陆提供互联网信息服务

通常不需要备案的场景：

服务器不在中国大陆（如香港、海外）
仅面向海外访问

官方查询与说明入口（以工信部体系为准）：

工业和信息化部 ICP/IP 地址/域名信息备案管理系统

因为我不想重新买海外服务器，所以走了完整备案流程，前后大约 10 天。

挂梯子后无法访问的问题

备案过后，我遇到了第二个问题：

不挂梯子能访问
挂梯子后访问异常

这个问题通常和“解析链路、代理线路、DNS 解析策略、地区网络路径”有关，不是单点故障。

我一开始以为是华为服务器防火墙挡住了境外ip访问，查了半天突然发现直接用服务器ip可以访问到…

那就只能是 DNS 与线路策略存在地域差异，发现阿里云免费的DNS服务是只提供国内的解析，于是开始尝试引入 Cloudflare 做统一解析与代理。

Cloudflare 接入域名

我把域名托管到了 Cloudflare，想解决跨地区访问稳定性问题。

官网参考：

Cloudflare 的核心优势：

全球 Anycast 网络
DNS 生效快、可观测性好
可选 CDN / WAF / 基础防护
支持代理（橙色云）与仅 DNS（灰色云）两种模式

我踩到的点

我最开始直接开了“小橙云”（代理模式），结果站点反而不可用。

排查后发现问题核心是：

代理模式会让访问先到 Cloudflare 边缘，再回源到我的服务器
回源链路、证书模式、源站策略、备案接入条件如果没配齐，就可能触发访问异常

域名接入点备案

Cloudflare 接入后又触发了“域名接入点备案”相关问题。我的处理方式是：

先临时关闭代理（灰云，仅 DNS）
回到华为云按要求做接入备案
等待审核通过（我这次约 4 天）

这一步结束后，访问路径恢复稳定。

HTTPS 上线

最后一步是在服务器申请并部署免费 HTTPS 证书，完成全站加密访问。

我这里采用的是免费证书方案（如 Let’s Encrypt 体系），并配置了 HTTP -> HTTPS 跳转。

官网参考：

Let’s Encrypt

到这里，博客才算真正完成上线。

我这次流程的时间线

域名购买与首轮解析：当天完成
ICP 备案：约 10 天
Cloudflare 接入与排查：1~2 天
域名接入备案：约 4 天
HTTPS 部署：当天完成

最后总结

如果我只追求“最快上线”，我会直接选免服务器路线。如果我追求“长期可控 + 可扩展”，服务器路线是值得的，但有几个注意事项：

如果你没有购买服务器，尽量购买一个境外服务器，可以直接一步通关
已经有服务器的话，尽量在服务器的同厂商购买域名，例如：华为云服务器就在华为云购买域名..
当然如果你也像我一样贪便宜买了不同厂商的国内服务器和域名，至少你还有这篇踩坑文章可以查看
个人备案需要时间成本
解析与代理是网络工程问题，不是一条命令的问题
证书、回源、接入策略必须一起看，单点优化往往无效

这次建站最大的收获不是“会搭博客”，而是我对域名、DNS、备案、代理、回源链路这整条路径有了完整认知。

手机 GPT 连接 Mac Codex 教程

Tue, 26 May 2026 10:30:00 +0800

手机 GPT 连接 Mac Codex 教程

这篇是我自己的实操记录，目标是把手机端 GPT 和 Mac 上的 Codex 正常联通。

操作步骤

登录同一账号

在手机 GPT App 登录自己的账号
在 Mac 的 Codex 里登录同一个账号

开启手机多因素认证

在手机端开启多因素认证（MFA），否则可能会在手机安全验证中失败
我这里用的是 Apple 系统自带密码/认证能力完成验证

配置 Codex 代理环境变量

编辑 ~/.codex/.env 文件，加入以下内容：

HTTP_PROXY=http://127.0.0.1:6789
HTTPS_PROXY=http://127.0.0.1:6789
ALL_PROXY=http://127.0.0.1:6789
WS_PROXY=http://127.0.0.1:6789
WSS_PROXY=http://127.0.0.1:6789
http_proxy=http://127.0.0.1:6789
https_proxy=http://127.0.0.1:6789
all_proxy=http://127.0.0.1:6789
ws_proxy=http://127.0.0.1:6789
wss_proxy=http://127.0.0.1:6789
NO_PROXY=localhost,127.0.0.1,::1
no_proxy=localhost,127.0.0.1,::1

配置完成后，重启 Codex。

魔法用户不改代理环境时codex可以正常使用但是手机端可能会显示设备不在线

连接手机与 Codex

重启后重新尝试手机端与 Codex 的连接流程
连接成功后即可正常使用

成功标准

我这边判断是否成功主要看两点：

手机 GPT 与 Mac Codex 使用同一账号状态稳定
Codex 网络请求正常，不再出现代理/连接异常

排查建议

如果失败，我会按下面顺序排查：

检查手机和 Mac 是否确实为同一账号
检查 MFA 是否已完成并生效
检查 ~/.codex/.env 是否保存成功、端口是否正确
确认本地代理 127.0.0.1:6789 是否启动，端口是否一致
重启 Codex 后再试一次