App-server crashes on any tool call ("thread_tools" unknown feature key) — sudden onset, no local trigger

Open 💬 10 comments Opened Jun 19, 2026 by RomaricSmiley
💡 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.616.32156

What subscription do you have?

I have ChatGPT Plus subscription

Which IDE are you using?

VS Code

What platform is your computer?

macOS (Intel, x86_64) — Intel Core i5-8279U

What issue are you seeing?

Summary
The Codex extension (openai.chatgpt) for VS Code crashes the app-server whenever a tool call is required (project analysis, file reading, etc.), while plain conversational prompts work fine. The bug appeared suddenly mid-session — everything was working normally, then a single prompt triggered the first crash with no local change on my end. The issue is fully reproducible and has persisted through a complete clean reinstall.

Environment

  • macOS, Intel (x86_64), CPU: Intel Core i5-8279U
  • IDE: VS Code
  • Extension: openai.chatgpt (reproduced across multiple extension versions, including a fresh install of the latest version)

Important timeline detail
The first crash was not triggered by any local change, update, or configuration edit on my side — Codex was working normally, and then abruptly started crashing on a prompt mid-session. This strongly suggests a server-side/cloud-pushed change (e.g. a feature flag rollout) rather than anything client-side, since nothing in my environment changed between the last working prompt and the first crash.

Clear reproduction steps

  1. Open Codex in VS Code with a project folder open
  2. Send a plain conversational prompt, e.g. "Tell me a story" → works perfectly, no crash
  3. Send any prompt that requires tool use, e.g. "Analyze my project" or "Analyze this project and its recent changes" → app-server crashes immediately

This confirms the crash is specific to the tool-calling pathway, not the model/chat pathway itself.

Troubleshooting already performed (ruled out as causes)

  • Fixed a local SSL_CERT_FILE environment variable pointing to an invalid/oversized custom certificate bundle
  • Fixed a local SSL_CERT_FILE pointing to a nonexistent Homebrew path
  • Removed an unrelated stray certificate from the macOS login keychain
  • Fully uninstalled the extension, renamed/cleared ~/.codex entirely, reinstalled the extension from scratch, re-authenticated
  • Tested on both a downgraded and the latest extension version
  • None of the above resolved the crash

Issue 1 — Crash on any tool call: "unknown feature key in config: thread_tools"
config.toml contains only model, model_reasoning_effort, and a [projects."..."] trust_level block — no reference to thread_tools anywhere on disk (confirmed via recursive grep across ~/.codex/ and VS Code's settings.json). Despite this, any tool-requiring prompt crashes the app-server. I've seen this surface in two slightly different forms:

Form A (with explicit signal):

Codex process errored: Codex app-server process exited unexpectedly (code=unknown, signal=SIGTRAP). Last CLI error: codex_features: unknown feature key in config: thread_tools
codex_features: unknown feature key in config: thread_tools

Form B (process unavailable, no signal shown), triggered by the prompt "Analyse ce projet et ces récentes modifications" ("Analyze this project and its recent changes"):

Codex process errored: Codex process is not available
codex_features: unknown feature key in config: thread_tools

I suspect thread_tools is a server-side/cloud-managed feature flag tied to enabling tool calls within a thread, which the currently shipped app-server build does not recognize, causing a crash instead of graceful degradation. The sudden, config-less onset strongly points to a rollout that started pushing this flag to my account/client.

Issue 2 — Related crash on tool use: rollout state db discrepancy
On a separate tool-requiring prompt, the same crash occurred with a different last log line:

Codex process errored: Codex app-server process exited unexpectedly (code=unknown, signal=SIGTRAP). Last CLI error: codex_rollout::list: state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back
codex_rollout::list: state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back

This looks like a logged fallback/recovery path that may precede the actual thread_tools crash when tool invocation kicks in — possibly the same underlying bug surfacing via different log lines depending on timing.

Issue 3 — Bundled plugin manifest violates your own validation rule (separate bug, found during troubleshooting)

Codex process errored: Codex process is not available
codex_core_plugins::manifest: ignoring interface.defaultPrompt[0]: prompt must be at most 128 characters path=/Users/[user]/.codex/.tmp/plugins/plugins/ngs-analysis/.codex-plugin/plugin.json

The bundled ngs-analysis plugin (author: OpenAI) ships with a defaultPrompt[0] string well over your documented 128-character limit. The log says it's being "ignored" but the process becomes unavailable instead of gracefully skipping the invalid field.

Request
Given the clean reproduction (any tool call crashes the app-server via thread_tools, appearing suddenly with no local trigger) could you confirm whether this is a feature flag rollout issue affecting tool-calling, and provide a fix or rollback? This currently makes the extension unusable for any real coding task, since project analysis, file edits, and command execution all require tool calls. Also please fix the ngs-analysis bundled plugin manifest so it complies with your own 128-character limit.

Happy to provide full logs (~/.codex/logs_2.sqlite) or a Feedback ID if needed.

What steps can reproduce the bug?

  1. Open VS Code with a project folder loaded
  2. Open the Codex panel (openai.chatgpt extension)
  3. Send a plain conversational prompt, e.g.:

"Tell me a story"
→ Works correctly, no crash

  1. In the same or a new session, send a prompt that requires tool use, e.g.:

"Analyze my project"
or
"Analyse ce projet et ces récentes modifications"
→ The app-server crashes immediately with:

Codex process errored: Codex app-server process exited unexpectedly (code=unknown, signal=SIGTRAP).
Last CLI error: codex_features: unknown feature key in config: thread_tools
codex_features: unknown feature key in config: thread_tools

(Sometimes surfaces instead as:
Codex process errored: Codex process is not available
codex_features: unknown feature key in config: thread_tools)

Note: config.toml contains no reference to "thread_tools" (verified via recursive
grep across ~/.codex/ and VS Code settings.json — only present in the internal
log database). The crash also persists after a full clean reinstall (uninstalled
extension, wiped ~/.codex, reinstalled, re-authenticated), and first appeared
suddenly mid-session with no local config change beforehand.

What is the expected behavior?

Codex should successfully process tool-requiring prompts (e.g. project analysis,
file reading/editing) the same way it handles plain conversational prompts.

If "thread_tools" is an unrecognized or unsupported feature key (e.g. pushed via
a server-side feature flag rollout), the app-server should log a warning and
gracefully ignore/skip it rather than crashing the entire process with SIGTRAP.
A single unknown config/feature key should never take down the whole session.

Additional information

_No response_

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #29118
  • #28427

Powered by Codex Action

SajjadAlimohammadi · 1 month ago

@RomaricSmiley Downgrading should fix it. It worked for me.

pengfeng · 1 month ago

Got the same problem. Downgrading to version 26.5609.30741 fixed it.

awain7 · 29 days ago

Reproduced this with a completely fresh ~/.codex (renamed away the entire directory so config.toml, session DB, and all local state were brand new — no prior sessions, no custom config beyond the auto-generated project trust entry).

After re-login, opening the classroom-task-manager project and triggering a tool call still crashed the app-server with:

codex_features: unknown feature key in config: thread_tools

The regenerated config.toml on disk had no thread_tools key at all — just the default project trust_level entry. So the extension itself is injecting a thread_tools feature flag at runtime that the bundled/global CLI doesn't recognize, independent of any local config or session state.

Environment:

  • Extension: openai.chatgpt 26.616.41845 (VS Code, macOS)
  • CLI: codex-cli 0.141.0 (npm @openai/codex, global install)

This rules out local data corruption as the cause — looks like a version skew between the extension's expected feature set and the CLI/app-server it's pairing with.

Nguyenhieploi · 29 days ago

I was able to fix this issue by downgrading the Codex VS Code extension to version 26.609.30741.

After installing that version and restarting VS Code, Codex worked again without the Codex process is not available / state db discrepancy error.

awain7 · 29 days ago

Confirmed: downgrading the extension to 26.609.30741 (as others reported above) fixed it for me too. Tested by opening a project and triggering several tool calls — no more crashes. Disabled auto-update on the extension to keep it pinned until a fix ships in a newer version.

RomaricSmiley · 28 days ago

Confirmed: downgrading to version 26.609.30741 fixed the issue on my end as well. Tool calls are working again without any crashes. I've disabled auto-update on the extension to stay pinned on this version until a proper fix ships.

Thanks everyone for the quick feedback and to the team for the labels — really appreciated!

awain7 · 23 days ago

Update: tried upgrading from the pinned 26.609.30741 to the latest stable 26.623.42026 (released 2026-06-27) to see if this was fixed. Still crashes the same way. Reverted back to 26.609.30741, which remains the only working version I've found.

seedalri · 20 days ago

Downgrading to version 26.609.30741 fixed it for me too. Current version (v26.623.70822) still has the issue.

awain7 · 7 days ago

Update: this appears to be fixed in extension version 26.707.41301. Tested today: opened both a fresh workspace and my original project folder with existing thread history, resumed a long-running thread (~8000 lines), and ran multiple tool calls (file reads, git commands, file write/delete) — no more SIGTRAP / state db discrepancy / thread_tools errors. I've re-enabled auto-update. Others pinned to 26.609.30741 may want to try updating.