›_ Codex Issues
Codex Issues / #21806

VS Code Remote-SSH: Codex panel intermittently stalls after per-user TMPDIR IPC fix; logs show unsupported workspace_dependencies, unhandled thread-stream-state-changed, and outbound queue full

Open 💬 4 comments Opened May 8, 2026 by mario-garbelli

What version of the VS Code extension are you using?

openai.chatgpt-26.506.21252-linux-x64

Which IDE are you using?

VS Code Remote-SSH

What platform is your computer?

Remote Linux shared multi-user host via VS Code Remote-SSH.

Sanitized environment:

  • Remote host: shared Linux server
  • User: non-root user, UID <uid>
  • VS Code Remote path: <remote-vscode-server-path>
  • Workspace: <workspace-root>
  • Test folder: <small-test-folder>
  • Private temp directory: <user-private-tmpdir>

Summary

The Codex VS Code extension intermittently enters a stalled/degraded state in VS Code Remote-SSH.

The earlier shared /tmp/codex-ipc issue appears to be mitigated: TMPDIR, TMP, and TEMP are now set to a user-private temp directory before the Remote-SSH extension host starts, and Codex creates its IPC socket under that directory.

However, the Codex panel can still become stuck with a permanent spinner/loading state. During the stall, the codex app-server process remains alive, IPC appears valid, and no repository/tool child processes are running. The logs instead show unsupported feature enablement, repeated unhandled broadcasts, queue overflow/backpressure, connector/logo fetch failures, and steering timeouts.

This looks like a residual Remote-SSH stability issue after IPC isolation is fixed, possibly involving protocol/capability mismatch, event-stream handling, or backpressure between the VS Code extension, extension host, and app-server.

What issue are you seeing?

Intermittently:

  • The Codex send button changes to a spinner/loading state and remains stuck.
  • A second request sometimes does not start.
  • extensionHost CPU usage rises significantly.
  • The codex app-server process remains alive.
  • Some turns appear to finish server-side but do not return complete trace/output to the VS Code UI.
  • Reloading/reconnecting VS Code Remote-SSH temporarily restores normal behavior, but the degraded state can return later.

Why this does not look like the original /tmp/codex-ipc issue anymore

This initially looked related to the global /tmp/codex-ipc issue on shared multi-user hosts.

I moved TMPDIR, TMP, and TEMP to a user-private directory before VS Code Remote-SSH starts the extension host.

Current process environment confirms:

TMPDIR=<user-private-tmpdir>
TMP=<user-private-tmpdir>
TEMP=<user-private-tmpdir>

Codex now creates IPC under:

<user-private-tmpdir>/codex-ipc/ipc-<uid>.sock

I verified that:

  • The socket exists.
  • The socket is owned by the correct user.
  • /proc/<codex-app-server-pid>/environ contains the user-private TMPDIR.
  • The codex app-server process remains alive during the stall.

Therefore, the original global /tmp/codex-ipc collision appears to be mitigated. The remaining failure seems to occur after IPC has been correctly scoped to a user-private temp directory.

Diagnostics during a stalled state

During a stalled state:

pstree shows: extensionHost -> codex app-server

The codex app-server process remains alive, but no child processes are observed, for example no:

git
bash
python
pytest
npm

This suggests that, at the time of the stall, the app-server is not actively executing repository/tool commands.

Current config / attempted mitigation

I attempted to reduce app/connector traffic with:

[apps._default]
enabled = false

Despite this, logs still show many plugin/app/connector-related events, including connector/logo fetches.

Key log evidence

Unsupported feature enablement
Features enabled enabledFeatures="..., workspace_dependencies, ..., apps, plugins, ..."
Request failed ... method=experimentalFeature/enablement/set ...
unsupported feature enablement `workspace_dependencies`: currently supported features are apps, memories, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation
Failed to sync experimental feature enablement

The extension appears to attempt enabling workspace_dependencies, but the app-server reports that this feature is unsupported.

Broadcast flood without handler
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

I observed hundreds of occurrences of this message in a single Codex.log.

Queue overflow / overload
dropping overload response ... outbound queue is full
Server overloaded; retry later.
Connector/logo fetch errors despite apps mitigation attempt
Error fetching error={"code":-32001,"message":"Server overloaded; retry later."} url=/aip/connectors/.../logo?theme=light
Error fetching error="TypeError: fetch failed" url=/aip/connectors/.../logo?theme=dark

Connector/app metadata or logo fetches still appear in the logs even after attempting to disable apps by default.

403 fetch errors
Error fetching httpStatus=403 statusText=Forbidden url=https://chatgpt.com/ces/v1/rgstr?...

The full URL has been intentionally redacted.

Steering timeout / no active turn
mcp_request_timeout conversationId=... method=turn/steer timeoutMs=30000
Error submitting steering turn for conversation ...
Received app server error error={"code":-32600,"message":"no active turn to steer"}

The full conversation/request identifiers have been intentionally redacted.

Expected behavior

  • The extension and app-server should agree on supported feature flags, or unsupported feature enablement should fail once without destabilizing the session.
  • Repeated thread-stream-state-changed broadcasts should either have a handler or should not overwhelm the extension host.
  • Connector/app metadata or logo fetch failures should not affect chat responsiveness.
  • Queue overflow/backpressure should not leave the UI stuck in a permanent spinner/loading state.
  • Remote-SSH should remain stable once IPC is correctly scoped to a user-private TMPDIR.

Actual behavior

  • The extension attempts to enable unsupported workspace_dependencies.
  • Hundreds of unhandled thread-stream-state-changed broadcasts appear in Codex.log.
  • Connector/logo fetches continue despite an apps mitigation attempt.
  • Queue overflow / overload appears in logs.
  • Steering requests time out and later return no active turn to steer.
  • The VS Code UI can become stuck in a spinner/loading state.

Related issues

  • Remote-SSH global /tmp/codex-ipc collision:

https://github.com/openai/codex/issues/17765

  • Remote-SSH 403/backend/plugin instability leading to queue overflow:

https://github.com/openai/codex/issues/16341

  • Extension event storm / high CPU / unhandled thread-stream-state-changed:

https://github.com/openai/codex/issues/15397

  • Streaming UI stalls with repeated thread-stream-state-changed:

https://github.com/openai/codex/issues/13343

Additional note

I have not attached full logs here because they may contain local paths, hostnames, usernames, UIDs, request/conversation IDs, connector IDs, workspace-specific identifiers, or other environment-specific details.

I can provide a sanitized Codex.log if useful, with local paths, hostnames, usernames, UIDs, request/conversation IDs, connector IDs, workspace names, repository names, and other identifying values removed.

If helpful, I can also provide a redacted timeline from a single stalled session showing the order of:

  1. unsupported workspace_dependencies
  2. repeated thread-stream-state-changed
  3. connector/logo fetch failures
  4. outbound queue full / overload
  5. turn/steer timeout
  6. no active turn to steer

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗