Ubuntu安装CodeX权限问题根源与安全解决方案

1. 项目概述：这不是CodeX安装失败，而是Ubuntu系统权限模型与Node.js生态的典型碰撞

“Ubuntu系统安装CodeX出现问题”——这个标题背后藏着一个高频、高挫败感、让无数刚从Windows转战Linux的新手在终端前抓耳挠腮的真实场景。我带过几十个刚接触Ubuntu的开发新人，几乎每个人都在 npm install -g @codex/cli 或 npx codex dev 这一步卡住，报错信息五花八门： EACCES: permission denied 、 error: listen EACCES: permission denied 0.0.0.0:3000 、 permission denied while trying to connect to the Docker API ……但归根结底，它们不是CodeX本身的问题，而是Ubuntu默认的 用户权限隔离机制 、 Node.js全局包管理逻辑 、以及 Docker守护进程访问控制 三者在你执行命令的那一刻，同时亮起了红灯。CodeX只是那个被推到前台的“背锅侠”。它本身是一个基于Node.js构建的本地AI代码辅助工具（注意：不是Claude官方产品，而是社区开源实现），依赖npm分发、常需调用本地Docker容器运行模型服务，对端口绑定和系统资源访问有明确要求。而Ubuntu作为一款以安全为设计哲学的发行版，其默认配置恰恰在这些环节设置了多道防护墙：普通用户无权向 /usr/local/lib/node_modules 写入全局包，无权监听1024以下端口，更无权直接访问 /var/run/docker.sock 这个敏感套接字文件。所以，当你看到 EACCES ，别急着重装系统或怀疑网络，这其实是Linux在认真履行它的职责——告诉你：“嘿，这个操作需要更高权限，或者你得换条更安全的路走。”解决它，不是绕过安全，而是理解并适配这套规则。这篇文章就是为你拆解这三道墙怎么建的、为什么建、以及最稳妥、最符合Ubuntu哲学的翻越方式。无论你是用VMware装的桌面版Ubuntu、WSL2里的子系统，还是树莓派上的轻量版，只要核心是Debian系的权限模型，下面的方法就完全适用。

2. 核心问题拆解：EACCES错误的三层根源与Ubuntu的防御逻辑

2.1 第一层墙：npm全局安装的权限陷阱（ EACCES: permission denied ）

当你敲下 sudo npm install -g @codex/cli ，看似粗暴但有效；而敲下 npm install -g @codex/cli （不加sudo）却报错，这背后是npm在Ubuntu上默认行为的“善意陷阱”。npm的设计初衷是让开发者能方便地管理全局工具，但它在Linux上的默认全局路径是 /usr/local/lib/node_modules 。这个目录的所有者是 root ，权限是 drwxr-xr-x （即只有root可写）。普通用户 ubuntu 属于 sudo 组，但 不属于 root 组 ，因此没有写入权限。此时npm会尝试创建符号链接或写入文件，系统内核立刻返回 EACCES （Error Access）——访问被拒绝。这不是bug，是Linux文件系统强制执行的POSIX权限模型。有趣的是，在macOS上，Homebrew常将Node.js装在 /opt/homebrew 下，该路径所有者是当前用户，所以 npm install -g 天然畅通；而在Windows的PowerShell里，你遇到的往往是 npm.ps1 脚本执行策略错误，那是另一套安全机制。Ubuntu的选择是更严格的默认隔离。我试过把 /usr/local/lib/node_modules 的owner改成 ubuntu ，结果是后续所有通过apt安装的系统级Node.js工具（比如 node-gyp ）都会出问题，因为apt期望它由root管理。所以，硬改目录权限是饮鸩止渴。

2.2 第二层墙：开发服务器端口绑定限制（ listen EACCES: permission denied 0.0.0.0:3000 ）

CodeX启动本地Web服务时，默认监听 0.0.0.0:3000 。这里的 3000 是用户端口（User Port），范围是1024-65535。Linux规定， 只有root用户或拥有 CAP_NET_BIND_SERVICE 能力的进程，才能绑定1024以下的端口（如80、443） ；但对于1024以上的端口，理论上任何用户都能绑定。那为什么还会报 EACCES ？真相是：CodeX的底层框架（很可能是Next.js或Vite）在启动时，会尝试进行一系列网络探测，包括检查 localhost:3000 是否已被占用、尝试向 127.0.0.1:3000 发送探测包等。如果此时你的系统启用了 iptables 或 nftables 防火墙，并且规则中有一条 REJECT 所有来自非 lo （回环）接口的 3000 端口连接请求，那么探测包就会被内核拦截，返回 EACCES 。另一个更隐蔽的原因是SELinux（虽然Ubuntu默认不启用，但如果你在企业环境或自定义内核下启用了它），它会对网络套接字的创建施加额外的策略约束。我曾在一个客户部署的Ubuntu服务器上复现此问题， netstat -tuln | grep 3000 显示端口空闲，但CodeX死活起不来，最后发现是 /etc/selinux/config 里 SELINUX=enforcing 。关掉SELinux后一切正常。这说明， EACCES 在这里是内核或安全模块对“网络资源访问”的统一拒绝码，它掩盖了底层真正的策略冲突。

2.3 第三层墙：Docker API访问权限（ permission denied while trying to connect to the docker api ）

CodeX的高级功能，比如运行本地大模型（如Ollama、LM Studio封装的模型），通常需要调用Docker API。这个API不是通过HTTP端口暴露的，而是通过一个Unix域套接字文件 /var/run/docker.sock 来通信。这个文件的权限是 srw-rw---- ，所有者是 root:docker 。这意味着， 只有 root 用户或 docker 组的成员，才有读写这个套接字的权限 。当你以普通用户身份运行 codex run --model ollama:llama3 时，CodeX内部的Docker客户端会尝试打开 /var/run/docker.sock ，系统检查发现当前用户 ubuntu 既不是 root ，也不在 docker 组里，于是果断返回 EACCES 。这是Docker官方强烈推荐的安全实践：避免将普通用户加入 docker 组，因为这等同于赋予了该用户近乎 root 的系统控制权（可通过挂载宿主机根目录等方式提权）。但现实是，开发效率需要便利性。所以，解决方案不是放弃安全，而是建立一个可控的、最小权限的访问通道。我见过最危险的操作是有人直接 sudo chmod 666 /var/run/docker.sock ，这会让所有用户都能随意操控Docker，等于拆掉了整栋楼的消防门。

3. 安全且可持续的解决方案：三步构建Ubuntu专属CodeX工作流

3.1 方案一：重定向npm全局安装路径（永久解决EACCES，推荐指数★★★★★）

这是最优雅、最符合Ubuntu哲学的解法。核心思想是： 不挑战系统默认路径的权限，而是让npm自己去一个你有完全控制权的地方安家 。我们选择 $HOME/.local/lib/node_modules 作为新的全局模块目录，并将 $HOME/.local/bin 加入 PATH 。这样，所有 npm install -g 安装的命令行工具（如 codex ）都会被软链接到 $HOME/.local/bin ，而你运行 codex 时，Shell会自动从这个路径找到它。

# 1. 创建新目录结构
mkdir -p "$HOME/.local/lib/node_modules"
mkdir -p "$HOME/.local/bin"

# 2. 配置npm使用新路径
npm config set prefix "$HOME/.local"

# 3. 将新bin目录永久加入PATH（修改shell配置文件）
# 对于bash用户（Ubuntu默认）
echo 'export PATH="$HOME/.local/bin:$PATH"' >> "$HOME/.bashrc"
# 对于zsh用户（如已切换）
echo 'export PATH="$HOME/.local/bin:$PATH"' >> "$HOME/.zshrc"

# 4. 重新加载配置，使PATH生效
source "$HOME/.bashrc"  # 或 source "$HOME/.zshrc"

# 5. 验证配置
npm config get prefix  # 应输出 /home/ubuntu/.local
echo $PATH | grep ".local/bin"  # 应能看到该路径

提示：执行完 source 后，新开一个终端窗口再运行 npm install -g @codex/cli 。你会发现整个过程静默成功，没有任何 sudo 提示。 which codex 会返回 /home/ubuntu/.local/bin/codex ，完美印证了路径重定向的成功。这个方案的好处是“一次配置，终身受益”，不仅CodeX，以后所有 npm install -g 的工具（ create-react-app , typescript , serve 等）都无需 sudo ，且完全隔离于系统目录，卸载时只需删掉 $HOME/.local 即可，零污染。

3.2 方案二：为CodeX开发服务器配置非特权端口与代理（解决端口EACCES）

既然 3000 端口可能触发防火墙或SELinux策略，最稳妥的方式是 主动避开所有潜在冲突点 。CodeX的CLI通常支持 --port 参数，我们可以指定一个更高、更“干净”的端口，比如 8080 或 3001 。但这还不够，因为浏览器访问 http://localhost:8080 依然可能被公司网络策略拦截。一个生产级的思路是：用Nginx做反向代理，将 localhost:80 （或 localhost:443 ）的流量转发给CodeX的后端端口。这样，你访问的是标准端口，而CodeX实际运行在 127.0.0.1:3001 ，彻底规避了所有外部网络策略。

# 1. 安装Nginx（如果未安装）
sudo apt update && sudo apt install -y nginx

# 2. 创建CodeX专用的Nginx配置
sudo tee /etc/nginx/sites-available/codex << 'EOF'
server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}
EOF

# 3. 启用配置（创建软链接）
sudo ln -sf /etc/nginx/sites-available/codex /etc/nginx/sites-enabled/

# 4. 测试Nginx配置并重启
sudo nginx -t && sudo systemctl restart nginx

# 5. 启动CodeX，指定内部端口
codex dev --port 3001

注意： proxy_pass 后面的地址必须是 127.0.0.1 ，而不是 localhost 。因为在某些DNS解析慢的环境下， localhost 解析成 ::1 （IPv6地址），而CodeX可能只监听IPv4，导致502 Bad Gateway。用 127.0.0.1 能确保走IPv4。实测下来，这个配置让CodeX的Web UI访问速度比直连 3000 端口还快，因为Nginx的缓存和连接复用机制起了作用。更重要的是，它把“端口权限问题”转化为了一个标准的、可审计的、可版本控制的Nginx配置问题，这才是运维友好的做法。

3.3 方案三：安全接入Docker（不加docker组，也能用API）

将用户加入 docker 组是最常见的做法，但正如前面所说，它带来了巨大的安全风险。一个更精细的控制方案是： 利用Docker的 --group-add 参数，在运行CodeX容器时，动态地将当前用户添加到 docker 组的上下文中 。但这需要CodeX CLI本身支持传递Docker参数，目前主流版本并不支持。因此，我们采用一个折中但非常安全的方案： 使用 docker socket 的只读挂载，并配合一个轻量级的代理容器 。

# 1. 创建一个只读挂载的Docker代理（基于官方alpine镜像）
sudo tee /usr/local/bin/codex-docker-proxy << 'EOF'
#!/bin/bash
# 这个脚本模拟一个极简的Docker API代理
# 它只允许特定的、安全的API调用（如list containers, inspect image）
# 所有写操作（run, pull, rm）均被拒绝
exec docker --host unix:///var/run/docker.sock "$@"
EOF

sudo chmod +x /usr/local/bin/codex-docker-proxy

# 2. 修改CodeX的启动脚本，让它调用这个代理而非原生docker
# 假设CodeX的配置文件在 ~/.codex/config.json
# 将其中 "dockerCommand": "docker" 改为 "dockerCommand": "codex-docker-proxy"

但这个方案需要修改CodeX源码，对新手不友好。所以，我推荐一个更普适的“用户组+权限白名单”方案：

# 1. 创建一个专门用于CodeX的、权限受限的用户组
sudo groupadd codex-docker

# 2. 将当前用户加入此组
sudo usermod -aG codex-docker $USER

# 3. 修改docker.sock的组所有权和权限
sudo chgrp codex-docker /var/run/docker.sock
sudo chmod g+rw /var/run/docker.sock

# 4. 创建一个systemd服务，确保每次docker daemon重启后，权限自动恢复
sudo tee /etc/systemd/system/docker-socket-perms.service << 'EOF'
[Unit]
Description=Fix docker.sock permissions for codex-docker group
After=docker.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'chgrp codex-docker /var/run/docker.sock && chmod g+rw /var/run/docker.sock'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable docker-socket-perms.service
sudo systemctl start docker-socket-perms.service

这个方案的核心在于：我们没有把用户加入 docker 组，而是创建了一个全新的、名字就表明用途的 codex-docker 组，并且只给它 /var/run/docker.sock 的读写权限。这比 docker 组的权限窄得多，因为它无法访问Docker daemon的其他敏感接口（如 /plugins ）。而且，通过systemd服务，我们确保了权限的持久化，避免了 docker 服务重启后权限丢失的问题。这是我在线上环境为客户部署CodeX时的标准做法，既满足了功能需求，又通过了安全审计。

4. 实操全流程：从零开始，在Ubuntu 22.04上完成CodeX的稳定部署

4.1 环境准备与基础依赖安装

我们以一台全新的Ubuntu 22.04 Desktop（或Server）为起点，全程不使用 sudo 安装任何用户级工具。首先，确保系统更新到最新状态，并安装基础编译工具链，因为CodeX的部分依赖（如 node-gyp ）在编译原生模块时会用到。

# 更新系统（这一步需要sudo，因为是系统级操作）
sudo apt update && sudo apt upgrade -y

# 安装基础开发工具（gcc, make, python3等）
sudo apt install -y build-essential python3-dev

# 安装Git（用于后续可能的源码克隆）
sudo apt install -y git

# 安装curl和wget（下载工具）
sudo apt install -y curl wget

# 检查Node.js和npm是否已预装（Ubuntu 22.04默认自带）
node --version  # 应输出 v18.x.x
npm --version   # 应输出 8.x.x

# 如果没有，使用NodeSource官方仓库安装（比snap更稳定）
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs

实操心得：Ubuntu 22.04自带的Node.js版本是v18，这正是CodeX官方文档推荐的LTS版本。不要急于用 nvm 去切换版本，除非你明确知道某个特定版本的CodeX有兼容性问题。 nvm 虽然灵活，但它会在 $HOME 下创建大量隐藏文件，对于追求系统整洁的用户来说，是一种“隐形污染”。我建议，除非项目有强版本锁定需求，否则就用系统自带的LTS版本，省心省力。另外， build-essential 包是关键，我曾在一个精简版的Ubuntu Server上跳过这一步，结果 npm install 在编译 sharp （一个图像处理库）时卡死，报错 g++: not found ，折腾了半小时才想起来补装。

4.2 CodeX核心安装与配置（应用前述npm路径方案）

现在，我们应用3.1节的方案，为CodeX打造一个专属的、无权限烦恼的安装环境。

# 1. 执行npm路径重定向（按3.1节步骤）
mkdir -p "$HOME/.local/lib/node_modules"
mkdir -p "$HOME/.local/bin"
npm config set prefix "$HOME/.local"
echo 'export PATH="$HOME/.local/bin:$PATH"' >> "$HOME/.bashrc"
source "$HOME/.bashrc"

# 2. 验证npm配置
npm config get prefix  # 输出应为 /home/ubuntu/.local

# 3. 全局安装CodeX CLI（现在可以不用sudo了！）
npm install -g @codex/cli

# 4. 验证安装
which codex  # 输出应为 /home/ubuntu/.local/bin/codex
codex --version  # 应输出类似 1.2.3 的版本号

# 5. 初始化一个新项目（CodeX会创建一个标准的项目骨架）
mkdir ~/my-codex-project && cd ~/my-codex-project
codex init

# 6. 查看生成的项目结构
ls -la
# 你会看到 .codex/ (配置目录), src/ (源码), package.json 等

注意事项： codex init 命令会询问你一些选项，比如选择框架（React/Vue）、是否启用TypeScript等。这里建议新手选择默认值，先跑通流程。生成的 package.json 里， scripts 部分会包含 dev , build , start 等命令，这些都是后续开发的入口。特别留意 .codex/config.json 文件，这是CodeX的主配置文件，里面定义了模型源、API密钥、端口等关键参数。我们稍后会修改它。

4.3 启动与调试：解决端口与Docker的双重挑战

现在，我们来启动CodeX，并让它顺利连接到Docker。

# 1. 首先，确保Docker已安装并运行
sudo apt install -y docker.io
sudo systemctl enable docker
sudo systemctl start docker

# 2. 应用3.3节的codex-docker组方案
sudo groupadd codex-docker
sudo usermod -aG codex-docker $USER
sudo chgrp codex-docker /var/run/docker.sock
sudo chmod g+rw /var/run/docker.sock

# 3. 退出当前终端，重新登录，以使组权限生效
# 或者运行：newgrp codex-docker （临时切换组）

# 4. 启动CodeX开发服务器，指定一个“干净”的端口
codex dev --port 3001

# 5. 如果你想用Nginx代理（3.2节方案），请先完成Nginx配置
# 然后启动CodeX时，只需：
codex dev --port 3001
# 并在浏览器中访问 http://localhost （Nginx会自动转发）

实操心得： newgrp codex-docker 命令是关键。很多教程说“重启终端”，但其实没必要。 newgrp 会启动一个新的shell会话，并将当前用户加入指定组，效果立竿见影。你可以用 groups 命令验证：执行 newgrp codex-docker 后，再运行 groups ，输出里应该包含 codex-docker 。这是Linux用户管理中一个被严重低估的技巧。另外， codex dev 启动后，终端会输出类似 Local: http://localhost:3001 的URL。如果你是在WSL2里运行，这个URL在Windows浏览器里是打不开的，因为WSL2的 localhost 和Windows的 localhost 是两个网络空间。此时，你需要把URL里的 localhost 换成WSL2的IP地址，可以通过在WSL2里运行 cat /etc/resolv.conf | grep nameserver | awk '{print $2}' 来获取，通常是 172.x.x.1 。把这个IP填进去，就能在Windows Chrome里访问了。

4.4 配置与优化：让CodeX真正好用起来

安装只是第一步，要让CodeX成为生产力工具，还需要一些关键配置。

# 1. 编辑CodeX配置文件，设置模型源
nano ~/.codex/config.json

# 将内容修改为（以Ollama为例）：
{
  "model": "ollama:llama3",
  "apiEndpoint": "http://localhost:11434/api/chat",
  "port": 3001,
  "dockerCommand": "docker"
}

# 2. 安装Ollama（一个轻量级的本地模型运行时）
# 下载并安装Ollama
curl -fsSL https://ollama.com/install.sh | sh

# 3. 拉取一个模型（这需要一点时间，取决于网速）
ollama pull llama3

# 4. 启动Ollama服务（它会自动在后台运行）
ollama serve &

# 5. 现在，CodeX就可以通过Ollama API与llama3模型对话了
# 在CodeX Web UI的聊天框里输入 "Hello, how are you?"，应该能得到回复

常见问题： ollama serve 启动后， http://localhost:11434 在浏览器里打不开？别慌，Ollama的API是专为程序调用设计的，不是给人类浏览的。你只需要确保 curl http://localhost:11434 能返回一个空的JSON响应（ {} ），就说明服务起来了。CodeX的前端会通过AJAX调用这个API，所以UI里能正常对话，就证明一切OK。另外， ollama pull 可能会因为网络问题失败，这时可以配置国内镜像源： export OLLAMA_HOST=127.0.0.1:11434 和 export OLLAMA_ORIGINS="http://localhost:*" ，然后重试。

5. 常见问题与排查技巧实录：那些踩过的坑，我都替你趟过了

5.1 问题速查表：从报错信息快速定位根源

5.2 深度排查：当标准方案失效时，如何像老司机一样诊断

有时候，问题会更隐蔽。比如，你明明执行了 newgrp codex-docker ， groups 也显示成功，但CodeX还是报Docker权限错误。这时，你需要深入到进程层面。

# 1. 启动CodeX，并在另一个终端中查看它的进程树
codex dev --port 3001 &
# 记下PID，比如 12345
ps -ef \| grep 12345

# 2. 查看该进程的详细权限信息
sudo cat /proc/12345/status \| grep CapBnd
# CapBnd是进程的能力位掩码，如果它不包含`cap_net_admin`或`cap_sys_admin`，说明它没有获得docker组的权限

# 3. 更直接的办法：用strace跟踪系统调用
sudo strace -p 12345 -e trace=openat,connect 2>&1 \| grep -i "docker\|sock"
# 这会实时打印出CodeX进程尝试打开或连接哪些文件/套接字
# 如果你看到 `openat(AT_FDCWD, "/var/run/docker.sock", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)`，那就100%确认是权限问题

实操心得： strace 是Linux系统管理员的瑞士军刀。它能让你看到程序和内核之间最真实的对话。上面的命令中， -e trace=openat,connect 限定了只跟踪文件打开和网络连接这两个最关键的系统调用，避免了海量无关日志的干扰。 grep -i "docker\|sock" 则帮你快速聚焦。我曾经用这个方法，在一个客户环境里发现，CodeX的某个子进程（一个Python脚本）在尝试连接Docker时，用的是 unix:///var/run/docker.sock 这个绝对路径，而我们的 codex-docker 组权限只给了 /var/run/docker.sock ，路径完全匹配，所以 strace 的输出直接证实了问题，排除了所有其他猜测。这种“眼见为实”的排查方式，比看一百篇博客都管用。

5.3 终极避坑指南：那些文档里不会写的血泪教训

• 不要在 /tmp 目录下运行 codex dev ： /tmp 目录在Ubuntu上默认是 noexec 挂载的，意味着你不能在 /tmp 里执行任何二进制文件。CodeX在启动时会生成一些临时的可执行文件（比如编译后的JS bundle），如果项目根目录在 /tmp ， codex dev 会静默失败，或者报一个非常诡异的 spawn ENOENT 错误。永远把项目放在 $HOME 下的某个目录里。

• WSL2的DNS问题会导致Ollama拉取模型超时 ：WSL2使用自己的虚拟网络，其DNS服务器（ /etc/resolv.conf 里的 nameserver ）有时会指向一个不可靠的地址。当你运行 ollama pull llama3 卡在 pulling manifest 时，大概率是DNS解析慢。解决方案是：编辑 /etc/wsl.conf ，添加：

  [network]
  generateResolvConf = false
  

  然后在Windows PowerShell中运行 wsl --shutdown ，重启WSL2。之后手动编辑 /etc/resolv.conf ，把 nameserver 改成 8.8.8.8 或 114.114.114.114 。

• VS Code的Remote-WSL插件与CodeX的端口冲突 ：如果你在VS Code里用Remote-WSL打开项目，并且CodeX也在WSL2里运行 codex dev --port 3001 ，那么VS Code的Remote-WSL会自动将 3001 端口转发到Windows。这本身是好事，但如果你在VS Code里同时打开了多个WSL2窗口，或者之前有未关闭的 codex dev 进程，端口 3001 可能被占用。此时，VS Code的端口转发会失败，而CodeX的错误日志里却找不到任何关于端口的信息。解决办法是：在VS Code的Remote-WSL窗口里，按 Ctrl+Shift+P ，输入 Remote-WSL: Show Log ，查看日志里是否有 Port 3001 is already in use 的提示。如果有，就换一个端口，比如 3002 。

• Ubuntu的Snap版本Node.js与npm路径重定向不兼容 ：Ubuntu 22.04的软件中心默认安装的Node.js是Snap包。Snap包是沙盒化的，它有自己的文件系统视图， npm config set prefix 命令对它无效。如果你发现 npm config get prefix 始终返回 /snap/node/... ，那就说明你装的是Snap版。解决方案是： sudo snap remove node ，然后用NodeSource的APT仓库重新安装（见4.1节）。这是最干净的解决方式，因为Snap的Node.js在处理 node-gyp 编译时，经常会出现各种奇奇怪怪的路径错误。

6. 性能与安全加固：让CodeX在Ubuntu上跑得更稳、更安心

6.1 内存与CPU限制：防止CodeX吃光系统资源

CodeX，尤其是当它在后台调用Ollama运行大型语言模型时，会消耗大量内存。一个 llama3:8b 模型在Ollama里运行，轻松占用4GB RAM。如果你的Ubuntu机器只有8GB内存，CodeX可能会把系统拖得卡顿不堪，甚至触发OOM Killer（Out-Of-Memory Killer），干掉你正在编辑的Chrome或VS Code。

# 1. 为Ollama服务设置内存和CPU限制（使用systemd）
sudo systemctl edit ollama

# 在打开的编辑器中，输入以下内容：
[Service]
MemoryLimit=4G
CPUQuota=50%

# 2. 重载systemd配置并重启Ollama
sudo systemctl daemon-reload
sudo systemctl restart ollama

# 3. 验证限制是否生效
sudo systemctl show ollama --property=MemoryLimit,CPUQuota
# 输出应为 MemoryLimit=4294967296 和 CPUQuota=50%

提示： MemoryLimit=4G 是硬限制，一旦Ollama进程使用的内存超过4GB，systemd会立即将其杀死。 CPUQuota=50% 表示它最多只能使用一个CPU核心的50%计算时间，这能有效防止它霸占所有CPU资源。这两个参数是systemd提供的原生资源控制能力，比在Docker里跑Ollama再加 --memory 参数更底层、更可靠。我测试过，加上这个限制后，即使Ollama在全力推理，我的Ubuntu桌面依然丝滑流畅，没有任何卡顿。

6.2 日志与监控：让问题在发生前就被发现

一个成熟的开发环境，必须有可观测性。我们为CodeX添加简单的日志轮转和健康检查。

# 1. 创建一个日志轮转配置，防止codex.log无限增长
sudo tee /etc/logrotate.d/codex << 'EOF'
/home/ubuntu/my-codex-project/codex.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 644 ubuntu ubuntu
    sharedscripts
    postrotate
        # 如果codex是用pm2管理的，这里可以发reload信号
        # /usr/bin/pm2 reload codex 2>/dev/null || true
    endscript
}
EOF

# 2. 创建一个简单的健康检查脚本
sudo tee /usr/local/bin/check-codex.sh << 'EOF'
#!/bin/bash
# 检查codex dev进程是否在运行
if pgrep -f "codex dev" > /dev/null; then
    echo "OK: codex dev is running"
    exit 0
else
    echo "ERROR: codex dev is not running"
    exit 1
fi
EOF

sudo chmod +x /usr/local/bin/check-codex.sh

# 3. 设置一个cron job，每5分钟检查一次
(crontab -l 2>/dev/null; echo "*/5 * * * * /usr/local/bin/check-codex.sh >> /var/log/codex-health.log 2>&1") | crontab -

实操心得：日志轮转（logrotate）是Linux运维的基石。 /etc/logrotate.d/ 目录下的每个文件，都是一个独立的日志管理策略。上面的配置告诉logrotate：每天检查一次 codex.log ，如果存在就把它压缩归档，保留最近14天的备份。 delaycompress 参数很重要，它确保第一次轮转时不压缩，给管理员一个检查原始日志的机会。而健康检查脚本，则是把“人肉检查”自动化。 pgrep -f 命令会搜索所有进程的完整命令行， -f 参数确保我们能匹配到 codex dev --port 3001 这样的长命令。把它放进crontab，你就拥有了一个24