codex - 💡(How to fix) Fix [VS Code extension / Linux] IpcRouterManager fails to start: EACCES creating /tmp/codex-ipc/ipc-<uid>.sock when directory is owned by another user

What version of the IDE extension are you using?

26.513.21555

What subscription do you have?

Team

Which IDE are you using?

VS Code

What platform is your computer?

Linux 5.15.0-174-generic x86_64 x86_64

What issue are you seeing?

The Codex extension fails to start on a multi-user Linux server because it cannot create its IPC socket. The extension creates a shared directory /tmp/codex-ipc/ with mode 0755 owned by whichever user starts the extension first. Other users on the same machine then get EACCES when trying to create their own ipc-<uid>.sock inside it.

Full error from the extension log:

2026-05-15 17:04:59.720 [error] [IpcRouterManager] Server error 
errorCode=EACCES 
errorMessage="listen EACCES: permission denied /tmp/codex-ipc/ipc-1111.sock" 
errorName=Error 
errorStack="Error: listen EACCES: permission denied /tmp/codex-ipc/ipc-1111.sock
    at Server.setupListenHandle [as _listen2] (node:net:1918:21)
    at listenInCluster (node:net:1997:12)
    at Server.listen (node:net:2119:5)
    at yf.startRouterIfNeeded (/path/to/.vscode-server/extensions/openai.chatgpt-26.513.21555-linux-x64/out/extension.js:422:16986)
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
    at async rl.connect (/path/to/.vscode-server/extensions/openai.chatgpt-26.513.21555-linux-x64/out/extension.js:422:18992)"

State of the directory on my machine:

$ id
uid=1111(userA) gid=1010(algorithm) groups=1010(algorithm)

$ ls -ld /tmp/codex-ipc/
drwxr-xr-x 2 userB algorithm 4096 May 15 16:48 /tmp/codex-ipc/

$ ls -la /tmp/codex-ipc/
drwxr-xr-x    2 userB algorithm   4096 May 15 16:48 .
drwxrwxrwt 3143 root  root      126976 May 15 17:03 ..
srwxr-xr-x    1 userB algorithm      0 May 15 16:48 ipc-1112.sock

The directory is owned by another user (userB, uid 1112) who started the extension earlier. With permission 0755, I (uid 1111) only have r-x on it, so listen() on /tmp/codex-ipc/ipc-1111.sock is denied by the kernel. Because /tmp has the sticky bit set, I also cannot rm the directory without sudo or help from userB.

Extension version: openai.chatgpt-26.513.21555-linux-x64 Environment: VS Code Remote-SSH to a shared Linux server (multiple users on the same host).

What steps can reproduce the bug?

1. Have a Linux server with multiple users (e.g. a shared dev box or a lab/HPC node).
2. As user A, connect via VS Code Remote-SSH and let the Codex extension start. It creates /tmp/codex-ipc/ with mode 0755, owned by user A, and a socket ipc-<uidA>.sock inside.
3. As user B, connect to the same server via VS Code Remote-SSH and start the Codex extension.
4. User B's extension tries to listen() on /tmp/codex-ipc/ipc-<uidB>.sock but fails with EACCES: permission denied, because the directory is not writable to user B.
5. User B cannot remove or fix the directory on their own due to the sticky bit on /tmp.

Minimal shell reproduction of the underlying permission issue:

# as userA
mkdir -m 0755 /tmp/codex-ipc
# as userB
python3 -c "import socket,os; s=socket.socket(socket.AF_UNIX); s.bind('/tmp/codex-ipc/ipc-test.sock')"
# PermissionError: [Errno 13] Permission denied

### What is the expected behavior?

The extension should choose an IPC location that is per-user by design, so that multiple users on the same host never collide. Any one of the following would fix it:

1. Preferred — use $XDG_RUNTIME_DIR (typically /run/user/<uid>/, created by systemd-logind with mode 0700 and owned by the user). This is the standard Linux location for per-user runtime sockets and avoids the problem entirely:
```bash
    ${XDG_RUNTIME_DIR}/codex/ipc.sock

1. Fallback — per-user directory under /tmp, e.g. /tmp/codex-ipc-<uid>/ created with mode 0700. This guarantees no cross-user interference.
2. Or — use the user's home/cache directory, e.g. ${XDG_CACHE_HOME:-$HOME/.cache}/codex/ipc.sock.
3. If /tmp/codex-ipc/ must remain a shared directory, it should be created with mode 01777 (sticky + world-writable, same semantics as /tmp itself) so that each user can create and remove their own socket without affecting others. The current 0755 is incompatible with the "shared parent, per-user sockets" design that the ipc-<uid>.sock naming scheme implies.

Additionally, the extension should:

• Detect stale socket files from a previous run of the same user and unlink() them before listen().
• Surface a clearer, actionable error message in the UI when this happens (currently the failure is silent unless the user opens the output panel).

Thanks!

Additional information

No response