Repository navigation
Codex Desktop 26.519 / CLI 0.133.0: long post-tool thinking gaps and excessive context growth even with memories disabled #24336
Description
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:
- read the file,
- rewrote it,
- ran multiple extra checks,
- all tool outputs returned,
- then no useful assistant output appeared for about 15 minutes,
- 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:20Zuser asks to rewrite a document in clearer2026-05-24T12:13:29Zfile read starts.2026-05-24T12:14:56Zfull-file patch completes.2026-05-24T12:15:12ZCodex starts extra checks: file snippet,rg,git diff --check.2026-05-24T12:15:48Zlast visible tool output completes.2026-05-24T12:31:01Zuser interrupts the turn.- Gap after completed tool output: about 15 minutes.
Token telemetry around the problematic section:
2026-05-24T12:14:57Z: last input tokens158,183, total cumulative7,543,3112026-05-24T12:15:17Z: last input tokens162,616, total cumulative7,706,3252026-05-24T12:15:30Z: last input tokens164,703, total cumulative7,871,4552026-05-24T12:15:48Z: last input tokens165,187, total cumulative8,036,995- after interrupt response: last input tokens
166,909, total cumulative8,204,143
Core log after the interrupt response included:
total_usage_tokens=176102estimated_token_count=Some(210451)auto_compact_scope_limit=244800full_context_window_limit_reached=falsetoken_limit_reached=falseneeds_follow_up=falseskipping 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.sqlitethread metadata,- affected rollout JSONL around the event lines,
logs_2.sqlitetelemetry 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
Activity
github-actions commentedon May 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
sunshaoxuan commentedon Jul 17, 2026
I can reproduce and quantify the same failure mode on Windows with Codex Desktop / app-server 0.144.5.
Observed impact
During one long engineering task, the root session recorded:
The 3h44m silent interval itself accounted for only 199,388 tokens, about 0.135% of the task increase. The large quota impact came from many high-context model turns, not from that single wait.
Context-growth reconstruction
The task compacted six times. Each window restarted around 29K to 30K input and later reached roughly 218K to 230K before the next compaction.
One representative window:
That last transition suggests the long delay also caused a large prompt-cache miss.
Between the compaction and the 199K request, the model-visible history contained 460 serialized response items, about 1.11M characters. Custom/function tool calls, tool outputs, and reasoning represented about 88.3% of that serialized volume. The fixed project-side AGENTS/environment message was only 4,828 characters, with AGENTS.md itself about 2,599 characters.
The same window contained 132 tool-call/output cycles. Tool outputs were dominated by source/diff inspection and test logs. Patch/edit tool calls also embedded large code bodies, which then remained in logical history until compaction.
Relevant 0.144.5 implementation
Each sampling loop rebuilds the prompt from the logical history:
https://github.com/openai/codex/blob/rust-v0.144.5/codex-rs/core/src/session/turn.rs#L270-L277
The Responses request includes the history, base instructions, and tool definitions:
https://github.com/openai/codex/blob/rust-v0.144.5/codex-rs/core/src/client.rs#L829-L913
previous_response_id reduces transport when the prefix matches, but the effective model context and usage still include the full logical prefix:
https://github.com/openai/codex/blob/rust-v0.144.5/codex-rs/core/src/client.rs#L1165-L1254
Tool outputs are individually truncated/normalized but remain in cumulative history until compaction:
https://github.com/openai/codex/blob/rust-v0.144.5/codex-rs/core/src/context_manager/history.rs#L355-L412
This appears closely related to #13733, extended here to Desktop, shell output, patch payloads, wait/poll operations, and subagent coordination.
Requested product changes
Could Codex provide or consider:
I can provide sanitized event ranges and an in-app Feedback ID privately. I cannot publish the raw rollout because it contains local paths and private source content.
Internal feedback
In-app feedback was submitted with the affected session attached.
Feedback ID:
019f6b4c-597b-78f0-ae1a-6eb8ef69053fMavumavu commentedon Jul 22, 2026
I can reproduce this same user-visible failure mode on a current Windows Codex Desktop build, and it is recurrent rather than a one-off stall.
Environment
OpenAI.Codex_26.715.10079.0_x64gpt-5.6-sol, Ultra reasoningRepeated behavior
The pattern has occurred many times within the same continuing Goal, including across Desktop restarts/updates:
This means the user must continuously supervise the Goal and repeatedly intervene from their side. That should not be necessary for an active long-running Goal whose remaining work and permissions are already known. The issue has interrupted this workflow often enough that unattended execution is not dependable.
In some occurrences, background/subagent completion may be involved, which overlaps with #15723. Other occurrences look like the post-tool silent gap described in this issue: all visible tools have returned, yet there is no next assistant action. I did not observe evidence that every occurrence was caused by a network disconnect, so #28227 is related but narrower.
Expected behavior
After visible tools complete, Codex should do one of the following without requiring a user “poke”:
It should not remain silently stranded while still appearing to own an unfinished active Goal.
UX/diagnostic request
Please expose enough durable state to distinguish:
A watchdog that notices “all visible work is terminal, Goal remains active, but no continuation was scheduled” and either retries once or surfaces a clear recoverable error would prevent the repeated manual intervention.
This comment intentionally omits project names, private paths, prompts, and source contents.
sunshaoxuan commentedon Jul 23, 2026
Thanks, this is useful corroboration of the continuation failure. I want to clarify the priority of my report because a watchdog that blindly resumes execution could amplify the measured token impact.
The dominant token growth in my case did not occur during the 3h44m silent interval. That interval accounted for 199,388 tokens, only 0.135% of the 147,549,184 gross-token increase. The task recorded 1,078 usage increments with a median of 138,565 input tokens, and 239 increments exceeded 190,000 input tokens. Cached input represented 97.36% of the added input, while ChatGPT Pro weekly usage moved from 22% used to 66% used during the task.
Automatic continuation by itself therefore does not address the main measured impact. If recovery issues another full-context model request, unattended retries may repeatedly consume very large inputs while the user is away.
Any watchdog or continuation recovery should be cost-aware and bounded. Before retrying, it should:
The desired outcome is reliable continuation together with protection from invisible quota amplification. Telemetry such as
input_tokens_by_source, per-turn input size, compaction events, and cumulative usage is necessary to verify that a lifecycle fix does not make the token-consumption failure worse.