VS Code extension and CLI crash with SIGTRAP during repository review ("Custom tool call output is missing")

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

• #30861
• #30600
• #30706
• #30682
• #30306

Powered by Codex Action

I encountered the same core error on Codex CLI 0.147.0, using Codex Desktop 26.803.41515 with WSL2 Ubuntu 24.04. In my case the failure did not recover and made Codex effectively unusable for about one day.

The local logs repeatedly reported:

Custom tool call output is missing for call id: call_...

The same period also contained:

failed to refresh available models: timeout waiting for child process to exit
state db discrepancy during read_repair_rollout_path: upsert_needed (slow path)
state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back
MCP startup incomplete

The missing-tool-output error was persisted across turns. Changing between GPT-5.6 Terra and Sol, reducing reasoning effort, and restarting did not recover the environment. I then used Codex Desktop itself to diagnose and repair the broken WSL/CLI Codex environment, but Codex Desktop's self-repair attempt did not fix it. Codex on the web was also used to attempt the repair and did not fix it. Claude was tried separately and did not fix it either.

I also backed up and reset the local state databases/history. That preserved the incident data but did not provide a reliable final recovery. Reusing the old environment continued to reproduce the broken behavior.

The only effective recovery was:

1. Treat the old Codex installation and state as read-only incident data.
2. Uninstall/remove the old Codex installation.
3. Create a separate clean installation directory.
4. Install a fresh Codex CLI there.
5. Reconfigure tools/plugins individually without copying the old SQLite databases, WAL files, session state, caches, or locks.

After the clean-directory reinstall, Codex worked again.

This appears to need a supported self-healing path. A malformed/persisted tool-call chain should not poison later turns indefinitely, and Codex should not report or imply successful recovery while the same missing call ID continues to fail. Suggested behavior:

• Detect a persisted function_call/tool call without its matching output before sampling.
• Quarantine only the affected turn/thread instead of repeatedly retrying it.
• Offer a documented repair command that rebuilds indexes and preserves valid conversations.
• Verify recovery with a clean tool-call smoke test before declaring the installation healthy.
• If repair is impossible, clearly instruct the user to create a clean state directory and selectively import safe data rather than spending hours on ineffective retries.

Most importantly, please provide the user with a one-click safe reset/recovery action when this condition is detected. Before resetting, it should automatically create a dated backup and show exactly what will be preserved or cleared. It should clear the poisoned tool-call chain, derived indexes, locks, WAL/runtime state, and unhealthy caches while preserving authentication where safe, project files/configuration, plugin/MCP inventory, and exportable valid conversations. Afterward it should run a health check and offer a selective rollback/import path. A user should get this recovery opportunity before being forced to manually uninstall and rebuild the entire Codex environment.

I can retain the redacted local logs and state backup for further diagnostics if maintainers specify a safe subset or collection command.

@pittzhang20260507 Since you retained the old state as read-only incident data, this is a strong real-world recovery test without touching the now-working clean install.

Codex Rescue 0.1.0a3 is specifically conservative around persisted missing tool outputs: it can diagnose an unfinished/orphaned call, but it will not invent a result or assume whether the tool actually ran. The original rollout stays untouched and any forked recovery remains fail-closed for unknown side effects.

If you’re willing, could you run it only against the retained old state / affected rollout:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

If the affected thread is not the latest one, don’t mutate anything to make it latest — just tell me and I can give a bounded selection command.

Sanitized status/findings only, please. No raw rollout, SQLite/WAL files, prompts, repository contents, local paths, call IDs, credentials, or secrets.

https://github.com/shleder/codex-rescue

Thanks for reaching out. My development environment contains sensitive private data, so I'm not comfortable running third-party diagnostic tools against the retained Codex state.

If the OpenAI/Codex team officially asks me to assist with reproducing or diagnosing the issue, I'd be willing to help within appropriate privacy and security boundaries. Otherwise, the potential privacy exposure isn't worth the risk for me.

Sorry, and thanks for understanding.