subl命令报“permission denied”根源在系统拦截而非sublime自身，主因是软链接目标无执行权限、sip阻止写入受保护路径或路径含空格未转义。
subl 命令本身不会提示“权限不足”——报 Permission denied 的一定是 shell 在执行它时被系统拦截了，根源在软链接目标、PATH 目录或 macOS Rootless 机制。
为什么 subl 执行时报 Permission denied？
这不是 Sublime 自身的问题，而是 shell 尝试运行 subl 可执行文件时被操作系统拒绝。常见真实原因有三个：
- 软链接指向的原始文件（如
/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl）本身没有可执行权限（chmod +x缺失） - 你把软链接建在了受保护路径（比如
/usr/bin/subl），macOS Sierra+ 的 Rootless（SIP）直接禁止写入 - 软链接目标路径含空格但未转义，shell 解析失败后尝试执行不存在的命令，某些 shell 会静默 fallback 到权限检查并报错
macOS 上修复 subl 权限错误的实操步骤
Apple Silicon（M1/M2/M3）和 Intel Mac 处理方式一致，但路径细节不同：
- 先确认原始
subl文件存在且可执行：ls -l /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl；若权限列不含x，运行sudo chmod +x "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" - 不要往
/usr/bin写——SIP 会拦截。改用/usr/local/bin（Intel）或/opt/homebrew/bin（Apple Silicon + Homebrew） - 创建软链接时必须转义空格：
sudo ln -sf "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" /usr/local/bin/subl - 确保
/usr/local/bin在 PATH 中：检查echo $PATH是否含该路径；若无，编辑~/.zshrc加export PATH="/usr/local/bin:$PATH"，再source ~/.zshrc
Linux 下 subl 报 Permission denied 的关键检查点
Debian/Ubuntu 的 .deb 包自带 subl，但 Snap/Flatpak 版本默认不提供，容易误判为“权限问题”：
- 运行
which subl，如果返回空，说明根本没安装命令行工具，不是权限问题 - 若返回路径（如
/usr/bin/subl），用ls -l $(which subl)查看是否是软链接；如果是，再ls -l看它指向的目标是否存在、是否可执行 - 常见陷阱：软链接指向
/opt/sublime_text/subl，但该文件属 root 且权限为-rw-r--r--（缺 x）；修复命令：sudo chmod +x /opt/sublime_text/subl - 别用
sudo chmod 777 /usr/bin/subl——这改的是软链接本身，无效且危险
Windows 上 subl 启动报错“拒绝访问”的真实原因
不是 UAC 弹窗没点“是”，而是杀毒软件或组策略拦截了子进程启动：
- 先验证
subl.exe是否真在安装目录（如C:\Program Files\Sublime Text\subl.exe）；便携版通常不带这个文件 - PATH 配置后必须重启终端（CMD/PowerShell/Windows Terminal 全部关掉重开），否则旧进程看不到新 PATH
- 某些企业环境禁用从 CMD 启动 GUI 程序，此时
subl .会卡住或报错；可用start "" "C:\Program Files\Sublime Text\subl.exe" .绕过 - 如果杀毒软件（如 Windows Defender 实时保护）报“潜在行为”，需临时禁用或添加
subl.exe到白名单
真正难排查的，是软链接目标路径里有中文或空格却没被引号包裹——shell 解析断裂后可能触发奇怪的权限校验逻辑。这类问题不会报具体路径，只笼统说 Permission denied，务必用 ls -l $(which subl) 一层层追到底层文件权限和路径有效性。
