VSCode远程SSH下Codex插件403错误终极解决：代理、回调与IPC权限三重排查

May 7, 2026

先前我一直使用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插件最终得以顺畅登录远程开发环境。