Post-compaction turn silently loses tool_search, app connectors, and configured MCP tools

Open 💬 2 comments Opened Jul 22, 2026 by TeaShaman-cyber
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 call
  • 09:32:17compacted record
  • 09:32:18context_compacted event
  • 09:34:33 — first post-compaction turn_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

  1. Open a long Codex Desktop task with enough connected apps/MCP tools for deferred tool discovery.
  2. Successfully call one or more app and MCP tools.
  3. Manually compact the task.
  4. Continue in the same task.
  5. 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_search entry.
  • 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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33608
  • #33609

Powered by Codex Action

Deanifish · 1 month ago

Additional Windows reproduction:

  • Codex Desktop package 26.721.4979.0, gpt-5.6-sol, GitHub plugin github@0.1.8-2841cf9749ae.
  • After compaction, root task still exposed tool_search, but exact and broad searches returned zero GitHub tools; root tool manifest also exposed zero GitHub tools.
  • Local Codex Apps cache contained 225 tools, including 89 GitHub tools.
  • Fresh child task in same process exposed all 89 GitHub tools and successfully called github_fetch_pr.

This isolates failure to per-task post-compaction tool-manifest hydration, not connector/cache health. Related symptom: #33601.