Codex CLI daemon权限报错排查：进程身份与文件属主错位修复

1. 报错现场还原：daemon 为什么总在权限上绊倒

第一次遇到这个报错的人，十有八九会下意识敲一个sudo上去，然后发现命令确实跑起来了，但过两天又坏，而且坏得更隐蔽。Codex CLI 的权限类报错之所以让人抓狂，是因为它并不是命令本身没权限，而是CLI 客户端与后台 daemon 之间那条“看不见的通道”权限对不上。表现出来是permission denied，根子上却是两套身份在抢同一个目录。

先把最常见的几种脸谱摆出来，方便你一眼对上号。这三种报错文本虽然长得不一样，但绝大多数情况下指向同一个根因：进程身份与文件属主错位。

我在不同机器上复现过很多次，规律相当稳定：只要“创建目录的那个身份”和“启动 daemon 的那个身份”不是同一个，问题迟早会冒出来。比如你用管理员权限装了一遍，顺手跑了一次初始化，~/.codex目录和里面的 socket 文件就归管理员所有了，模式位可能是0600。之后你用普通账户启动，客户端需要在这个目录里创建或连接 socket，内核一看属主不是你、模式位又不给写，直接EACCES。

这里有个容易被忽略的点：Unix domain socket 的权限检查走的是文件系统权限位，跟 TCP 端口那种“小于 1024 需要 root”完全不是一回事。所以很多人凭直觉去查端口占用、查防火墙，查半天没结果——方向从一开始就跑偏了。socket 文件就是一个特殊文件，它就是靠ls -l里那串srwx------说话的。

再补一个反直觉的现象：有时候报错信息会写成“连接被拒绝”或者“服务未响应”，看起来像 daemon 没起来，其实 daemon 好好活着，只是它属于另一个用户。你去ps里能看到它，但当前用户连不上它，客户端就理解为“服务不可用”。这一层误判会把人带向重启服务、重装 CLI 的错误路径，白白浪费半小时。

所以判断这件事的第一原则很简单：先看属主，再看日志，最后才怀疑代码。ls -ld和id两条命令能解决的问题，不值得重装一遍。

1.1 三类典型报错文本与它们的真实含义

把报错文本翻译成人话，是排查效率最高的起点。os error 13在类 Unix 系统里固定是EACCES，意思是“你有身份但没这个权限”；如果出现os error 1，那是EPERM，通常是操作本身被禁止（比如对某个特殊文件做 chmod），性质不同，别混为一谈。EACCES九成以上是模式位或属主问题，一小部分是 SELinux/AppArmor 之类的强制访问控制拦了。

Access is denied. (os error 5)是 Windows 上的对应物。它比 Unix 那边更让人困惑，因为 Windows 有两层：NTFS ACL 和 UAC 令牌过滤。你账户在管理员组里，不代表当前进程有管理员令牌——默认情况下进程跑的是“过滤后的标准令牌”，写C:\Program Files或者某些受保护目录照样被拒。很多人看到“我是管理员”就认定不该报权限错误，这个认知偏差在 Windows 上踩坑率极高。

还有一类报错不带permission字样，比如daemon did not respond in time、socket hang up、failed to bind。这些是权限问题的次生表现：daemon 因为写不了 pid 文件而静默退出，客户端等超时；或者 daemon 起来了但绑定 socket 失败，客户端连了个空壳。遇到这类，别急着调超时参数，先去翻 daemon 自己的日志文件。

日志位置通常跟配置目录在一起，~/.codex/logs/之类，具体路径以codex --help或配置文件里的log_dir为准。日志里往往有一行非常直白的Permission denied (os error 13)带着完整路径——那才是真正的现场，客户端打印的那句只是转述。

提示：客户端报错里如果出现路径，务必一个字一个字对照，尤其注意/root/和/home/xxx/的区别。路径本身就是最强的线索。

1.2 权限冲突的根因：进程身份与文件属主错位

把这件事抽象一下：daemon 模式本质上是“一个常驻进程 + 一个通信端点 + 若干状态文件”的组合。这三样东西都有属主，而访问它们的客户端进程有自己的身份。只有当客户端身份对这三样东西都有足够权限时，链路才通。

错位通常从哪来？我总结出四条高频路径：

第一条是安装环节用管理员权限。某些安装脚本要求写系统目录，你顺手sudo了，脚本“贴心地”把用户级配置目录也一起初始化了，于是~/.codex变成 root 的。

第二条是首次运行用了提权终端。Windows 上右键盘符选“以管理员身份运行”，或者 Linux 上sudo codex，daemon 就以高权限身份注册了，之后普通终端连不上。

第三条是环境变量被提权操作污染。sudo默认会重置HOME，但有些配置保留HOME却换了XDG_RUNTIME_DIR，导致 socket 被创建到/run/user/0/下，普通用户根本看不见那个目录。

第四条是历史遗留。半年装过一次，卸载时没清干净，残留的 socket 文件属主是旧账户的 UID（比如 1000），而系统重装后你的新 UID 变成了 1001，数字对不上，属主判定失败。

这四条路径的共同结局都一样：某个文件的属主 UID 与当前进程的 EUID 不匹配，且模式位不允许“其他人”访问。理解了这一层，后面所有修复动作其实都是在做同一件事——把链路两端拉回同一个身份。

2. 拆开 daemon 的启动链路：哪一步在检查权限

要精准定位，得知道 daemon 从敲下回车到准备就绪，中间到底摸过哪些文件。我把这条链路拆成六步，每一步都是一个潜在的失败点。你不需要记住全部，但至少要知道失败可能发生在“创建”阶段还是“连接”阶段，因为这两类的处理方式完全不同。

第一步，主进程解析参数，判断是否需要拉起后台服务。这一步只读配置，一般不会失败，除非配置文件本身读不了（也是权限问题，但报错会指向配置文件路径）。

第二步，确定并准备运行时目录。典型顺序是：优先用$XDG_RUNTIME_DIR，没有就退回~/.codex/run或~/.codex。这一步会stat目录，不存在就mkdir。如果目录已存在但不属于当前用户，mkdir会返回EEXIST，随后写入操作才报EACCES——报错点往往在后面的写操作，而不是创建操作，这会误导排查方向。

第三步，spawn 子进程并 detach。这一步要注意：子进程会继承父进程的全部身份属性，包括 EUID、补充组、umask、资源限制。父进程如果是提权跑的，子进程就是提权的；父进程 umask 是022，子进程创建的 socket 就可能变成0755，比预期宽松。

第四步，绑定监听端点。Unix 下是bind()一个 socket 文件，Windows 下是创建命名管道。这一步的坑在于：如果 socket 文件已存在，bind会失败，很多实现的做法是先 unlink 旧文件再 bind——但 unlink 需要对目录有写权限，权限不足时就会在“清理旧文件”这一步炸掉。

第五步，写 pid 文件或锁文件。有些实现用flock防重复启动，锁文件权限不对会直接失败，报错文本可能是Resource temporarily unavailable，看着像并发问题，实际是权限问题。

第六步，打开日志文件并重定向。以追加模式打开，需要文件写权限；如果日志文件被轮转工具改成了别的属主，这一步也会挂。

看到这里你应该有感觉了：六个步骤里有五个都在跟文件系统打交道。所以“daemon 起不来”这个笼统描述，实际含义高度依赖日志里那一行具体路径。

2.1 三个关键位置：配置目录、socket 文件、日志句柄

真正常出问题的就三个位置，把这三个位置的状态搞清楚，八成的案子当场能破。

配置目录是最外层的门。它需要当前用户有读、写、执行三种权限。注意“执行”位对目录的意义是“能进入并访问子项”，缺了它，目录里的文件名都列不出来。很多人修复时只chmod +r +w，忘了+x，结果还是不行。标准做法是700，属主可读写进入，其他人一律靠边。

socket 文件是通信端点。它的模式位通常在0600或0660之间，属主必须是运行客户端的那个用户，或者客户端所属的组。这里有个细节：socket 文件的权限在 bind 时由 umask 决定，所以如果父进程 umask 是000，可能生成一个0777的 socket——宽得离谱，安全上是隐患，但功能上反而“能用”，于是被忽视。

日志句柄看着最无害，实际最容易在“长期运行”场景出问题。比如日志轮转把文件 rename 走了，daemon 手里的句柄还指向旧 inode，新的同名文件被创建成别的属主，下一次打开就失败。这类问题只在跑了几天之后才出现，极难复现。

我一般的检查顺序是：先stat配置目录，再ls -l找 socket，最后tail日志。三步下来还没线索，才去看进程状态和环境变量。

2.2 权限检查的判定顺序

内核判定一个open()是否成功，顺序是固定的：先看进程 EUID 是否等于文件属主 UID，相等就用属主那三位；不等则看进程的组列表是否包含文件属主 GID，包含就用组那三位；都不匹配才用“其他人”三位。这个顺序解释了很多“我明明在组里却还是不行”的疑惑——如果你既是属主又是组成员，属主位优先，属主位是---的话，组位再宽松也没用。

这也带来一个实用的修复技巧：当你没法改属主（比如共享环境），可以把文件改成“属组可写”，然后把用户加进那个组。但注意组变更对已登录会话不生效，得重新登录或者用newgrp。

Windows 那边的判定逻辑完全不同，是按 ACL 里 ACE 的顺序（显式拒绝优先，然后显式允许，再继承允许）叠加。所以 Windows 上报权限错误，要看icacls输出的完整列表，特别留意有没有一条DENY挂在你的账户或某个组上——那种情况加权限是加不上去的，必须先把 DENY 拿掉。

3. 分平台复现与定位手法

排查权限问题最忌讳“猜”。我的习惯是先构造一个最小复现，确认问题确实出在属主上，再去改配置。这样即使改错了，也能立刻回滚，不至于把环境搞得更乱。

类 Unix 平台上的最小验证是这样：开一个终端，id -u记下当前 UID；然后stat一下配置目录和 socket，看 UID 是否一致；再用sudo -u指定另一个身份去test -w目录。三条命令下来，结论就很明确了。这套流程我用了很多次，基本不需要看源码。

Windows 上的最小验证要绕一点。先whoami /user拿到 SID，再whoami /groups看当前进程的实际令牌组（注意这里显示的是过滤后的组，管理员组会标成“仅用于拒绝”），然后icacls看目标目录的 ACL。三步之后你就知道自己是“名义管理员”还是“实际管理员”了。

3.1 Linux 与 macOS 下的定位命令组合

下面这组命令我是常备的，直接抄走改路径就能用。核心思路是：一次把所有相关文件的身世打印出来，横向对比。

# 1. 当前身份与所属组 id -u; id -un; id -Gn # 2. 配置目录与运行时目录的元信息 stat -c '%U:%G %a %n' ~/.codex 2>/dev/null stat -c '%U:%G %a %n' "${XDG_RUNTIME_DIR:-/tmp}" 2>/dev/null # 3. 找 socket 与 pid 文件 find ~/.codex -maxdepth 2 -name '*.sock' -o -name '*.pid' 2>/dev/null # 4. 谁在占用这个 socket ss -xlp 2>/dev/null | grep -i codex # 5. 现存 daemon 进程跑在哪个用户下 ps -eo user,pid,ppid,cmd | grep -i '[c]odex'

macOS 上stat的参数不同，用stat -f '%Su:%Sg %Lp %N'。ss可能没有，用lsof -U | grep codex替代。这两处差异经常让人以为“命令不存在就是环境有问题”，其实只是平台工具集不一样。

跑完这组命令，重点看两件事：find出来的文件属主是不是当前用户；ps里那个 daemon 的 user 列是不是当前用户。只要有一项不符，问题定性就完成了，不用再往下猜。

还有一条很有用的：检查umask。umask决定了新建文件的默认权限，如果它是0000或者0002，daemon 创建的 socket 会偏宽松；如果是0077，创建出来就是0600，这反而正常。有些环境把 umask 设成0027，导致组内其他用户读不了日志——在多用户共享机器上是常见抱怨。

3.2 Windows 下的 UAC 与令牌过滤

这一节值得单独说，因为它是 Windows 上“权限报错”的第一大来源，而且和 Linux 的直觉完全相反。

Windows Vista 之后引入了 UAC。账户即使属于管理员组，用户登录时也会拿到两个令牌：一个完整的管理员令牌，一个过滤后的标准令牌。默认情况下，双击启动的进程用的是过滤后的令牌，管理员组在令牌里被标记为“仅拒绝”。这意味着：你看到自己是管理员，但进程实际只有标准用户权限。

于是就有了那个经典场景——你在资源管理器里能删某个文件，在命令行里删不掉。不是命令有问题，是两个进程的令牌不一样。

判断当前令牌状态，最快的办法是whoami /groups，找BUILTIN\Administrators那一行，看“属性”列有没有“组已启用”还是“仅用于拒绝”。如果显示“仅用于拒绝”，说明当前是标准令牌，需要提权才能做那些操作。

# 查看当前进程的令牌组 whoami /groups | Select-String -Pattern "Administrators" # 查看目标目录的 ACL icacls "$env:USERPROFILE\.codex" # 找到拒绝项（如果有） (Get-Acl "$env:USERPROFILE\.codex").Access | Where-Object { $_.AccessControlType -eq 'Deny' }

第三行特别关键。Windows 上偶尔会出现一条继承下来的DENY项，卡在某个组上，导致你怎么加权限都没用。我遇到过一次，是某个安全软件给用户目录挂了拒绝写某些扩展名的规则，表现就是 daemon 创建的临时文件被拒。查了半天属主，最后Get-Acl一跑才看见。

另外提醒一句：Windows 上用户名带空格或者中文的情况不少见，C:\Users\张 三\这种路径在拼接命令行时如果没加引号，会被拆成两段，报错信息会变成一个莫名其妙的“找不到路径”或者“拒绝访问”。这类问题看着像权限，其实是引号。用$env:USERPROFILE而不是硬编码路径，能规避大部分。

3.3 用一个最小实验确认是不是属主问题

定性最快的方式是做一个“换身份”实验。思路是：把配置目录临时换到一个确定属于当前用户、权限确定的位置，看问题是否消失。

# 用临时目录做隔离验证 export CODEX_HOME="$(mktemp -d)/codex-home" codex daemon --foreground

如果换了目录就好了，那百分之百是原目录的属主或权限问题，跟程序逻辑无关。这个实验的价值在于它能一刀切开“环境问题”和“程序问题”，省掉大量无效排查。

Windows 上同理，设一个环境变量指向%TEMP%下的新目录即可。注意mktemp -d创建的目录默认是700，属主是当前用户，这正好是理想的干净状态。

注意：这个实验只做定性，不要长期用临时目录跑生产任务，临时目录会被系统清理，配置和状态会丢。

如果换了目录问题依旧，那要换个方向：可能是二进制本身没有执行权限（chmod +x），可能是被安全策略拦截，也可能是依赖的动态库加载失败——后者报错文本有时也会带permission denied，因为有安全模块在拦mmap可执行内存。

4. 修复方案：四条路线与它们的适用边界

修复这件事没有唯一正确答案，得看你的使用场景。单人开发机、多用户共享服务器、公司受管设备，这三类环境的最优解完全不同。我下面给四条路线，按“从轻到重”排，优先试前面的。

先立一条纪律：任何修复动作之前，先备份配置目录。不用很复杂，cp -a一份带日期的副本就行。权限问题修错方向的时候，把环境搞得更乱是很常见的，有备份就不慌。

另外提醒，chown -R这类递归操作要看清目标路径。写错一个字符，把家目录整个改属主，恢复起来很痛苦。执行前先echo一遍路径确认，这个习惯值得养成。

4.1 路线一：把整条链路统一到普通用户

这是最推荐的做法，适用于绝大多数个人开发场景。核心思想：从安装到运行，全程不用提权。

具体操作是先清理掉高权限遗留，再以普通用户重新初始化。清理的时候要小心，别把有价值的配置删了。

# 1. 备份 cp -a ~/.codex ~/.codex.bak.$(date +%Y%m%d%H%M) # 2. 修正属主（不是删除重建，保留配置） sudo chown -R "$(id -u):$(id -g)" ~/.codex # 3. 收紧目录权限 chmod 700 ~/.codex # 4. 清掉可能残留的旧 socket find ~/.codex -maxdepth 2 -name '*.sock' -delete # 5. 以普通用户前台启动，观察输出 codex daemon --foreground

第一步的备份别省。第二步用chown -R而不是删目录，是因为很多人的配置里有认证信息、自定义模型别名、快捷键绑定，删了要重配。第三步700是标准值，别给755，配置目录里可能有凭据。

如果sudo不可用（比如公司受管设备），那就只能走“删掉重来”的路线，但删之前一定确认目录内容确实可以丢。

这条路线之所以最优，是因为它从源头上消除了身份分裂的可能。以后不管怎么升级、怎么重装，只要不加sudo，就不会再出现这个问题。

4.2 路线二：修复既有目录的属主与权限位

有时候你不能删目录——比如里面有一堆已经调好的项目配置，或者这是台共享机器，别人也在用。这时候就做“外科手术”。

除了目录本身的属主，还要检查几个容易被忽略的地方。第一个是$XDG_RUNTIME_DIR，在某些发行版上它由 pam_systemd 在登录时创建，属主应该是你，模式0700。如果之前用sudo -i进去过，可能会留下一个错误的目录。第二个是/tmp下 daemon 可能创建的临时 socket，/tmp是全局可写的，多个用户的文件混在一起，属主判断尤为关键。第三个是 pid 文件和锁文件。

# 逐一检查常见位置 for p in ~/.codex "${XDG_RUNTIME_DIR:-/run/user/$(id -u)}" /tmp; do echo "== $p" ls -ld "$p" 2>/dev/null find "$p" -maxdepth 1 -user root 2>/dev/null | head -20 done

最后一行是找“本来是用户文件却被 root 占了”的漏网之鱼。这条命令我在几台机器上都揪出过问题文件，尤其是/tmp下的残留 socket，肉眼很难注意到。

修完之后一定要重新启动终端会话。有些权限变更（比如组变更）对已存在的会话不生效，你以为修好了，其实只是旧会话还在用旧缓存。

4.3 路线三：前台模式隔离验证

--foreground这个参数是排查神器。daemon 默认后台化，出错信息被吞进日志，你只能看到客户端转述的一句模糊报错。前台模式下，所有输出直接打到终端，包括初始化每一步的日志。

# 提高日志级别，把权限相关的细节都打出来 codex daemon --foreground --log-level debug 2>&1 | tee /tmp/codex-daemon.log

具体参数名各版本可能不同，以codex daemon --help的输出为准，这一点我强调一下：别照抄网上抄来的参数，版本迭代后参数名经常变，照抄容易得到“未知参数”的报错，然后误以为是权限问题的新变种。

前台模式下观察什么？看它在哪一步停下来。如果是“准备目录”阶段就停，那是目录权限；如果是“绑定端点”阶段停，那是 socket 权限或者残留文件；如果是“打开日志”阶段停，那是日志文件权限。这三种的修复方式不同，但都属于同一个大类。

我以前遇到过一个案例：前台模式跑得好好的，一后台化就失败。查下来是后台化时会chdir("/")，然后所有相对路径解析失败。这类问题跟权限没关系，但报错文本很像。所以前台能跑、后台不能跑，这个组合本身就说明问题不在身份，而在路径或工作目录。会区分这一点，能省下大量时间。

4.4 路线四：确实需要高权限时的正确姿势

有些场景确实需要提权，比如 daemon 要监听低编号端口，或者要访问某些只有管理员能读的目录。这时候的正确做法不是sudo codex daemon，而是用系统服务管理器托管，让服务以指定身份运行。

Linux 上推荐systemd --user，它天然以当前用户身份运行，不需要 root：

# ~/.config/systemd/user/codex-daemon.service [Unit] Description=Codex CLI Daemon After=default.target [Service] Type=simple ExecStart=%h/.local/bin/codex daemon --foreground Restart=on-failure RestartSec=3 [Install] WantedBy=default.target

配上systemctl --user enable --now codex-daemon，之后用journalctl --user -u codex-daemon -f看日志。这套方案的好处是：日志统一、自动重启、身份明确，而且不污染 root 的家目录。

macOS 上对应的是launchd的 LaunchAgent，放在~/Library/LaunchAgents/下，同样以当前用户身份运行。Windows 上推荐用“计划任务”并勾选“不管用户是否登录都运行”，注意要显式指定运行账户，别用 SYSTEM——用 SYSTEM 跑会让配置文件跑到C:\Windows\System32\config\systemprofile下，之后你自己再跑又是一次身份分裂，这个坑很深。

真要监听低编号端口，更好的做法是让服务跑在高位端口，前面挂个反向代理做转发，而不是给 daemon 提权。提权运行的常驻进程是安全风险，能不给就不给。

5. 反复踩中的几个坑

权限问题的麻烦之处在于，同一个现象可能有四五个不同原因，而且互相掩盖。下面这几个是我踩过、并且见过别人反复踩的，写出来供对照。

第一个坑：sudo安装、普通用户运行。这是最经典的组合，几乎每个用 Unix 系的人都中过招。判断方法很简单，看配置目录的属主是不是 root。修复就按路线一走。

第二个坑：旧 socket 残留。daemon 异常退出（比如被kill -9）时来不及清理 socket 文件，下次启动时文件还在，bind 失败。这时候很多人会去查权限——确实是权限，但权限问题是次要的，主要是文件本身不该存在。删掉即可。

第三个坑：多版本并存。机器上装了两个版本，一个在~/.local/bin，一个在/usr/local/bin，PATH 顺序不同导致你跑的是旧版本，而旧版本的 socket 路径和新版本不一样，客户端连不上。这时which -a codex和codex --version能帮你确认。

第四个坑：路径在同步盘或网络盘上。把配置目录配置到云同步目录或者网络挂载点上，Unix socket 在某些文件系统上根本不支持，报错可能是EACCES或者EOPNOTSUPP。这类问题换目录就好，不用深究。

第五个坑：安全软件的受控文件夹访问。Windows 上某类安全功能会保护用户目录下的特定位置，第三方程序写入被静默拦截，表现就是“权限不足”，但 ACL 里看不出问题。排查方式是临时把目标目录加入白名单，看是否恢复。

5.1 旧 socket 残留导致的“假权限错误”

单独把这个拎出来说，因为它太有欺骗性。报错文本是permission denied，你去看权限，发现属主对、模式位也没问题——因为文件本来就不该在那儿。

原理是这样的：bind()对一个已存在的路径会直接返回EADDRINUSE，很多实现的做法是先unlink()再bind()。而unlink()需要对父目录有写权限。如果父目录权限被人改过（比如某次误操作chmod 555），unlink就失败，错误一路往上冒泡，最后客户端打印出来的就是一句permission denied。你盯着 socket 文件的权限看，永远看不出问题，因为问题在目录上。

正确的检查姿势是先看目录，再看文件：

# 目录权限是否正确（需要 700 或至少属主有 w+x） ls -ld ~/.codex # socket 文件是否还存在 ls -l ~/.codex/*.sock 2>/dev/null # 进程是否真的在跑 pgrep -af 'codex.*daemon'

三种状态组合起来的解读方式如下表，这张表我在排查时用得很顺：

这张表覆盖了我遇到的绝大多数组合。剩下的小概率情况是 socket 路径和进程实际绑定的路径不一致，那就要看启动参数里有没有显式指定路径，以及环境变量有没有被覆盖。

5.2 umask 与文件模式位的隐性影响

umask这个话题容易被忽略，但它决定了新建文件的初始权限，间接影响后续所有操作。

机制是这样：open()时传入的 mode 会被 umask 按位取反后与上去。想要 socket 是0600，程序传入0666，umask 是0077，结果是0600；如果 umask 是0022，结果就是0644——其他用户可读。对 socket 来说，可读意味着可以连接，这就不太安全了。

umask从哪来？shell 启动时的默认值，或者~/.bashrc、/etc/profile里设的。有些公司环境统一设成0027，导致组内共享的配置目录里，其他组成员读不了日志，一查就是权限报错。

查看方式很直接：

umask # 当前值 umask -S # 符号形式，更直观

修复的话，在启动 daemon 的脚本里显式设umask 077，别依赖环境默认值。这一行很小的改动，能消除一类“时好时坏”的权限问题——因为在不同终端里启动，继承的 umask 可能不一样。

5.3 环境变量覆盖导致的路径漂移

这条坑最隐蔽。配置文件里写着~/.codex，但实际生效的是另一个路径，因为环境变量优先级更高。

常见的几个变量：HOME、XDG_CONFIG_HOME、XDG_RUNTIME_DIR、以及工具自己的前缀变量（比如CODEX_HOME）。优先级一般是 工具前缀变量 > XDG 变量 > HOME 推导。只要其中一个在某个终端里被设过，就会出现“同一个命令在不同窗口表现不一样”的灵异现象。

排查方式是把它们全打出来，逐个核对：

env | grep -Ei '^(HOME|XDG_|CODEX_)' | sort

我遇到过一次，某个 IDE 内置终端启动时注入了CODEX_HOME指向项目内目录，导致我在 IDE 里跑得好好的，在系统终端里就是权限报错。查了半天文件属主，最后发现两边压根不是同一个目录。

这类问题的通用解法是：在报错信息里找绝对路径，然后ls -ld那个路径。别信配置文档写的默认值，以实际路径为准。

6. 长期规避：把权限问题挡在安装环节

修一次不算本事，让它别再犯才有价值。权限问题的根源几乎都在“安装/初始化”这个一次性动作上，把这个环节管住，后面就省心了。

核心原则只有一条：让创建和使用处于同一身份。安装用普通用户，初始化用普通用户，日常运行也用普通用户。凡是需要提权的步骤，单独拎出来，做完立刻回到普通身份，不要让提权操作去碰用户级目录。

第二条原则：别在共享路径上放 daemon 状态。/tmp、网络盘、同步盘都不合适。放在用户家目录下的私有位置，权限可控，也不会被系统清理。

第三条原则：升级时先停服务。很多升级脚本会替换二进制，如果 daemon 还在跑，旧进程持有旧 inode，新版本起来后路径可能变化，两边错位。养成systemctl --user stop再升级的习惯。

第四条原则：保留一份可用的配置备份。不是为了防丢，是为了出问题时能快速回退到已知良好状态，把“到底是配置问题还是环境问题”这条线切开。

6.1 安装前后的自检清单

下面这张表是我自己用的检查清单，每次在新机器上装完跑一遍，能挡掉绝大多数后续麻烦。项目不多，但每一条都对应过真实的坑。

Windows 上的等价清单：whoami /user确认身份、icacls确认目录无 DENY 项、where.exe codex确认无多版本、$env:PATH里没有把旧路径排在前面。

跑一遍不到一分钟，比出问题后排查一小时划算得多。

我还建议把上面这些检查写成一个小脚本，放在~/bin里，装完跑一下。脚本不用复杂，输出“OK/BAD”就够。这种小工具的价值在于把隐性知识固化下来，下次换机器、换同事接手，都能直接复用，不用重新踩一遍。

6.2 团队环境下的约定

如果是多人协作的场景，权限问题会翻倍，因为每个人的账户、组、系统版本都不一样。这时候靠口头约定不够，得写进文档。

我的做法是约定三条：统一用用户级安装，谁都不用系统包管理器装到系统目录；统一配置目录位置，都用默认的~/.codex，不搞自定义前缀；统一启动方式，能前台调试就前台，长期跑就用用户级服务管理器托管，不用裸nohup。

这三条看起来琐碎，实际能省下大量“我这里好着你那里不行”的争论。因为大家的身份模型一致了，出问题就是环境问题，不是配置差异，排查起来有共同语言。

另外，容器化环境要特别注意：容器里默认是 root 用户，挂载宿主目录进来后，文件属主映射关系可能完全错位。常见现象是容器里创建的文件在宿主上属主变成1000:1000或者root:root，两边来回切换就出问题。解决办法是在镜像里创建与宿主 UID 一致的用户，用--user指定运行身份，别图方便用 root 跑。

最后分享一个我一直在用的小技巧。遇到任何权限类的报错，先别急着改代码或改配置，把报错里那个路径复制出来，ls -ld一下，再把当前用户id打出来，两行结果并排放着看。属主对不对、模式位够不够、组匹不匹配，这三件事一眼就能看出来。这三十秒的动作，能干掉后面可能存在的半小时弯路。权限问题的本质从来不复杂，复杂的是人会先入为主地假设“我应该是管理员”，而系统只认 UID 和那九位权限位。