Anthropic把权限管理藏了3年，多用户场景终于翻车

Claude Code在单用户机器上跑得很顺，一到多用户Linux环境就崩。不是代码问题，是Anthropic根本没想过企业场景——或者说，他们以为chmod 777算解决方案。

一位叫Jeremy的工程师上周踩了这个坑。他切到自己的工作账户启动Claude Code，屏幕弹出EACCES: permission denied，系统调用显示errno: -13。权限错误，经典Linux噩梦。

诡异的是，报错指向的文件路径在Jeremy自己的家目录里。自己的文件，自己没权限写。

第一层：表面症状

Jeremy先检查了当前用户和目录归属。whoami返回admincostplus，而~/.claude目录的所有者也是admincostplus，权限700。这意味着其他用户连读都读不了。

他尝试用claude --dangerously-skip-permissions强制跳过权限检查，程序依然崩溃，还是在文件打开环节报错。这说明问题比运行权限更深——Claude Code需要写日志、写配置，而这些目录它进不去。

关键发现藏在Jeremy的家目录深处。/home/jeremy/.claude/debug/这个目录的归属者是admincostplus，权限drwx------。翻译成人话：admincostplus之前用Jeremy的机器调试过，Claude Code以他的身份创建了调试目录，现在真正的主人Jeremy反而被锁在外面。

这就像你请朋友来家里用电脑，他登录自己的账号装了软件，结果软件把配置文件扔在你的文档文件夹里，还上了锁。

第二层：权限架构的三层解法

解决方案需要同时搞定用户组、共享目录和符号链接。不是改几个chmod就能收工的事。

第一步建用户组。创建一个claudeusers组，把Jeremy和admincostplus都塞进去。这是Linux多用户协作的基础操作，但Claude Code的安装文档里一个字没提。

第二步搞共享目录。/opt/claude-shared作为中立地盘，归属Jeremy但组权限开放给claudeusers。关键参数是chmod 2775——那个2是setgid位，确保新创建的文件自动继承组归属，而不是谁创建归谁。

第三步最脏。需要把admincostplus家目录里的Claude相关文件夹删掉，换成指向共享目录的符号链接。涉及的路径有四个：.claude、.claude-code、.config/claude-code、.local/share/claude-code。脚本里用rsync把Jeremy的配置同步到共享区，再给admincostplus建链接。

这套架构的隐藏成本：任何新用户加入，都需要root权限跑一遍脚本。Claude Code没有内置的多用户模式，全靠系统管理员手工搭桥。

第三层：产品设计的盲区

Anthropic的文档把Claude Code定位为"个人AI助手"，安装指南假设一台机器一个人用。但企业场景里，开发机共享、CI/CD多账户运行、运维和开发权限分离都是常态。

对比OpenAI的CLI工具，它们至少把配置路径做成可环境变量覆盖。Claude Code的路径写死在代码里，用户只能搬家目录或者玩符号链接这种野路子。

Jeremy在排查过程中用了--dangerously-skip-permissions这个隐藏参数。参数名字透露了开发团队的态度：他们知道权限检查会挡住人，但宁愿加个危险开关，也不愿重构配置管理。

这套解决方案现在跑在生产环境了。Jeremy把脚本开源出来，Issue区已经堆了17个类似问题的求助，覆盖Ubuntu、RHEL和Arch三种发行版。

最后一个细节：脚本里给被替换的目录加了.bak-时间戳后缀备份。Jeremy在注释里写，"因为总有一天你会忘记为什么这里有个符号链接，然后手动删掉它。"

你团队的Claude Code装在共享机器上吗？检查一下家目录里.claude的归属，现在是谁的名字？