codex - 💡(How to fix) Fix VS Code Remote-SSH extension uses global /tmp/codex-ipc on multi-user Linux hosts, causing EACCES and cross-user IPC collisions [1 comments, 2 participants]

What issue are you seeing?

The official OpenAI Codex VS Code extension becomes unusable when it is used through VS Code Remote-SSH on a shared multi-user Linux host.

The extension appears to use a fixed global IPC directory under /tmp:

/tmp/codex-ipc

and then tries to create a Unix socket inside it, for example:

/tmp/codex-ipc/ipc-1565.sock

On a multi-user host, if that directory was previously created by another user, my user cannot create its own socket there. The extension then fails during initialization with repeated permission errors and the chat UI becomes stuck.

Observed error from the VS Code logs:

[IpcRouterManager] Server error errorCode=EACCES errorMessage="listen EACCES: permission denied /tmp/codex-ipc/ipc-1565.sock"

Important detail: this failure happens before sending any prompt. Simply opening the Codex panel is enough to trigger the error repeatedly.

Visible behavior in the UI:

• the Codex input box becomes blocked or unresponsive
• the send button changes to a loading/spinner state
• no request is processed
• the same IPC error keeps appearing in the logs

This does not appear to be a workspace/context problem. It reproduces even in an empty directory.

This seems to be a design issue for shared Linux systems, because the IPC directory is global rather than isolated per user or per session.

What steps can reproduce the bug?

1. Use the official OpenAI Codex extension in VS Code.
2. Connect from a local machine to a remote shared Linux server/cluster using VS Code Remote-SSH.
3. On that remote Linux host, let one user initialize the extension first so that /tmp/codex-ipc is created under that user's ownership.
4. Connect to the same remote host as a different Linux user.
5. Open the Codex panel in VS Code.

At that point, the extension immediately starts failing with EACCES when trying to create its IPC socket inside /tmp/codex-ipc.

In my case, the relevant remote state looked like this:

$ ls -ld /tmp /tmp/codex-ipc drwxrwxrwt 183 root root 102400 Apr 13 20:52 /tmp drwxr-xr-x 2 jgalvan users 4096 Jan 29 10:29 /tmp/codex-ipc

My user was different from jgalvan, so I did not have write permission inside /tmp/codex-ipc.

I also confirmed that this is not caused by the current project directory, because the same failure happens even when VS Code is opened in an empty folder on the remote host.

I also tried setting TMPDIR to a private per-user directory, but the extension still attempted to use /tmp/codex-ipc, so it does not seem to derive the IPC location from TMPDIR.

What is the expected behavior?

The extension should work correctly on multi-user Linux hosts used through VS Code Remote-SSH.

It should not use a single global IPC directory shared by all users, such as /tmp/codex-ipc.

Instead, it should create IPC resources in a location that is isolated per user or per session, for example:

• XDG_RUNTIME_DIR, when available
• /tmp/codex-ipc-$UID
• /tmp/codex-ipc-$USER
• another unique user-scoped or session-scoped runtime directory

The socket names should also be unique per process/session, not reused globally across users.

If stale sockets or directories already exist, the extension should handle them safely without causing cross-user conflicts or permanent initialization failure.

Opening the Codex panel should not fail just because another user has previously used the extension on the same remote Linux node.

Additional information

Environment:

• Product: official OpenAI Codex VS Code extension
• Usage mode: VS Code Remote-SSH
• Remote OS: shared multi-user Linux server/cluster
• Local machine: not relevant to the failure, because the problem occurs on the remote host before any prompt is sent
• Codex CLI: not installed; this is the VS Code extension only

Why this matters:

• This is not just a stale-file cleanup issue.
• On shared systems, a global /tmp/codex-ipc path can cause repeated conflicts between different users.
• Even if directory permissions were relaxed to allow writes by multiple users, that would still be unsafe, because users could collide on socket names or potentially connect to the wrong IPC endpoint.

Observed socket/directory names on the system included:

• ipc.sock
• ipc-1255.sock
• ipc-1565.sock

These names do not appear to be scoped by username or session identity.

Representative log entry:

2026-04-13 20:51:59.898 [error] [IpcRouterManager] Server error errorCode=EACCES errorMessage="listen EACCES: permission denied /tmp/codex-ipc/ipc-1565.sock" errorName=Error errorStack="Error: listen EACCES: permission denied /tmp/codex-ipc/ipc-1565.sock\n\tat Server.setupListenHandle [as _listen2] (node:net:1918:21)\n\tat listenInCluster (node:net:1997:12)\n\tat Server.listen (node:net:2119:5)\n\tat Ef.startRouterIfNeeded (.../out/extension.js:...)\n\tat process.processTicksAndRejections (node:internal/process/task_queues:103:5)\n\tat async La.connect (.../out/extension.js:...)"

Suggested fix:

• prefer XDG_RUNTIME_DIR for IPC on Linux
• otherwise create a per-user runtime directory
• generate per-session socket names
• clean up stale IPC paths safely