sublime text 启动时拿不到 ssh-agent 环境变量，因 wsl 中 ssh-agent 默认仅限当前 shell 会话，gui 应用无法继承 ssh_auth_sock 和 ssh_agent_pid；解决方法是统一从已启动 agent 的 wsl 终端执行 subl .，并确保密钥权限正确（~/.ssh 700、私钥 600）、git 使用 wsl 自身 ssh 而非 windows 路径。
Sublime Text 启动时拿不到 ssh-agent 环境变量
WSL 中的 ssh-agent 默认只对当前 shell 会话有效，GUI 应用（如 Sublime Text）通过桌面环境启动时，根本看不到 SSH_AUTH_SOCK 和 SSH_AGENT_PID 这两个关键变量。结果就是：终端里 git push 正常，Sublime 里点 Git: Push 却报 Permission denied (publickey)。
解决办法不是重启 agent，而是让 Sublime 启动时「继承」它：
- 别用桌面图标或开始菜单启动 Sublime，统一从 WSL 终端执行：
subl . - 确保你已在该终端中运行过
eval "$(ssh-agent -s)"和ssh-add ~/.ssh/id_ed25519 - 如果用了 systemd 用户服务管理 ssh-agent（比如某些 Ubuntu WSL 发行版），需额外导出变量：
export SSH_AUTH_SOCK=$(systemctl --user show-environment | grep SSH_AUTH_SOCK | cut -d= -f2)
Windows 和 WSL 的 SSH 密钥路径不一致导致冲突
很多人把 Windows 的 ~/.ssh/id_ed25519 软链接到 WSL，但忽略了权限问题——WSL 下 ~/.ssh 目录必须是 700，私钥文件必须是 600，否则 ssh-add 会静默拒绝加载，git 也跳过该密钥。
检查和修复步骤：
- 运行
ls -l ~/.ssh/，确认id_ed25519权限为-rw------- - 如果不是，立刻执行：
chmod 600 ~/.ssh/id_ed25519和chmod 700 ~/.ssh - 如果链接的是 Windows 路径（如
/mnt/c/Users/xxx/.ssh/id_ed25519），不要直接软链接——WSL 对 NTFS 文件的权限控制不可靠，应复制一份到 WSL 主目录再设置权限
SublimeGit 插件没读到正确的 git 配置
SublimeGit 不自动读取 ~/.gitconfig 里的 core.sshCommand 或凭证配置，尤其当你在 WSL 里用 git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe" 指向 Windows 的 ssh.exe 时，Sublime 会因路径解析失败而 fallback 到默认行为，最终走错 SSH 客户端。
稳妥做法是让 WSL 自己处理 SSH：
- 删掉 Windows 路径的
core.sshCommand配置（用git config --global --unset core.sshCommand） - 确保 WSL 里
which ssh返回的是/usr/bin/ssh，不是 Windows 的路径 - 在 WSL 的
~/.gitconfig中显式指定密钥路径（可选但推荐）：git config --global core.sshCommand "ssh -i ~/.ssh/id_ed25519"
HTTPS 推送时弹窗认证失败，不是插件问题
如果你用 HTTPS 地址（https://github.com/xxx/repo.git）而不是 SSH，SublimeGit 会调用系统 git，而 git 在 WSL 下无法触发 Windows 的凭据弹窗——它只会返回 Authentication failed，且不提示输入账号密码。
这不是 Sublime 的 bug，是协议限制：
- 要么切回 SSH 协议（推荐）：
git remote set-url origin git@github.com:xxx/repo.git - 要么在 WSL 里启用 Git 凭证管理器：
git config --global credential.helper store，然后首次git push时手动输一次 PAT（Personal Access Token），后续就自动记住了 - 注意：
credential.helper store会明文保存 token 到~/.git-credentials，仅适合个人开发机
真正卡住人的地方，往往不是“怎么配”，而是“为什么配了还是不行”——绝大多数验证失败，都发生在 ssh-agent 环境没继承、密钥权限不对、或 git 用了 Windows 的 ssh 但路径在 WSL 下失效这三个环节。盯住 SSH_AUTH_SOCK、~/.ssh 权限、git config --get core.sshCommand 这三个点，比重装插件管用得多。
