codex - 💡(How to fix) Fix [Persistent multi-version bug for VS Code SSH Linux] enters overload loop and collapse after threads stuck and recovery [3 comments, 2 participants]

Server overloaded; try later

However, the evidence suggests that this is a local Codex app-server / transport / old-thread recovery problem rather than a normal backend overload.

Key observations:

codex login status:
Logged in using ChatGPT
exit code: 0

But a simple CLI smoke test times out:

codex exec smoke test:
failed to refresh available models: timeout waiting for child process to exit

The Codex logs contain repeated local overload and thread recovery signals:

outbound queue is full
dropping overload response
thread/resume
thread-read-state
server overloaded
PendingMigrationError
Codex app-server process exited unexpectedly
signal SIGTERM
Codex process is not available
disconnected

Recent keyword counts from the logs:

outbound queue is full: 12464
dropping overload response: 12464
server overloaded: 22047
PendingMigrationError: 225
thread/resume: 121
thread-read-state: 108
not-connected: 14

The app-server eventually exits unexpectedly:

Codex app-server process exited unexpectedly
signal SIGTERM

After that, the extension reports that the Codex process is unavailable or disconnected.

I also saw many 401 and 403 entries in the logs, but these appear to be secondary connector or network noise rather than the primary failure, because ChatGPT login status itself succeeds.

The most reliable temporary workaround is to rename or remove the active .codex directory, let Codex create a fresh one, and then selectively copy back only minimal files such as config.toml and auth.json. Copying old session data back can retrigger the failure.

This strongly suggests a local state / session hydration / app-server backpressure issue rather than a pure account, login, or model availability issue.

### What steps can reproduce the bug?

The exact failure is easiest to reproduce in my existing VS Code Remote-SSH HPC environment with an existing `.codex` state containing old sessions.

Approximate reproduction pattern:

1. Connect to a remote Linux HPC server using VS Code Remote-SSH.
2. Use the Codex VS Code extension on the remote side.
3. Use an existing active `.codex` directory that contains old sessions from previous Codex extension versions.
4. Open the Codex panel in VS Code.
5. Let the extension attempt to list, read, or resume old threads.
6. One or more old large threads appear to trigger repeated `thread/resume` or `thread-read-state` activity.
7. Logs begin showing repeated local transport overload messages:

```text
outbound queue is full
dropping overload response
thread/resume
server overloaded
The UI then repeatedly shows:
Server overloaded; try later
Eventually, existing conversations cannot be loaded and new conversations cannot be started.
The app-server exits unexpectedly with SIGTERM.
The extension reports that the Codex process is unavailable or disconnected.
The only reliable way to recover is to rename or remove the active .codex directory and let Codex create a fresh one.

Generic workaround that temporarily restores usability:

# Stop Codex-related processes first.
pkill -u "$USER" -f 'codex app-server' 2>/dev/null || true
pkill -u "$USER" -f 'openai.chatgpt-.*/codex' 2>/dev/null || true

# Freeze active Codex home.
mv "$HOME/.codex" "$HOME/.codex.frozen.$(date +%Y%m%d-%H%M%S)"

# Create a clean active Codex home.
mkdir -m 700 "$HOME/.codex"

Then I selectively copy only minimal files such as:

config.toml
auth.json

I avoid copying the entire old sessions, archived_sessions, SQLite state files, logs, or session index back into the active .codex directory.

Important: this is only a workaround. It makes Codex temporarily usable again, but old threads remain dangerous to open or resume.

### What is the expected behavior?

Codex should not allow one problematic old thread, local state migration issue, or failed thread recovery attempt to make the entire VS Code extension unusable.

Expected behavior:

1. A problematic old thread should be skipped, quarantined, or marked as failed.
2. Failed `thread/resume` or `thread-read-state` operations should not be retried until the local outbound queue is saturated.
3. The local app-server should apply backpressure, circuit-breaking, or failure isolation.
4. New threads should remain usable even if one old thread cannot be resumed.
5. The app-server should recover cleanly after a failed thread hydration attempt.
6. The UI should distinguish local app-server / transport overload from actual remote server overload.
7. The UI should not show only:

```text
Server overloaded; try later

when the evidence points to local Codex app-server / transport overload.

A more accurate error would be something like:

Local Codex app-server overloaded or disconnected

or:

Failed to resume old thread. Start in safe mode or quarantine this thread?

Useful recovery features would include:

A safe mode that starts Codex without loading or hydrating old sessions.
A way to disable automatic old-thread recovery on startup.
A supported command to rebuild local session indexes and state safely.
Automatic quarantine for threads that repeatedly fail thread/resume or thread-read-state.
A way to preserve new-thread functionality even when old session recovery fails.

### Additional information

Environment:
- VS Code with Remote-SSH
- Remote Linux HPC server
- Codex IDE extension installed on the remote side
- Authentication through ChatGPT login
- Model involved: gpt-5.5
- The issue is more likely to appear after multi-turn sessions, especially with fast/high or fast/xhigh reasoning.

Version history:

Last known stable version in my environment:
openai.chatgpt-26.406.40811-linux-x64

Affected versions:
Newer versions after 26.406.40811, including versions required for GPT-5.5 usage.

Why this looks like a local app-server / transport / session recovery bug:

codex login status succeeds.
Removing or renaming the local .codex state makes Codex usable again.
The failure is correlated with old thread read/resume attempts.
Logs show massive local transport queue saturation:
outbound queue is full
dropping overload response
The app-server exits with SIGTERM.
New threads fail only after the local app-server enters this overloaded state.
The UI message says server overloaded, but the evidence points to local app-server / transport queue overload.

Impact:

Existing long-running research/coding threads cannot be opened safely.
Once a problematic old thread triggers the overload loop, even new threads cannot be started.
The user has to manually freeze or surgically edit local Codex state to recover.
The issue recurs after upgrading to newer versions needed for GPT-5.5.
The error message is misleading because it suggests a generic remote server overload, while the evidence points to local app-server/session recovery overload.

Privacy note:

I am intentionally not attaching raw logs or full transcripts in the initial report because they may contain private paths, usernames, research project names, prompts, and local file names. I can provide redacted excerpts that include only app-server, transport, and thread recovery diagnostics if needed.