Codex 使用小 Tip：VPN 不稳定？直接把 CLI 放到服务器上

VPN 连 Codex 不稳定，最烦的不是慢，而是写到一半突然断线。

页面卡住、请求超时、终端重连，思路全被打断。尤其是让 Codex 跑一段时间的代码分析、项目改造时，本地网络一抖，前面的等待基本白费。

一个更稳的办法是：

直接在网络稳定的服务器上运行 Codex CLI。

你只需要通过 SSH 连上服务器，在服务器终端里操作 Codex。电脑本地只负责显示终端，不再承担主要的网络请求。

这样做有什么好处？

1. 少受本地 VPN 波动影响

Codex CLI 的请求从服务器发出。

你的电脑和服务器之间只保持 SSH 连接。即使本地网络偶尔抖一下，也比直接通过浏览器或本地 CLI 连接稳定得多。

当然，服务器本身也要有稳定的外网环境。别把 Codex 搬到一台连网页都打不开的机器上，那只是换了个地方报错 😅

2. 终端响应更利落

服务器通常具备更稳定的带宽和更低的网络延迟。

代码读取、文件修改、命令执行这类操作，往往会比本地反复经过 VPN 更顺畅。具体速度取决于服务器线路、地区和当前网络状况，不是部署上去就一定变成“光速”。

3. 任务可以长时间运行

服务器适合运行耗时任务。

比如：

扫描一个大型项目
批量重构代码
运行测试并修复报错
分析日志文件
让 Codex 持续处理多个任务

配合 tmux 或 screen，即使你退出 SSH，任务也能继续跑。晚上关电脑，第二天回来还能接着看结果。

基础使用流程

第一步：准备一台服务器

建议选择：

网络稳定的 Linux 服务器
能正常访问 Codex 服务的地区或线路
至少 2 核 CPU、4GB 内存
磁盘空间足够放项目和依赖
已安装 Git、Node.js 或项目需要的运行环境

如果只是处理小项目，配置不用堆太高。别为了跑一个 CLI，买一台像服务器机房一样夸张的机器。

第二步：SSH 登录服务器

在本地终端执行：

ssh username@your-server-ip

如果 SSH 使用了自定义端口：

ssh -p 2222 username@your-server-ip

登录成功后，确认当前环境：

uname -a
pwd

接着进入项目目录：

cd /path/to/your-project

第三步：安装并登录 Codex CLI

按照你当前使用的 Codex CLI 安装方式，在服务器上完成安装和认证。

安装完成后，可以先确认命令是否可用：

codex --help

认证信息建议使用环境变量、官方登录流程或服务器上的安全凭据管理方式。不要把 API Key 直接写进代码，也不要提交到 Git 仓库。

可以检查环境变量是否存在，但不要把密钥内容打印出来：

test -n "$OPENAI_API_KEY" && echo "API Key 已配置" || echo "API Key 未配置"

第四步：启动 Codex CLI

进入项目目录后运行：

codex

如果你的 CLI 支持指定任务，也可以直接输入具体需求，例如：

检查当前项目的登录流程，找出可能导致 session 丢失的问题，并给出修改方案。先不要直接改文件。

建议一开始加上限制：

先分析，不要立即修改
只处理指定目录
修改前展示 diff
不要删除文件
执行测试前先说明命令

这几句话看似啰嗦，能少踩很多坑。尤其是老项目，别让工具一上来就“热心”地重构半个代码库。

用 tmux 保持任务运行

直接 SSH 跑任务有个问题：网络一断，终端可能就没了。

可以使用 tmux。

创建会话

tmux new -s codex-task

进入 Codex 工作目录：

cd /path/to/your-project
codex

临时退出，但不停止任务

按下：

Ctrl + B，然后按 D

你会回到普通 Shell，但 Codex 仍在服务器里运行。

重新连接会话

tmux attach -t codex-task

查看已有会话：

tmux ls

这个组合特别适合需要运行几十分钟甚至几小时的任务。

一个更稳的工作习惯

你可以按下面的流程操作：

SSH 登录服务器
创建一个独立的 tmux 会话
进入项目目录
查看 Git 当前状态
让 Codex 先分析，不直接改代码
确认方案后，再允许修改
运行测试
查看 git diff
提交或回滚改动

开始前先检查 Git 状态：

git status
git branch --show-current

任务完成后查看修改内容：

git diff
git status

如果改动不符合预期，可以快速回滚未提交的文件：

git restore path/to/file

这一步别省。AI 写代码快，改错也快。没有 Git 记录，后面排查会非常痛苦。

关于 Token 消耗，别盲目乐观

在服务器上运行 CLI，确实可能让整体交互更高效，也能减少重复请求和网络重试带来的浪费。

但 Token 消耗主要还是取决于：

发送了多少上下文
项目文件规模
是否反复让它读取同一批文件
是否频繁推翻前面的方案
使用的模型和调用方式

服务器不会自动让 Token 变少。

真正有效的做法是缩小任务范围：

只检查 src/auth 目录，不要读取 node_modules 和 dist。先定位登录状态丢失的原因，输出涉及的文件和修改建议，不要直接改代码。

范围越清楚，来回沟通越少，Token 通常也更省。

安全设置别偷懒

服务器上可能存放源码、密钥和生产配置。运行 Codex CLI 前，建议做好这几件事：

不要把生产环境密钥放进项目目录
不要让工具默认读取 .env.production
给服务器单独创建低权限用户
使用 SSH Key，关闭弱密码登录
配置防火墙，只开放必要端口
代码仓库使用最小权限 Token
任务结束后清理临时文件和日志
涉及生产环境时，先备份再操作

如果只是测试项目，可以准备一份脱敏副本。别把真实数据库连接串、用户隐私和内部密钥直接喂给工具。

常见问题排查

Codex 命令找不到

检查安装路径：

which codex

查看当前用户的环境变量：

echo "$PATH"

如果你用的是 Node.js 安装方式，还要确认当前 Node 版本和包管理器配置正常。

SSH 断开后任务停止

大概率是没有使用 tmux 或 screen。

重新创建会话后再运行：

tmux new -s codex-task

服务器上依旧连接失败

检查服务器网络：

curl -I https://example.com

再确认：

服务器地区是否支持相关服务
DNS 是否正常
防火墙是否限制外连
环境变量是否配置正确
系统时间是否准确

服务器能 SSH 登录，不代表它一定能正常访问 Codex 服务。网络权限是两回事。

避坑清单

不要把 API Key 写进 Shell 历史记录
不要在生产目录里随意执行自动修改
不要让 Codex 默认扫描整个服务器
不要跳过 git diff
不要只依赖浏览器终端运行长任务
不要认为服务器部署后就一定省 Token
不要把 SSH 端口、密钥和服务器地址发到公开群聊
不要让多个任务共用一个混乱的工作目录

适合用服务器跑 Codex 的场景

如果你遇到下面这些情况，可以优先考虑服务器方案：

本地 VPN 经常断
笔记本合盖后任务无法继续
项目体积较大，本地读取很慢
需要让任务运行几个小时
经常在不同电脑之间切换
希望把开发环境统一放在远程机器上

简单说：本地电脑负责连接，服务器负责干活。这个分工通常更省心。

把 Codex CLI 放到服务器上，不是为了追求复杂配置，而是为了让任务少被网络打断。配合 SSH、tmux、Git 和基本的权限管理，你就能搭出一套稳定的远程 AI 编程环境。