VSCode远程SSH下Codex插件403错误终极解决:代理、回调与IPC权限三重排查
先前我一直使用Cursor进行“氛围编程”(vibe coding),却频频被token快速消耗的问题困扰。恰好我订有ChatGPT Plus,于是决定转投Codex体系。
然而,受众所周知的环境限制,即使开启了网络代理,当我在VSCode中通过Remote-SSH连接远程服务器后,依然遇到了登录异常,见下图:
本以为这只是个小网络故障,结果从下午排查到深夜。最终定位到三个层面的问题交织在一起:代理出口、OAuth回调以及插件IPC权限。过程踩了不少坑,整理出来希望能帮到有同样遭遇的朋友。
首先,我在远程服务器上确认当前代理链路走向:
echo $http_proxy $https_proxy $all_proxy
curl -x http://127.0.0.1:7890 https://api.ipify.org; echo
curl -x http://127.0.0.1:12789 https://api.ipify.org; echo
发现本机7890端口已被占用。我便将远程入口端口改为12789,并让它转发至本机实际代理端口(本机为7897)。
本机SSH config最终配置如下:
Host <你的服务器名称>
HostName <你的服务器IP>
User <你的用户名>
RemoteForward 12789 127.0.0.1:7897
LocalForward 1455 127.0.0.1:1455
两条转发缺一不可。RemoteForward负责让远程服务器借助本机代理出网,LocalForward则用于浏览器OAuth回调回流至远程服务器的1455端口。
之后回到远程,将Shell环境中的代理统一指向12789(即SSH反向转发入口):
export http_proxy=http://127.0.0.1:12789
export https_proxy=http://127.0.0.1:12789
export all_proxy=socks5h://127.0.0.1:12789
export NO_PROXY=localhost,127.0.0.1,::1
export no_proxy=$NO_PROXY
验证出网是否成功:
curl --max-time 10 -x http://127.0.0.1:12789 https://api.ipify.org; echo
此时返回了一个新的出口IP,表明远程已确实走通了本机代理链路。
接着,我在远程的Cursor设置里配置HTTP代理:
{
"http.proxy": "http://127.0.0.1:12789",
"http.proxySupport": "on",
"http.noProxy": ["localhost", "127.0.0.1", "::1"]
}
至此,网络连接和OAuth回调环节基本没问题,已经能够通过Codex CLI成功登录。然而,Codex插件却在这时卡死不动。
这一步最为坑人,起初我一度以为是网络问题再次发作。后来仔细查看日志,才发现是IPC权限错误。排查使用了下面几条命令:
grep -R "codex-ipc\|EACCES" ~/.cursor-server/data/logs -n
ls -la /tmp/codex-ipcid
结果发现机器上/tmp/codex-ipc的属主是另一个用户,权限为drwxrwxr-x,我并无写入权限,因此插件无法在其中创建ipc-1007.sock。解决办法并非重装插件,而是给自己设立一个私有的TMPDIR,让IPC不再落入共享的/tmp/codex-ipc中。
先创建目录并设置权限:
mkdir -p ~/.tmp
chmod 700 ~/.tmp
然后在~/.bashrc、~/.profile和~/.bash_profile三个文件中均加入以下内容:
: "${TMPDIR:=${HOME}/.tmp}"
mkdir -p "$TMPDIR"
chmod 700 "$TMPDIR" 2>/dev/null || true
export TMPDIR
整个过程涉及代理穿透、OAuth回流与IPC权限隔离,环环相扣。虽然知乎和小红书上或许有更便捷的方案,但通过对这三层的逐一修复,Codex插件最终得以顺畅登录远程开发环境。