Found an issue with the latest update about IDE extension: IPC socket dir /tmp/codex-ipc is not user-namespaced — EACCES on shared multi-user hosts (HPC login nodes)
The thing is that I cannot open my codex extension on my Cursor while connected with our university's cluster.
On a shared multi-user Linux host (university HPC login node, RHEL 9), the Codex IDE extension fails to start: the panel never connects, and the extension log spams once per second:
[error] [IpcRouterManager] Server error errorCode=EACCES
errorMessage="listen EACCES: permission denied /tmp/codex-ipc/ipc-<pid>.sock"
at cg.startRouterIfNeeded (.../openai.chatgpt-26.602.71036-linux-x64/out/extension.js)
at async pl.connect (...)
I then checked with Claude code, here is the summary:
Root cause
IpcRouterManager binds its socket under a fixed shared path os.tmpdir()/codex-ipc/ (extension.js: path.join(os.tmpdir(), "codex-ipc"), created with default 0755 perms). On a multi-user machine, whichever user runs Codex first owns /tmp/codex-ipc; every other user then gets EACCES forever and the extension is unusable for them. On our cluster the directory was created by another user weeks ago, so the extension is permanently broken for everyone else on that node.
This regressed in the extension update 26.601.20914 → 26.602.71036 (codex-cli 0.137.0-alpha.4): 26.601 had no IpcRouterManager and worked fine in the same environment (VS Code/Cursor Remote-SSH into the cluster).
Expected behavior
The IPC directory should be per-user, e.g. $XDG_RUNTIME_DIR/codex-ipc, os.tmpdir()/codex-ipc-$UID with 0700 perms, or under $CODEX_HOME. Also, a fatal bind failure should surface as a user-visible error instead of a silent 1/s retry loop.
Workaround
Setting TMPDIR to a per-user directory (e.g. /tmp/$USER) before the remote server starts fixes it, since the path is derived from os.tmpdir().
Environment
- Extension: openai.chatgpt 26.602.71036 (codex-cli 0.137.0-alpha.4)
- Host: shared HPC login node, RHEL 9.x, x86_64, accessed via Cursor Remote-SSH
- Worked on: same setup with extension 26.601.20914
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗