文武科技柜 我把 Cockpit Tools 的 2 个 Codex 唤醒任务迁到了 VPS：关掉电脑也能自动运行
文章目录
我之前一直在 Cockpit Tools（Windows、MacOS安装包） 里登录两个 Codex 账号，并给它们配置了唤醒任务。
平时用着没什么问题。
但它有一个明显的限制：
任务还是依赖本地环境。
如果电脑关机、Cockpit Tools 没有运行，唤醒任务自然也就执行不了。
我想要的其实很简单：
不管我的电脑开不开机，都让服务器自己每小时唤醒两个 Codex 账号。
于是我没有继续研究 Cockpit Tools 怎么同步，而是直接把这件事交给了 AI。
最后 AI 帮我把两个账号迁到了 VPS，并重新做了一套服务器定时任务。
整个过程我基本没有自己写 systemd，也没有一条一条复制 Linux 命令。
如果你也不太懂 Linux，这篇文章可以直接照着做。
先说结论：不是“同步”，而是“迁移 + 重建”
一开始我也以为，可以直接把 Cockpit Tools 里的唤醒任务同步到服务器。
后来才发现，两件事其实不一样。
Cockpit Tools 里的唤醒任务，本质上还是由本地程序负责调度。
所以严格来说，我这次并不是：
把 Cockpit Tools 整个搬到 VPS而是：
Cockpit Tools 旧环境
↓
找到两个 Codex 账号的登录状态
↓
迁移到 VPS
↓
两个账号分别使用独立 CODEX_HOME
↓
VPS 使用 systemd 每小时执行一次 codex exec也就是说：
账号状态迁过去，定时任务在服务器上重新建。
这样本地电脑关机以后，VPS 仍然可以自己运行。
我最终做成了什么样？
部署完成后，服务器上大概是这个结构：
VPS
├─ Codex 账号 1
│ └─ 独立 CODEX_HOME
│
├─ Codex 账号 2
│ └─ 独立 CODEX_HOME
│
└─ systemd
├─ codex-wakeup.service
└─ codex-wakeup.timer
↓
每小时执行一次
↓
账号 1 → Codex
账号 2 → Codex最后实现的效果是：
- 两个 Codex 账号互不影响。
- 每小时自动执行一次轻量请求。
- 本地电脑关机也没关系。
- 一个账号失败，不影响另一个继续执行。
- VPS 重启以后任务还会继续。
- 可以随时通过日志确认任务是否执行成功。
后来我还加了一个网页日志看板，不过这个属于可选功能，后面单独说。
我没有重新登录两个账号
这一点是这次迁移里最省事的地方。
因为我之前已经在 Cockpit Tools 里登录好了两个 Codex 账号，所以旧环境里已经保存了它们各自需要的登录状态。
AI 能访问我原来的环境以后，没有让我重新 OAuth 两次。
它先找到了 Cockpit Tools 里两个账号对应的数据，然后把运行 Codex 所需要的登录文件直接迁到了 VPS。
最后分别放到：
/var/lib/codex-wakeup/accounts/account1和：
/var/lib/codex-wakeup/accounts/account2两个账号继续完全隔离。
这里有一个很重要的区别：
迁移登录文件，不等于把 auth.json 发给 AI
不要自己打开：
auth.json然后把里面的 Token、OAuth 信息复制到聊天里。
正确的做法是：
让 AI 在它已经获得授权访问的两台机器之间直接传文件。
例如：
本地 Cockpit Tools 环境
↓
AI 读取文件路径
↓
直接上传到 VPS
↓
重新设置文件权限凭证内容不需要显示在聊天里，也不需要打印到终端。
如果旧环境已经不存在、AI 无法访问，或者登录状态迁过去以后已经失效，再使用：
codex login --device-auth重新授权。
所以我更推荐：
能迁就先迁，迁不了再重新登录。
开始前需要准备什么？
其实不多。
你需要：
- 一台 Ubuntu VPS：RackNerd、CloudCone 都可（我用的是我闲置的 Racknerd VPS）。
- VPS 可以通过 SSH 正常登录。
- 两个能正常使用 Codex 的账号（一个账号也可以，根据自己的账号数量来）。
- VPS 可以正常访问 OpenAI。
- 一个能够直接操作终端、SSH 和文件的 AI Agent / Codex。
如果你和我一样，原来就在 Cockpit Tools 里运行任务，最好让 AI 同时可以访问原来的电脑环境。
这样它才能自己找出：
- Cockpit Tools 的任务配置。
- 两个账号。
- 两个账号对应的登录状态。
- 原来的执行周期。
真正需要我自己做的事情很少
这次部署里，大部分工作都是 AI 完成的。
包括：
- 检查服务器系统。
- 检查 Node.js。
- 检查 Codex CLI。
- 找 Cockpit Tools 的账号数据。
- 找原来的唤醒任务配置。
- 上传两个账号的登录文件。
- 创建专用 Linux 用户。
- 创建两个独立 CODEX_HOME。
- 设置权限。
- 创建运行脚本。
- 创建 systemd service。
- 创建 systemd timer。
- 实际执行两个账号。
- 查看日志。
- 排查错误。
- 检查下一次运行时间。
我真正需要人工处理的，通常只有两种情况。
第一种：
旧登录状态不能用了。
这时候 AI 会运行：
codex login --device-auth然后给我登录网址和验证码。
我自己去浏览器完成授权，再回复：
已完成，继续第二种：
如果后面部署网页看板，而 AI 无法操作云服务器安全组，我自己去开放对应端口。
其他事情，能交给 AI 的就全部交给 AI。
直接把这段提示词交给 AI
下面这段就是我现在更推荐的版本。
把：
<你的服务器IP或SSH别名>换成自己的服务器即可。
你现在是一名 Linux / Ubuntu / systemd / Codex CLI 运维工程师。
请直接操作我的旧 Cockpit Tools 环境和目标 VPS，把现有的两个 Codex 唤醒任务迁移到 VPS。
目标服务器：
<你的服务器IP或SSH别名>
我要实现：
- 两个 Codex 账号继续完全隔离。
- 每个账号每小时执行一次轻量 Codex 请求。
- 优先沿用原 Cockpit Tools 任务中的模型和推理强度。
- 一个账号失败时，另一个仍然继续执行。
- 使用 systemd service + timer。
- 本地电脑关机后不受影响。
- VPS 重启以后任务自动恢复。
- 部署完成后必须真实执行并验证。
【第一步：先检查旧环境】
如果你可以访问原来的 Cockpit Tools 环境：
1. 找到当前启用的 Codex 唤醒任务。
2. 确认任务包含几个账号、执行周期、模型和推理强度。
3. 找到两个账号各自对应的 Codex 登录状态。
4. 确认两个账号原本是分开的。
5. 不要先删除或暂停旧任务。
如果登录状态可用：
优先直接把两个账号运行 Codex 所需要的登录文件安全迁移到 VPS。
要求：
- 不要把 auth.json、OAuth Token 等内容打印到终端或聊天。
- 不要让我手动复制 Token。
- 直接在授权环境之间传输文件。
- VPS 上两个账号必须放在不同 CODEX_HOME。
如果旧环境无法访问、找不到登录状态，或者迁移以后认证已经失效，再使用 codex login --device-auth。
【第二步：检查 VPS】
先检查：
- Ubuntu / Linux 版本
- Node.js
- npm
- Python
- Codex CLI
- codex 真实路径
- 是否已经存在相同用户、目录、service、timer 或类似任务
不要直接覆盖未知配置。
修改已有文件前先备份。
如果 Codex CLI 版本过旧，导致原 Cockpit Tools 使用的模型无法运行，先确认兼容性，再决定是否升级。
【第三步：创建运行环境】
创建专用系统用户：
codex-wakeup
不要长期使用 root 运行 Codex。
使用：
/var/lib/codex-wakeup
作为主要目录。
两个账号分别使用：
/var/lib/codex-wakeup/accounts/account1
/var/lib/codex-wakeup/accounts/account2
工作目录：
/var/lib/codex-wakeup/workspace
两个账号必须使用不同 CODEX_HOME。
迁移登录文件以后，重新设置 owner 和严格文件权限。
【第四步：账号认证】
优先使用迁移过来的登录状态。
分别检查 account1 和 account2 是否仍然有效。
如果有效，不要让我重新 OAuth。
只有下面情况才执行：
codex login --device-auth
- 无法访问旧登录状态
- 迁移失败
- codex login status 显示认证失效
- 实际调用 Codex 证明认证不可用
如果需要 Device Auth，把网址和验证码告诉我，然后暂停。
等我回复：
已完成，继续
再继续后面的部署。
【第五步：创建自动任务】
创建：
/usr/local/libexec/codex-wakeup-run
要求：
- account1 和 account2 依次执行。
- account1 失败以后，account2 仍然继续。
- 两个账号使用各自 CODEX_HOME。
- 请求尽量轻量，例如：
Reply OK only.
Codex 调用尽量使用：
--ephemeral
--skip-git-repo-check
--sandbox read-only
--ignore-user-config
--ignore-rules
工作目录：
/var/lib/codex-wakeup/workspace
然后创建：
codex-wakeup.service
codex-wakeup.timer
要求：
- service 使用 codex-wakeup 用户。
- timer 每小时执行一次。
- 开机自动启用。
- 保留合理的 systemd 安全限制。
- 不要为了省事取消 NoNewPrivileges。
【第六步：真实验证】
不要只创建文件。
必须真实执行一次：
codex-wakeup.service
并确认：
1. account1 实际调用成功。
2. account2 实际调用成功。
3. 日志能看到 Codex 的实际回复。
4. 能看到 tokens used。
5. timer 为 active / enabled。
6. 能看到下一次运行时间。
7. 一个账号失败不会阻止另一个账号。
如果日志出现：
401
451
ERROR
不要只看到这些词就判断失败。
继续检查后面是否仍然出现：
session id
Codex 实际回复
tokens used
以最终完整结果判断。
【第七步：迁移完成以后】
只有 VPS 上两个账号都真实执行成功，并且 timer 正常以后，才暂停原来的 Cockpit Tools 唤醒任务。
不要在 VPS 验证成功以前先删除旧任务。
【最后只告诉我】
- 迁移是否成功
- account1 是否正常
- account2 是否正常
- timer 是否 active / enabled
- 下一次运行时间
- 当前 Codex CLI 版本
- 实际使用模型
- 实际推理强度
- 创建或修改了哪些关键文件
- 原 Cockpit Tools 任务是否已经暂停
- 还有没有需要我本人处理的问题
如果遇到问题，优先自己检查和修复。
只有遇到必须本人处理的 OAuth、密码或云厂商控制台操作时，再停下来找我。我实际部署时踩了 3 个坑
这一部分我觉得比复制 Linux 命令更重要。
因为你真的让 AI 去部署以后，最容易卡住的往往不是“大问题”，而是一些很小的细节。
第一个坑：脚本权限导致 203/EXEC
第一次运行 systemd 的时候，任务直接失败。
日志里出现：
203/EXEC
Permission denied一开始看起来挺吓人，其实跟 Codex 账号完全没关系。
原因只是执行脚本权限设置错了。
脚本一开始是：
0700只有 root 可以执行。
但 systemd service 使用的是：
codex-wakeup专用账号，自然跑不了。
后来 AI 把权限改成：
0755问题马上解决。
所以以后碰到：
203/EXEC先查脚本路径和执行权限，不要上来就重装 Codex。
第二个坑：服务器上的 Codex CLI 太旧
第一次真实执行的时候，两个账号其实已经可以运行。
但 AI 发现服务器默认使用的模型和 Cockpit Tools 原任务不一样。
我原来的任务使用的是：
gpt-5.6-luna
low服务器上的 Codex CLI 当时比较旧。
把模型强制改成原来的配置以后，反而执行失败。
后来检查才发现是 CLI 版本兼容问题。
AI 先备份旧版本，再升级 Codex CLI。
升级以后重新运行：
两个账号都正常返回：
OK所以以后遇到：
Cockpit Tools 能用这个模型，但 VPS 上 Codex CLI 不能用
不要先怀疑账号。
先检查：
codex --version再确认当前 CLI 是否支持这个模型。
第三个坑：日志里有 401 / 451，不一定真的失败
这个非常容易误判。
我的服务器日志里偶尔会看到：
401
451
ERROR如果只看到这几个词，很容易以为任务挂了。
但继续往后看，却仍然有：
session id
OK
tokens used说明最终请求其实成功了。
所以判断 Codex 唤醒任务有没有真正运行成功，不能只搜：
ERROR而应该看完整执行结果。
最简单的方法就是：
最后有没有 Codex 实际回复，有没有 tokens used。
有的话，再结合 systemd 返回码判断。
VPS 跑通以后，再停本地 Cockpit Tools
这个顺序也很重要。
不要刚开始迁移，就先把 Cockpit Tools 里的原任务关掉。
正确顺序应该是：
旧 Cockpit Tools 任务继续保留
↓
VPS 部署
↓
迁移账号
↓
VPS 手动运行一次
↓
确认账号 1 成功
↓
确认账号 2 成功
↓
确认 timer active / enabled
↓
确认下一次运行时间
↓
再暂停本地任务这样即使 VPS 中途部署失败，原来的任务还在，不会两边一起停掉。
怎么判断部署真的完成了？
不用看几十条日志。
最后我只检查这几件事：
account1：正常
account2：正常
timer：active / enabled
下一次运行时间：正常如果还想再严谨一点，再确认：
Codex 实际回复：有
tokens used：有这些都正常，主任务基本就完成了。
可选：再做一个网页日志看板
最开始我只是想解决：
电脑关机以后，Codex 还能不能继续自动唤醒？
systemd 已经把这个问题解决了。
后来我觉得，每次 SSH 上服务器看日志还是有点麻烦。
于是又让 AI 做了一个网页看板。
浏览器打开以后可以直接看到：
- 最近一次运行时间。
- 两个账号分别成功还是失败。
- 使用的模型。
- 推理强度。
- 提示词。
- Codex 回复。
- Token。
- 执行耗时。
- 历史运行。
- 下次运行时间。
- 秒级倒计时。
- systemd 原始日志。
还增加了：
立即执行按钮。
不过这里我建议：
先把自动任务跑通，再做看板。
不要第一次部署就把所有东西都塞给 AI。
如果想让 AI 部署日志看板
可以继续发送：
刚才的 codex-wakeup 已经正常运行。
现在帮我增加一个独立的网页日志看板。
要求：
- 使用 Python 3。
- 程序放在 /opt/codex-dashboard/app.py。
- 使用独立系统用户 codex-dashboard。
- 不要使用 root 运行网页。
- 使用 HTTPS。
- 默认端口 8787。
- 页面需要登录保护。
- 页面能查看两个账号最近运行结果。
- 能查看历史执行。
- 能查看模型、推理强度、提示词、回复、Token 和耗时。
- 能看到下一次运行的北京时间，精确到秒。
- 显示剩余倒计时。
- 日志按照时间倒序，最新日志显示在最上面。
- 手机和电脑都要正常显示。
- 原始 systemd 日志默认折叠。
- 不要展示 OAuth Token、auth.json 或其他敏感信息。
再增加一个“立即执行”按钮。
安全要求：
- 网页程序不能获得任意 root / sudo / shell 权限。
- 保留 NoNewPrivileges。
- 网页只能创建一个固定的请求文件。
- 使用 systemd path unit 监听请求文件。
- root service 只能启动 codex-wakeup.service。
- 页面不能传入任意 shell 命令。
- “立即执行”需要二次确认。
- 加入登录和 CSRF 检查。
- 如果任务正在运行，不允许重复启动。
部署前：
先读取现有环境。
如果已有 app.py，先备份。
部署后必须真实验证：
- dashboard service 正常
- 登录正常
- 错误密码无法登录
- 两个账号结果展示正确
- 下次运行时间正确
- 日志为倒序
- “立即执行”真实运行成功
- 手机页面正常
- 浏览器没有明显 JavaScript 错误
最后只告诉我：
- 看板是否成功
- 访问地址
- 服务状态
- 端口是否已放行
- 是否需要我手动配置云安全组
- 有没有安全风险这一步属于增强体验，不影响前面的自动唤醒任务。
最后再记住 6 件事
整篇教程里，我觉得真正值得记住的不是具体 Linux 命令，而是这 6 条。
1. 不要把 auth.json 发到聊天里
包括：
OAuth Token
refresh token
Session Secret
密码都不要主动复制进去。
2. 两个账号必须使用不同 CODEX_HOME
例如：
account1
account2必须完全分开。
否则两个账号的登录状态很容易互相覆盖。
3. 定时任务不要长期使用 root
专门创建：
codex-wakeup用户来运行。
4. 先验证 VPS，再停旧任务
服务器没有真实跑通以前，原来的 Cockpit Tools 唤醒任务不要急着删。
5. 看板不要拿任意 sudo 权限
网页能显示日志，不代表它就应该获得 root。
如果需要“立即执行”，只给它一个固定、安全的触发入口。
6. AI 修改生产文件之前先备份
尤其是：
app.py
systemd 配置
运行脚本先备份，再改。
出问题还可以直接回滚。
最后
我这次最大的感受其实不是：
我终于学会了 systemd。
恰恰相反。
这些东西我还是没有准备自己一点一点研究。
我真正做的是先把三件事情想清楚：
我要什么结果。
哪些东西 AI 不能乱碰。
最后满足什么条件才算真的成功。
然后把这些告诉 AI。
环境检查、账号迁移、SSH、权限、systemd、CLI 升级、日志排错、网页部署这些事情，让 AI 自己去处理。
以前做这种 VPS 项目，可能要对着教程复制几十条命令。
现在更适合 AI 小白的方式是：
我说清楚目标
↓
AI 检查环境
↓
AI 自己执行
↓
遇到必须人工授权时叫我
↓
AI 继续部署
↓
AI 自己验证
↓
最后把结果告诉我会不会 Linux 已经没那么重要了。
更重要的是：
你能不能把目标、边界和验收标准说清楚，然后让 AI 真正把事情做完。
推荐文章
近期其他 VPS 优惠活动
- CloudCone & RackNerd 2026 VPS 年货节：$11.29/年抄底价，最后72小时，错过再等一年
- RackNerd 双十一&CloudCone黑色星期五超便宜VPS套餐上线，DC02 机房来袭！
- CloudCone 2026 新年 VPS 促销：位于美国洛杉矶的最低 10.24 美元/年
- CloudCone VPS圣诞节促销活动正在进行中，错过只能等明年了。
- CloudCone 2025 年黑色星期五超级促销活动，错过还得等一年！
- 双十一攻略：搬瓦工发布11%折扣码，高端VPS线路现在入手最划算
- RackNerd 2025年黑色星期五超便宜VPS套餐上线，洛杉矶DC-02来袭
- 【VoyraCloud 2025黑五活动】高性能便宜VPS五折低至$2.5/月，可选纯净原生住宅IP
AI 提示词
AI 工具
- 龙虾大战8款产品全拆解，我用了一周OpenClaw，说点真话
- LibTV免费能用吗？我花了170万Token试了一下
- GLM-4.7 可以平替 Claude Code 的国产编码大模型
- 价值 $300 的 Google AI Pro，0 元白嫖12个月 Google Gemini 学生优惠完全指南（截止到 2026年1月31日）
- Google 羊毛：免费领 1 个月 Gemini 3、Nano Banana Pro 和 Veo 3 会员
- 12个免费白嫖 Nano Banana Pro 的方法，亲测有用
- 网盘拉新项目：打造没有天花板的被动收入（附资源+教程）
- Claude Code 进阶秘籍：手把手教你创建专属 Skills，效率翻倍！
- 干翻 Copilot？Chrome 这个隐藏功能，我踩坑 3 次终于开启了！（结尾有福利）
SEO+网站
你觉得这篇文章怎么样？
共有 0 条评论