Post-compaction turn silently loses tool_search, app connectors, and configured MCP tools
What issue are you seeing?
Codex Desktop successfully completes a manual context compaction, but the first model turn after compaction is silently provisioned without tool_search, deferred app tools, or configured MCP tools that were callable immediately before compaction.
The app/connector cache remains healthy and populated. There is no connector-specific error: the tools simply disappear from the model's available tool manifest. Shell and core tools remain available.
This looks like a post-compaction tool-manifest hydration regression related to #19486 / #19771, but with a different visible outcome: compaction succeeds instead of returning a validation error, then the resumed turn lacks the discovery/tool entries.
Environment
- Codex Desktop on Windows with
runCodexInWindowsSubsystemForLinux = true - Codex CLI/runtime:
0.145.0-alpha.30 - Model:
gpt-5.6-sol - Reasoning effort before compaction varied; first affected turns were
low - Connected tools included Codex Apps (Notion and other connectors) plus local MCP servers
Local timeline (UTC)
09:30:35— last successful configured MCP call09:32:17—compactedrecord09:32:18—context_compactedevent09:34:33— first post-compactionturn_context; configured MCP/app tools no longer available to the model- subsequent turns remained affected
At diagnosis time, the local Codex Apps cache had been refreshed and contained 534 tool descriptors, including Notion and ButlerBrain. Direct local smoke tests also confirmed that the configured memory MCP bridge and its backend were healthy. This rules out connector downtime and an empty/stale app catalog.
Reproduction
- Open a long Codex Desktop task with enough connected apps/MCP tools for deferred tool discovery.
- Successfully call one or more app and MCP tools.
- Manually compact the task.
- Continue in the same task.
- Observe that the next model turn has core tools but no
tool_search, app tools, or configured MCP tools.
Expected behavior
After compaction, the resumed turn should receive the same effective connector/MCP inventory and tool discovery capability as the pre-compaction turn. Compaction should preserve tool provisioning independently from the summarized conversation history.
Actual behavior
Compaction reports success, but tool provisioning is silently reduced. Restarting Codex or creating another task may rehydrate tools, but that is disruptive and loses continuity. Clearing the tool cache is not relevant because the cache is current and populated.
Suggested diagnostics / fix
- Assert after compact-history reconstruction that every deferred tool set has a corresponding
tool_searchentry. - Preserve or rebuild the effective MCP/app inventory from runtime configuration, not compacted conversation items.
- Emit a visible warning when post-compaction tool inventory differs from the preceding turn.
- Add a regression test for successful compaction followed by a turn with the same configured/deferred tool inventory.
I can provide a sanitized event-shape trace if maintainers need it; raw transcripts are private and are not required to reproduce the manifest transition.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional Windows reproduction:
26.721.4979.0,gpt-5.6-sol, GitHub plugingithub@0.1.8-2841cf9749ae.tool_search, but exact and broad searches returned zero GitHub tools; root tool manifest also exposed zero GitHub tools.github_fetch_pr.This isolates failure to per-task post-compaction tool-manifest hydration, not connector/cache health. Related symptom: #33601.