如果你已经租了一台 Linux VPS，想把它当成一台随时在线的远程开发机，Codex CLI 是一个很实用的入口：SSH 登录后直接在项目目录里读代码、改文件、跑测试。真正容易踩坑的地方不是 npm install，而是无桌面环境下怎么认证、如何限制权限，以及进程断线后怎么继续。
这篇文章以 Ubuntu 22.04/24.04 和 Debian 12 为例，从一台干净 VPS 配到可以长期使用的 Codex CLI。命令都可以复制执行，但 API Key、项目路径和 Linux 用户名请换成你自己的值。
Codex CLI 本身不需要很高的 CPU，主要消耗来自 Node.js、代码索引、测试命令和你同时运行的服务。个人项目建议从下面的配置起步：
| 用途 | 建议配置 | 说明 |
|---|---|---|
| 小型脚本、静态站点 | 2 核 / 2GB / 40GB SSD | 适合边改边跑测试 |
| Node、Python 全栈项目 | 2-4 核 / 4GB / 60GB NVMe | 给依赖安装和构建留余量 |
| 多仓库或 Docker 项目 | 4 核 / 8GB / 80GB NVMe | 同时跑数据库、测试和构建更稳 |
内存只有 1GB 也能安装，但 npm install、TypeScript 编译或 Docker 构建很容易触发 OOM。生产业务和 Codex 工作目录最好分开，至少创建一个普通用户，不要让编码代理一直在 root 目录里操作。
先用 SSH 登录，并更新系统：
ssh root@YOUR_SERVER_IP
apt update && apt full-upgrade -y
apt install -y ca-certificates curl git build-essential unzip tmux
创建工作用户：
adduser coder
usermod -aG sudo coder
mkdir -p /srv/workspaces
chown -R coder:coder /srv/workspaces
su - coder
如果你还没有配置 SSH 密钥，先完成密钥登录再关闭密码登录。排查 Permission denied 时，可以参考 VPS SSH Permission denied 排查清单。不要在 Codex 部署完成前把 22 端口直接暴露给所有来源而不做任何限制。
Codex CLI 官方支持 npm 安装。生产 VPS 不建议直接使用发行版自带的旧 Node.js，先安装 NodeSource 的 LTS 版本：
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs
node --version
npm --version
确认 Node.js 版本达到项目要求后安装 Codex：
sudo npm install --global @openai/codex
codex --version
升级也很简单：
sudo npm update --global @openai/codex
如果系统禁止全局 npm 写入，可以使用 nvm 安装 Node.js，再以 coder 用户执行全局安装。不要为了省事把整个 /usr 目录改成 777。
Codex CLI 支持 ChatGPT 登录和 API Key 登录。带桌面的电脑上运行 codex login，浏览器会打开授权页面；纯 SSH 的 VPS 通常没有浏览器，API Key 更适合自动化或远程机器。
在 VPS 的项目目录执行：
mkdir -p /srv/workspaces/demo && cd /srv/workspaces/demo
codex login
如果终端给出授权 URL，用本地电脑浏览器打开，完成登录后回到 SSH 会话。不同版本的 CLI 可能显示略有差异，按终端提示操作即可。登录状态可以检查：
codex login status
API Key 不要直接写进 shell 历史。用受保护的环境变量通过标准输入传给 CLI：
read -s OPENAI_API_KEY
printf '%s' "$OPENAI_API_KEY" | codex login --with-api-key
unset OPENAI_API_KEY
codex login status
如果要给 systemd 或 CI 使用，把 Key 放在只有 coder 可读的凭据文件中：
mkdir -p /home/coder/.config
install -m 600 /dev/null /home/coder/.config/codex.env
printf 'OPENAI_API_KEY=replace-me\n' > /home/coder/.config/codex.env
不要把 .config/codex.env 提交到 Git，也不要把 Key 放进 ~/.bashrc 后再截图或贴到工单里。API Key 登录按 API 用量计费，适合脚本和持续集成；ChatGPT 登录则使用对应 ChatGPT 工作区的权限和额度。具体认证行为以 OpenAI Docs 的 Codex CLI 文档 和 Authentication 为准。
切换到代码仓库：
cd /srv/workspaces/demo
git clone YOUR_REPOSITORY_URL .
git status
codex
首次对话建议先让 Codex 只读检查项目，再允许修改：
先阅读项目结构和 README，只告诉我启动命令，不要修改文件。
确定工作目录后，再提出一个小改动并要求运行测试。工作区权限越小越好：不要把 /etc、数据库备份目录或云厂商凭据目录放进 Codex 的工作目录。涉及生产项目时，先创建 Git 分支或提交检查点，方便回滚。
直接运行 codex，SSH 断开后进程通常也会结束。最简单的做法是使用 tmux：
tmux new -s codex
cd /srv/workspaces/demo
codex
按 Ctrl+b，再按 d 退出会话但保持进程运行；重新登录后恢复：
tmux attach -t codex
查看现有会话：
tmux ls
tmux 适合人工操作，不建议把一个需要确认权限的交互式编码代理做成无人值守的开机服务。若只是运行固定的 codex exec 脚本，才考虑 systemd，并给服务设置独立用户、工作目录、资源限制和只读凭据。
通常是 npm 全局目录没有在 PATH 中，先定位：
npm prefix --global
which node
which npm
用 sudo 全局安装时，确认 /usr/bin 或 npm bin 目录在当前用户 PATH 中；使用 nvm 时，重新加载对应 shell 配置。
检查仓库所有者和目录权限：
whoami
ls -ld /srv/workspaces/demo
sudo chown -R coder:coder /srv/workspaces/demo
不要用 chmod -R 777 解决权限问题，这会把源码、.env 和 SSH 配置一起暴露给同机其他用户。
先看内存和 OOM 日志：
free -h
dmesg -T | grep -i -E 'oom|killed process'
2GB VPS 可以临时增加 2GB swap，但 swap 不能替代真正的内存。构建任务很多时，升级到 4GB 比反复重试更省时间。
确认执行登录和运行 Codex 的是同一个 Linux 用户，并检查状态：
whoami
codex login status
不要用 root 登录 Key、再切换到 coder 用户运行；两套用户的凭据目录不同。
node --version和codex --version能正常返回；coder用户可以读写项目，但不拥有不必要的系统目录权限；- 已选择 ChatGPT 登录或 API Key 登录，并能通过
codex login status验证； - API Key 文件权限为
600，且已加入.gitignore； - 交互式会话在 tmux 中运行，SSH 断开后可以恢复；
- 修改前有 Git 分支或提交，测试命令和回滚路径都清楚；
- Docker 项目另行配置 healthcheck、日志和资源上限，可继续参考 VPS Docker Compose 生产环境配置清单。
VPS 上跑 Codex CLI 的核心不是把机器配置得多豪华，而是把认证、用户权限和会话持久化做好。小项目 2 核 2GB 就能开始；如果要同时跑 Docker、数据库和构建任务，直接选 4 核 8GB，少花时间排查 OOM。