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的歸屬，現在是誰的名字？