Codex Desktop Keeps Exiting? Update Old SSH App Servers

If Codex Desktop starts repeating app/installed and app/list after it auto-connects to SSH hosts, isolate any host running an older Codex app server before changing local state. Open Settings > Connections, disconnect one mismatched SSH host, restart Codex Desktop, and watch the app while idle. Then update that host's Codex CLI through its supported installer and reconnect it alone.

Do not delete ~/.codex, clear task history, expose the app server to the network, or kill every Codex process. Current reports point to a compatibility loop between a newer desktop client and older remote app servers, but they do not establish a universal root cause or a released upstream fix.

Confirm the Exact Loop

This guide applies when the failure starts after an SSH connection becomes ready and has several of these signs:

• the desktop app exits silently after roughly 10 to 35 minutes;

• logs repeat app/installed and app/list while no remote task is running;

• the older server rejects app/installed with JSON-RPC error -32600 or an unknown variant message;

• request or pending-operation counts keep rising while the app is idle; and

• local and remote codex --version output differs.

One current Windows report recorded thousands of app/installed requests and unknown variant errors before silent exits. A separate macOS Remote Control report described the same rejected method and unusually high relay traffic against an older remote app server. These reports make the version boundary worth testing; they do not prove that every Codex exit is this bug.

Compare Local and Remote Versions

Record the desktop build and each SSH host before updating anything. In Codex Desktop, open the app's About panel for the local build. Then connect to each configured host in a normal terminal and run:

codex --version

For a macOS or Linux host with a concrete alias in ~/.ssh/config, a read-only one-liner is also useful:

ssh devbox 'command -v codex && codex --version'

Replace devbox with the exact alias shown in Settings > Connections. OpenAI's remote-connections documentation says the desktop app discovers concrete SSH aliases and starts the remote Codex app server through SSH using the login shell. If command -v codex fails in a normal login shell, fix that PATH or installation problem before treating the protocol error as a version mismatch.

Keep a small table:

Do not infer compatibility from the hostname or operating system. The useful evidence is which exact remote version was connected when the loop began.

Isolate One SSH Host at a Time

Save or stop any active remote task first. Then:

1. Open Settings > Connections in Codex Desktop.

2. Disconnect the oldest or most mismatched SSH host.

3. Fully quit and reopen the desktop app.

4. Leave it idle for at least 10 minutes while watching for new app/installed, app/list, or -32600 entries.

5. Reconnect only that host and repeat the same observation window.

If the loop disappears while the host is disconnected and returns after that host reconnects, you have a clean A/B result. Repeat the process for other hosts instead of disconnecting all of them permanently.

This isolation matters because Codex can auto-connect more than one configured host. Updating an unrelated host or restarting only the local app may appear to help for a few minutes while the incompatible connection has not yet become ready.

Update the Remote CLI Through Its Owner

If the Connections UI shows Restart to update your CLI version, use that supported path and let the remote connection restart. Otherwise, update the remote codex installation through the same installer or package manager that owns the path you recorded.

For a macOS or Linux host installed with OpenAI's standalone installer, the official CLI page currently provides:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Do not run that command over an existing package-manager installation without first checking ownership. If the binary came from another supported installation method, use that method's update flow. Installing a second copy can leave the SSH login shell pointing at the older binary and make the mismatch harder to see.

After updating, start a fresh SSH login shell and run codex --version again. Reconnect only the repaired host from Codex Desktop.

Verify the Loop Is Gone

Use observable checks rather than a successful launch alone:

• no new unknown variant app/installed or JSON-RPC -32600 entry appears during a 10-minute idle window;

• request and pending-operation counts stay flat while idle;

• the SSH host reaches ready state once and remains connected;

• one small read-only remote task completes; and

• Codex Desktop remains open for longer than the previous failure interval.

If the loop continues with matching current versions, preserve the version table and sanitized counts. The mismatch hypothesis failed for that host, so repeated reinstalls are unlikely to add useful evidence.

Avoid Destructive False Fixes

Do not delete local task history, remote worktrees, SSH keys, or the entire Codex configuration. Those files are not shown to cause the protocol negotiation loop in the current reports.

Do not open the remote app-server port to the public internet, weaken SSH host verification, disable authentication, or paste credentials into an issue. Codex Desktop already uses SSH for the supported connection path. Changing the security boundary does not make an older protocol implementation understand a newer method.

Do not terminate every Codex process as a standing workaround. A restart is useful for a bounded A/B test, but it does not repair the version boundary and can interrupt unrelated local or remote tasks.

Monitor the Upstream Issues With Aident Loadout

You can check the two source reports without repeatedly browsing or giving an agent a GitHub token. Start with this exact setup phrase:

Follow https://aident.ai/SETUP.md

Then ask:

Check Aident Loadout authentication and Vault status. Search the staging capability catalog for the current read-only GitHub issue lookup Action, inspect its schema, and preflight exact lookups for openai/codex issues 37690 and 37355. If the Action is free and the inputs are valid, execute it and return only issue number, state, updated time, labels, comment count, reaction count, title, and canonical URL. Do not comment, react, edit, close, label, publish, expose credentials, use Bash, or open SSH connections.

The result is measurable: both issue records are current, the response is bounded to reviewable fields, and no GitHub write or provider credential appears in the conversation.

Set up Aident Loadout for bounded issue monitoring.

Report a Clean Reproduction

If a current remote CLI still triggers the loop, add evidence to the closest open issue instead of filing a title-only duplicate. Include:

• Codex Desktop build, local CLI version, and remote CLI version;

• desktop operating system and remote operating system;

• whether the connection was automatic or manually selected;

• sanitized counts for app/installed, app/list, -32600, and the maximum pending requests;

• time from connection-ready to exit or traffic growth;

• the one-host disconnect and reconnect result; and

• whether updating the remote CLI changed the behavior.

Remove hostnames, usernames, file paths, task content, tokens, and SSH configuration secrets. A short version matrix plus an A/B timeline is more useful than a complete log archive.

Sources

• OpenAI: Remote connections

• OpenAI: Codex CLI installation and updates

• OpenAI Codex issue 37690: older SSH app servers loop on app/installed

• OpenAI Codex issue 37355: Remote Control app-server version mismatch

• OpenAI Codex app-server protocol source

Refresh this guide when either issue closes with a confirmed fix, OpenAI documents an app-server compatibility requirement, or a Codex release changes SSH app-server negotiation.