根本原因是~/.composer或其子路径（如auth.json、cache/）被root占用，需用ls -ld检查归属，再用sudo chown -R $USER:$USER精准修复所有权，禁用chmod -R 777。
根本原因不是插件本身出错，而是 Composer 全局配置目录（~/.composer）或其子路径（如 auth.json、config.json、cache/）被 root 或其他用户占用，导致当前用户无法写入。
为什么 composer global update 报 “Permission denied” 修改配置？
错误通常出现在执行 composer global update 或 composer global require 时，终端输出类似：
Could not write to /home/user/.composer/auth.json Failed to save config: Permission denied
这说明 Composer 尝试更新全局配置文件失败，但问题不在插件代码，而在它要写入的路径归属不对。常见源头包括：
- 曾用
sudo composer global require，把整个~/.composer变成root所有 - CI/CD 流水线或 Docker 容器中 UID 不一致，挂载卷后
~/.composer被容器 root 写入 - 插件（如
hirak/prestissimo或镜像源工具）在安装时调用了需要写配置的操作，但权限已卡死
查清哪个路径被锁住：三步定位
别猜，直接看报错里写的路径，然后逐个检查归属：
- 运行
ls -ld ~/.composer—— 若第一列含root，整套全局配置都归还失败 - 运行
ls -l ~/.composer/auth.json ~/.composer/config.json—— 单独文件属主异常也足以阻断更新 - 运行
composer config --global cache-dir，再ls -ld那个路径 —— 缓存目录被占也会触发“无权修改”假象
只要任意一个输出显示属主不是 $(whoami)，就确认是所有权错配，不是 chmod 数字不够。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
修复动作必须精准，不能靠 chmod -R 777
chmod -R 777 ~/.composer 看似解燃眉之急，实则埋雷：安全扫描会拒收、Git 提交提示 ownership changed、后续 composer global 命令可能只成功一半。正确做法是归还控制权：
- 整目录重置：
sudo chown -R $USER:$USER ~/.composer - 若只想修关键文件：
sudo chown $USER:$USER ~/.composer/auth.json ~/.composer/config.json - 修复后验证：
composer global diagnose应显示 “OK”，且composer global list可正常输出
注意：sudo 这里仅用于临时提权跑 chown，绝不是让你接着跑 sudo composer global update——后者会再次污染目录。
长期避免：禁用 sudo 运行任何 composer global 命令
所有 composer global 操作都应在当前用户下执行。如果之前误用 sudo 导致 COMPOSER_HOME 被设为 /root/.composer，需手动清理：
- 检查真实生效路径：
composer config --global home - 若输出是
/root/.composer，删掉它：sudo rm -rf /root/.composer - 确保环境变量未覆盖：
unset COMPOSER_HOME，或从~/.bashrc中移除相关 export
最容易被忽略的是：插件更新失败时，错误信息里写的路径（比如 auth.json）往往只是表层症状，真正病灶可能是上层目录（~/.composer）的 UID 错位，而这个错位在 WSL 或 Docker 中尤其隐蔽——ls -ld 输出看起来正常，但实际因 metadata 未启用，chown 根本没生效。
