›_ Codex Issues
Codex Issues / #32385

Codex VS Code extension hangs on loading screen in Remote-SSH, while Codex CLI works

Resolved 💬 11 comments Opened Jul 11, 2026 by dramarazad-debug Closed Jul 14, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

26.707.41301

What subscription do you have?

ChatGPT Business

Which IDE are you using?

Visual Studio Code with Remote-SSH

What platform is your computer?

"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })" Remote host: Ubuntu 22.04 x86_64, shared multi-user Linux server

What issue are you seeing?

The Codex IDE extension does not become usable when VS Code is connected to a Linux server through Remote-SSH.

The Codex CLI works correctly in the remote terminal, but the IDE sidebar remains stuck on the Codex loading logo, or partially renders with a disabled prompt box. Codex Settings also hangs.

The remote Codex CLI is installed and authenticated:

codex --version
codex-cli 0.144.1

codex login status
Logged in using ChatGPT

The Codex executable is available to the VS Code remote extension host through PATH.

The extension backend appears to start successfully:

Activating Codex extension
[CodexMcpConnection] Spawning codex app-server
[IpcRouter] I am the router
[CodexMcpConnection] Initialize received id=1

However, the sidebar remains stuck and cannot accept input.

Earlier, the extension failed with:

listen EACCES: permission denied /tmp/codex-ipc/ipc-<UID>.sock

This is a shared multi-user server, and /tmp/codex-ipc had been created by another user with permissions that did not allow my account to create a socket.

I configured user-private temporary directories through TMPDIR, TMP, and TEMP and restarted the VS Code Remote server. The EACCES error disappeared, but the Codex sidebar still hangs.

A later log also showed:

Request failed
method=fs/readFile
message="No such file or directory (os error 2)"

Other non-fatal-looking warnings include:

WARNING: failed to clean up stale arg0 temp dirs: Resource busy (os error 16)

Codex could not find bubblewrap on PATH.
Codex will use the bundled bubblewrap in the meantime.

All usernames, hostnames, home directories, workspace paths, UIDs, and internal group names have been redacted.

What steps can reproduce the bug?

  1. Use VS Code on a Windows computer.
  2. Connect to a shared Ubuntu 22.04 server using the VS Code Remote-SSH extension.
  3. Install the official Codex IDE extension on the remote SSH host.
  4. Install and authenticate the Codex CLI on the remote server.
  5. Confirm that the CLI works:
  • codex --version
  • codex login status
  • codex
  1. Confirm that the remote VS Code extension host PATH contains the Codex executable directory.
  2. Open the Codex sidebar in the Remote-SSH VS Code window.
  3. Observe that the sidebar remains on the loading logo, or renders a disabled prompt box.
  4. Open Codex Settings and observe that it also hangs.

The issue persists after:

  • reinstalling the extension on the remote host
  • switching between stable and pre-release extension versions
  • installing an older extension version
  • reloading the VS Code window
  • restarting the extension host
  • killing and restarting the VS Code Remote server
  • confirming CLI authentication
  • confirming the remote extension host PATH
  • confirming that ~/.codex/config.toml is valid
  • configuring private TMPDIR, TMP, and TEMP directories

What is the expected behavior?

The Codex sidebar should initialize fully inside the VS Code Remote-SSH workspace and allow me to enter prompts, interact with the remote repository, and open Codex Settings.

The IDE extension should work when the Codex CLI is installed, available on the remote extension-host PATH, and authenticated.

Additional information

The CLI works correctly on the same remote server and in the same workspace.

The configuration file is minimal and valid:

model = "gpt-5.6-luna"
model_reasoning_effort = "low"

[projects."<REMOTE_WORKSPACE_PATH>"]
trust_level = "trusted"

The remote extension host PATH contains:

<USER_HOME>/.local/bin

The Codex executable resolves correctly through a symlink to the standalone Codex installation.

The app server reaches:

[CodexMcpConnection] Initialize received id=1

but the IDE UI remains unusable.

This appears specific to the IDE extension under Remote-SSH on a shared multi-user Linux server.

I can provide:

  • a screenshot of the stuck sidebar
  • complete redacted Codex Output logs
  • exact VS Code version
  • exact extension version
  • redacted output of ls -ld /tmp/codex-ipc

<img width="202" height="511" alt="Image" src="https://github.com/user-attachments/assets/bb1eac8a-7022-410c-a5a7-7945e2d571fb" />

View original on GitHub ↗

11 Comments

github-actions[bot] contributor · 9 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32109
  • #32041
  • #31149

Powered by Codex Action

lou-16 · 7 days ago

@dramarazad-debug hi, we had a similar situation arise at our org too. quick context: this is on CentOS, multi-user shared box, several people using codex/vscode-server on the same machine. don't know what your output for the extension was but in our case the codex extension output was:

2026-07-13 11:52:57.211 [error] [IpcRouterManager] Server error errorCode=EACCES errorMessage="listen EACCES: permission denied /tmp/codex-ipc/ipc-1058.sock" errorName=Error errorStack="Error: listen EACCES: permission denied /tmp/codex-ipc/ipc-1058.sock\n\tat Server.setupListenHandle [as _listen2] (node:net:1986:21)\n\tat

this reflected that the folder was created by a different user than the one we were logged in as, which didn't give us the write access the extension needed to set up its IPC. confirmed this with ls -la /tmp/codex-ipc:

total 20
drwxr-xr-x    2 xk4j9zq    xk4j9zq        27 Jul 13 09:32 .
drwxrwxrwt. 103 root       root       163840 Jul 13 11:54 ..
srwxr-xr-x    1 xk4j9zq    xk4j9zq         0 Jul 13 09:32 ipc-1009.sock

so the folder and socket were both owned by a different user (xk4j9zq), not us.

to fix this we first tried allowing everyone to write to the folder by changing /tmp/codex-ipc to 1777 root:root, but this only fixes the immediate EACCES for the user, the underlying issue is still there since the old socket/folder is still owned by whoever created it first.

then we moved forward, and got this in the output, which matches your given output. 

2026-07-13 12:48:50.308 [info] Activating Codex extension
2026-07-13 12:48:50.309 [info] [CodexMcpConnection] Spawning codex app-server
2026-07-13 12:48:51.016 [info] [IpcRouter] I am the router
2026-07-13 12:48:51.022 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
2026-07-13 12:48:51.660 [info] [IpcRouter] I am the router
2026-07-13 12:48:55.822 [info] [IpcRouter] I am the router
2026-07-13 12:48:56.917 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
2026-07-13 12:49:02.411 [info] [CodexMcpConnection] Initialize received id=1

what actually worked was killing off codex/vscode-server processes for our own user, since there was a stale process from my user.

but yeah the underlying issue still persists imo, feels like these perms shouldn't be broken like this in the first place, or there should at least be a proper workaround/cleanup instead of having to chmod /tmp or kill processes manually. anyone know if there's a real fix planned for this?

Aquila-f · 6 days ago

Same issue here.

I'm experiencing the same issue with the latest Codex extension.

Environment

  • VS Code: 1.128.0
  • OpenAI Codex extension: 26.707.71524
  • Remote SSH extension: 0.124.0
  • Local machine: macOS Sequoia 15.6 (Apple Silicon)
  • Remote host: NVIDIA DGX Spark
  • Remote OS: Ubuntu 24.04.4 LTS
  • Remote architecture: Linux ARM64 (aarch64)

Behavior

  • Codex works normally in a local VS Code window.
  • When connected via Remote SSH, the Codex sidebar never finishes loading and remains on the OpenAI logo indefinitely.
  • The extension is installed and enabled on the remote host.

Additional observations

  • GitHub Copilot Chat works normally in the same Remote SSH session.
  • Claude Code also works normally in the same Remote SSH session.
  • I don't see any 401/403 authentication errors or network-related errors in the developer console.
  • Reinstalling the extension did not change the behavior.
  • The issue is reproducible 100% of the time.

If there's anything else I can provide (logs, diagnostics, or additional environment information), I'd be happy to help.

---

This appears to specifically affect Remote SSH on Linux ARM64 (aarch64). I have not been able to reproduce the issue on a local VS Code window using the same account and extension version. (local is on mac)
vboussange · 6 days ago

Same issue here on Remote SSH on Linux. After some time, I get an error from VSCode: "The window is not responding". I have tried switching to an older version of the Codex extension, without success.

dramarazad-debug · 6 days ago

The problem got solved by launching VS code with the --disable-gpu.
I hope openAI or VScode will resolve this issue soon.

anton-expertstudio · 6 days ago

NOT solved.

I've been having this issue on and off for several weeks - likely an IPC socket race because I have multiple VS Code windows pointing to the same server.

But now it's unusable entirely.

k-kobi · 3 days ago

I encountered the same Codex VS Code Remote-SSH issue on a shared multi-user Linux HPC cluster. The Codex backend initialized successfully, but the IDE sidebar remained stuck loading and unusable.

The underlying problem in my case was the shared /tmp/codex-ipc directory. Running:

ls -ld /tmp/codex-ipc

showed that the directory had been created by another user and was not writable by my account:

drwxr-xr-x. 2 <OTHER_USER> <GROUP> ... /tmp/codex-ipc

I fixed the issue by creating a private temporary directory in my home directory:

mkdir -p ~/.tmp/codex
chmod 700 ~/.tmp ~/.tmp/codex

I then added the following environment variables to ~/.bashrc:

export TMPDIR="$HOME/.tmp/codex"
export TMP="$TMPDIR"
export TEMP="$TMPDIR"

After sourcing the updated configuration:

source ~/.bashrc

I restarted the VS Code Remote server:

pkill -u "$USER" -f vscode-server

So the working fix was to redirect TMPDIR, TMP, and TEMP away from the shared system /tmp directory to a private user-owned temporary director.

ndvbd · 2 days ago

Same issue here.... Very often stuck on load.

sellrock-de · 2 days ago

Same here

husain-zaidi · 1 day ago

set ulimit -n 10000
https://github.com/openai/codex/issues/32530#issuecomment-5012908167
This worked consistently for me

salihmarangoz · 1 day ago

I think I solved the problem. When I started from the GNOME it wasn't working, but it was working from the terminal. My finding was; *.desktop files redirects to /usr/share/code/code, but 'which code' outputs /usr/bin/code. So, I created .desktop files for my user to also persist this fix between updates.

My OS is Ubuntu 24.04 LTS. I used codex to solve the problem and summarize it:

VSCODE_CODEX_FIX.md