›_ Codex Issues
Codex Issues / #31396

Codex CLI 0.142.5: app-server crashes with SIGABRT on Linux Mint 22.3

Open 💬 2 comments Opened Jul 7, 2026 by DennisNoy197

What version of Codex CLI is running?

codex-cli 0.142.5

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.8.0-134-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Terminal emulator: -VS Code integrated terminal -Linux Mint Terminal | Multiplexer: none

Codex doctor report

Abgebrochen (Speicherabzug geschrieben)

What issue are you seeing?

Codex CLI crashes on Linux Mint 22.3 shortly after startup. The app-server exits unexpectedly with SIGABRT.

This may be related to the thread_tools feature/config issue reported in #29140, but my case is different because it happens with the CLI directly on Linux Mint, not only in the VS Code extension or Desktop app.

Possibly related issues:

#29140 — thread_tools unknown feature key / app-server crash
#21339 — Linux app-server / npm wrapper / SIGABRT behavior
#17473 — CODEX_HOME under /tmp helper alias warning

What steps can reproduce the bug?

Run Codex CLI with a fresh temporary CODEX_HOME:

CODEX_HOME=/tmp/codex-debug/home \
RUST_BACKTRACE=full \
codex exec --skip-git-repo-check "Antworte nur mit OK."

What is the expected behavior?

Codex CLI should execute the prompt normally, or at least return a recoverable error message instead of crashing the app-server with SIGABRT.

Additional information

This looks related to #29140 because of the thread_tools feature/config message and the app-server crash, but it may be a separate Linux CLI issue because:

This happens on Linux Mint 22.3 using the CLI directly.
The process exits with SIGABRT.
The crash continues even after using a fresh temporary CODEX_HOME.

Should this be tracked as a duplicate of #29140, or is this a separate Linux CLI/app-server crash?

Codex CLI Crash on Linux Mint.pdf

View original on GitHub ↗

2 Comments

DennisNoy197 · 1 month ago

Additional diagnostic information:

The issue has been labeled CLI, exec, app-server, and bug, which matches the observed failure.

One detail that may be relevant: codex doctor itself does not produce a normal report on my system. It aborts with:

Abgebrochen (Speicherabzug geschrieben)

So the crash is not limited to codex exec; at least codex doctor also aborts.

I can provide additional sanitized diagnostics if useful. Please let me know which of the following would be most helpful:

RUST_BACKTRACE=full codex doctor
RUST_BACKTRACE=full codex exec --skip-git-repo-check "Antworte nur mit OK."
coredumpctl list | grep codex
coredumpctl info <PID-or-index>

I will avoid posting any tokens, private repository content, or session contents publicly.

DennisNoy197 · 29 days ago

Update: crash isolated to WebSocket transport; HTTP workaround restores CLI and VS Code

I performed additional testing on Linux Mint 22.3 and was able to isolate the failure more precisely.

Current versions tested

  • Codex CLI upgraded from 0.142.5 to 0.146.0
  • VS Code extension: openai.chatgpt@26.5721.30844
  • Linux Mint 22.3 Cinnamon, x86_64

Findings

  1. Updating from 0.142.5 to 0.146.0 removed the earlier stale model-cache error, but did not fix the SIGABRT crash.
  1. The standalone CLI still crashes with:
Abgebrochen (Speicherabzug geschrieben)

Reproduction:

codex exec --skip-git-repo-check "Antworte nur mit OK."
  1. Disabling features.code_mode_host does not change the result:
codex exec \
  -c features.code_mode_host=false \
  --skip-git-repo-check \
  "Antworte nur mit OK."

This still aborts with SIGABRT.

  1. coredumpctl confirms SIGABRT for both binaries:
  • Standalone Codex CLI 0.146.0
  • The Codex binary bundled with the VS Code extension:

~/.vscode/extensions/openai.chatgpt-26.5721.30844-linux-x64/bin/linux-x86_64/codex

Therefore, reinstalling VS Code alone would not address the problem.

  1. With RUST_LOG=debug, normal HTTPS requests complete successfully:
  • authentication succeeds
  • analytics endpoint returns HTTP 200
  • model-list endpoint returns HTTP 200
  • plugin runtime initializes

The process aborts immediately after starting the WebSocket connection to:

wss://chatgpt.com/backend-api/codex/responses

The last relevant log messages show the WebSocket connection startup and Rustls certificate initialization. No recoverable error or Rust panic/backtrace is printed before SIGABRT.

Successful workaround

Forcing Codex to use the Responses API without WebSockets makes the same command complete successfully:

codex exec \
  -c 'model_provider="chatgpt_http"' \
  -c 'model_providers.chatgpt_http.name="ChatGPT HTTP"' \
  -c 'model_providers.chatgpt_http.base_url="https://chatgpt.com/backend-api/codex"' \
  -c 'model_providers.chatgpt_http.wire_api="responses"' \
  -c 'model_providers.chatgpt_http.requires_openai_auth=true' \
  -c 'model_providers.chatgpt_http.supports_websockets=false' \
  --skip-git-repo-check \
  "Antworte nur mit OK."

Result:

provider: chatgpt_http
...
codex
OK

I then added the following permanent configuration to ~/.codex/config.toml:

model_provider = "chatgpt_http"

[model_providers.chatgpt_http]
name = "ChatGPT HTTP"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

After restarting VS Code:

  • codex exec works normally
  • the ChatGPT/Codex VS Code extension works normally
  • no SIGABRT occurs

Conclusion

This appears to be a native Linux crash specifically in, or triggered by, the WebSocket transport path. The HTTP Responses transport works with the same account, authentication, model, machine, and installation.

A robust fix would ideally prevent the WebSocket path from aborting the entire process and either:

  • return a diagnostic error, or
  • automatically fall back to the non-WebSocket HTTP transport.

I can provide a sanitized full debug log or coredump metadata if maintainers need it.