codex - 💡(How to fix) Fix Codex Desktop 26.519 / CLI 0.133.0: long post-tool thinking gaps and excessive context growth even with memories disabled

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop: 26.519.5221.0

What subscription do you have?

chatgpt

What platform is your computer?

OS: Windows 10 Enterprise LTSC 2021

What issue are you seeing?

After updating to Codex Desktop 26.519 / CLI 0.133.0, I am seeing severe agent slowdowns and long “thinking” gaps after tool outputs have already returned.

The issue is not limited to old long-running sessions and is not explained by memories alone. A new session started after disabling memories still grew to very large per-turn input token counts and stalled after tool output completion.

What steps can reproduce the bug?

After tool calls complete, Codex should either:

• continue the assistant turn promptly,
• surface a clear error/timeout/cancellation,
• or explain that it is waiting on a specific still-running tool.

It should not remain in a long silent thinking state after all visible tools have completed

What is the expected behavior?

In one new session, the user asked for a document rewrite. Codex:

1. read the file,
2. rewrote it,
3. ran multiple extra checks,
4. all tool outputs returned,
5. then no useful assistant output appeared for about 15 minutes,
6. the user manually interrupted the turn.

The previous turn was not blocked by a shell process at that point; visible tool outputs had already completed.

Key local evidence

Affected thread:

• Thread id: 019e59af-4aa2-7b23-8669-35ab3c193ed8
• memory_mode = disabled
• CLI: 0.133.0-alpha.1
• Model: gpt-5.5
• Reasoning effort: medium
• Total tokens recorded: 8,204,143
• Rollout JSONL size: 1,641,584 bytes

Relevant event timeline:

• 2026-05-24T12:13:20Z user asks to rewrite a document in clearer
• 2026-05-24T12:13:29Z file read starts.
• 2026-05-24T12:14:56Z full-file patch completes.
• 2026-05-24T12:15:12Z Codex starts extra checks: file snippet, rg, git diff --check.
• 2026-05-24T12:15:48Z last visible tool output completes.
• 2026-05-24T12:31:01Z user interrupts the turn.
• Gap after completed tool output: about 15 minutes.

Token telemetry around the problematic section:

• 2026-05-24T12:14:57Z: last input tokens 158,183, total cumulative 7,543,311
• 2026-05-24T12:15:17Z: last input tokens 162,616, total cumulative 7,706,325
• 2026-05-24T12:15:30Z: last input tokens 164,703, total cumulative 7,871,455
• 2026-05-24T12:15:48Z: last input tokens 165,187, total cumulative 8,036,995
• after interrupt response: last input tokens 166,909, total cumulative 8,204,143

Core log after the interrupt response included:

• total_usage_tokens=176102
• estimated_token_count=Some(210451)
• auto_compact_scope_limit=244800
• full_context_window_limit_reached=false
• token_limit_reached=false
• needs_follow_up=false
• skipping active goal continuation because no goal

This suggests the stall happened before a normal completion/error surface, not because the context window was formally exceeded.

Why this does not look memory-only

The main affected thread had memory_mode = disabled, and the current config had memories disabled. Older sessions with memories enabled did show memory-related overhead, but the regression reproduced after disabling memories and starting a new session.

Related observations

Other affected sessions after the same update showed excessive context/tool discovery behavior:

• unnecessary loading of extra skills/playbooks,
• extra URL and documentation checks after the task already had enough information,
• repeated full-context turn growth,
• long delays until user interrupt.

Possible affected area

This may be related to one or more of:

• post-tool assistant continuation / turn lifecycle,
• context assembly and repeated injected session/tool/skill context,
• plugin/skill discovery metadata after 26.519 / CLI 0.133.0,
• request compression / auto-compaction boundary behavior,
• Desktop app handling of large per-turn prompt state.

I am not claiming the exact root cause. The strongest verified signal is: tool outputs completed, the turn stayed silent for a long time, and this reproduced in a new memories-disabled session with very large per-turn input token counts.

I can provide sanitized snippets from:

• state_5.sqlite thread metadata,
• affected rollout JSONL around the event lines,
• logs_2.sqlite telemetry around the affected turn,
• codex features list.

I cannot paste raw full rollout/log files publicly because they contain local paths and private working content.

Additional information

No response