Repository navigation
[Windows Desktop] 2h34 turn with reconnects, no useful progress, then completed without confirmed recovery #52694
Description
Summary
On October 9, 2026, a long-running local software-development conversation in Codex Desktop for Windows had a turn lasting 2 h 34 min 20 s. During the turn, the UI showed reconnection attempts and the monitored turn state remained active / inProgress, with error: null and no fresh useful public result. The assistant subsequently acknowledged it had made no progress on the six requested local support functions.
The turn ultimately ended with status: completed and error: null. The assistant said it had recovered a saved checkpoint and would continue, but no subsequent active turn or completed deliverable was observed at the final check. This is a reliability/progress/recovery visibility report, not a claim about the root cause or quota accounting.
Environment
- Product: Codex Desktop; local Windows execution using PowerShell
- Task: implement and test six local support functions around an existing controller (checks, evidence, receipts, manifest, parent package, reports)
- Conversation: long-lived, with prior turns and saved checkpoints
- Exact Codex Desktop version / bundled runtime version: not captured
- Model and reasoning effort for the affected turn: not verified
- No controlled reproduction was performed
Timeline (October 9, 2026; UTC)
| Time | Evidence / observation |
|---|---|
| 17:42:43 | Official affected turn start |
| ~17:43 | Assistant publicly announced preparation and testing of six supporting functions |
| 18:49:12 | Last write time of a locally inspected RESULT.json checkpoint, which still recorded zero implemented support callbacks and no native launches or submissions. Its metadata referred to an earlier turn, so this file is not treated as authoritative proof of the affected turn's terminal state |
| Time not embedded in screenshot | Desktop showed "Running for 2h 15m 21s", "Reconnecting 1/5", then "Reconnecting 2/5" and "Thinking"; a RESULT.json creation was also displayed (+26 / -0). None of this proves useful task completion |
| 20:12 | Assistant publicly acknowledged a malfunction, stating (translated from French): "I got stuck in a reasoning loop, without advancing the six support functions. No native launch or native effect was executed." This is the assistant's characterization, not proof of an internal reasoning-loop mechanism |
| 20:17:03 | Official turn end: completed, error: null. Total elapsed 9,260,379 ms (2h 34m 20.379s), including subsequent status checking and checkpoint inspection |
During the incident, compact official observations repeatedly showed active / inProgress with error: null. Technical markers changed, but no corresponding fresh useful public output was observed. The monitor did not re-submit an already accepted continuation.
After the final response, the conversation was observed as idle. An idle conversation after a final answer is not itself erroneous; it only means that the claimed continuation/recovery was not confirmed by observed follow-on work.
Expected vs actual
Expected: An accepted turn should either perform observable useful work, report a genuine blocker, or enter a clear bounded failure/retry state. After interruptions/reconnections, the system should distinguish transport retries, model activity, actual tool/task progress, and successful recovery. Checkpoints and previously accepted effects must be preserved without replaying already consumed native actions.
Observed: The turn remained active for more than two and a half hours; the assistant acknowledged no progress on the requested implementation; and the turn ended successfully according to lifecycle status, despite no verified deliverable or follow-on work at the final check.
Impact
- Material user delay and loss of confidence in whether the long-running task is progressing
- Six requested functions not shown delivered or qualified by the collected evidence
- Inadequate user-visible distinction among ongoing activity, reconnecting, substantive progress, and recovery
- Saved checkpoint remained recoverable; no destructive recovery action was attempted by the monitoring agent
Evidence limits / non-claims
- No root cause established: client, server, transport, local network, model, context length, permissions, or other factors remain possibilities
- No confirmed regional service outage, token/quota loss, or billable-usage attribution
- No proof that reasoning streamed continuously for the entire 2h34, nor that the agent's "reasoning loop" description is technically accurate
- Turn duration is not an exact measurement of time stalled
- An earlier
stream disconnected before completion: Transport error: network error: error decoding response bodyhappened in a separate invocation on the same day. It is not assigned as this turn's error or presumed causal - No deterministic reproducer; exact affected app/model versions not recovered
- This public report intentionally excludes raw logs, transcript, private project context, paths, account/session/turn UUIDs, and other correlation identifiers
Requested investigation
- Correlate reconnection attempts, lifecycle
active / inProgressand finalcompleted / error: null, and the absence of verified substantive task progress. - Explain which signals the Desktop/app-server can expose to distinguish genuine generation, transport retry, stalled execution, and successful continuation.
- Check whether prolonged turns can complete without making task progress after reconnect/retry episodes, and whether an explicit recoverable state or watchdog is warranted.
- Provide a safe private route for targeted server-side correlation identifiers or redacted diagnostics, if needed.
- Ensure recovery preserves the established checkpoint and does not re-execute effects already applied.
Potentially related, not asserted as the same cause:
- Windows Desktop 26.803: active turns show no progress for 3–4 hours while the app remains interactive #37775 — multi-hour active Windows turns without useful progress
- Windows desktop: repeated WebSocket idle timeouts, ~46-minute activity gap, and misleading post-recovery assistant response #50086 — Windows WebSocket reconnects and misleading post-recovery response
- [Windows Codex Desktop 26.1002.7124.0] /goal runs stream reasoning for ~50 min with no tools or answer; repeats after pause/resume #52529 — Windows long-lived turns streaming reasoning without tool/task progress
Reported at the affected account holder's request. No raw session or private project material is being shared in this issue.
Activity
github-actions commentedon Oct 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Hannark commentedon Oct 10, 2026
Follow-up — second distinct incident on October 10, 2026 (Windows Desktop)
I am reporting a second, separately documented occurrence affecting a long-running local software-development conversation. This is not evidence that the October 9 incident and this incident share a root cause. It adds a different and operationally important symptom: a user-requested pause at the next safe boundary was delivered to the target through the official thread-messaging tool, but no public acknowledgment or confirmed safe pause was observed.
This update is based on a contemporaneous, privacy-redacted evidence collection as of 2026-10-10 16:25:41 UTC. It does not claim the turn remains active beyond that observation.
Environment and limits
gpt-6.1-solwithxhigheffort; no claim that these settings caused the incident.Timeline (October 10, 2026; UTC)
send_message_to_threadtool. Tool feedback confirmed the destination, but did not include a receipt proving that the active turn had consumed/applied the instruction. The monitoring agent did not resend it.active / inProgress,error: null, on the same turn, without a new public message or terminal result found.The 2h15 duration is elapsed turn time, not a measured continuous stall. A recorded helper failure does not imply that every later process was idle. The absence of a pause acknowledgment also does not prove that the pause message was dropped or ignored: it may have remained queued, or been processed without an observable public receipt.
Difference from #52694's original October 9 incident
Reconnecting 1/5and2/5retries; turn eventually completed after 2h34 witherror: null; assistant acknowledged no progress on the intended implementation.The shared, narrower concern is unreliable observability and safe recovery of prolonged turns, rather than any proved internal loop, service outage, regression, or particular model defect.
User impact and requested investigation
The user could not establish a verified safe stopping boundary for an overnight shutdown. Previous partial work and one-shot native effects must be preserved, not blindly replayed. The monitor stopped its own automated relays rather than forcibly terminating the affected turn.
Please investigate:
active / inProgresswithout a public assessment or final result.send_message_to_threadsubmission to an already active target is queued, delivered into the active turn, consumed, persisted, and/or acknowledged — and what telemetry distinguishes these states.Possibly related by symptom, not asserted to have the same underlying defect: #46479 (unresponsive Windows task/control requests) and #45967 (accepted steer persistence semantics).
No token/credit-loss claim, regional outage claim, model-internal reasoning-loop diagnosis, or post-update regression claim is made. This comment is posted at the affected account holder's request; no full session or private identifiers are shared.
Hannark commentedon Oct 10, 2026
Terminal update / correction — October 10 second incident
This update supersedes the provisional “still active / inProgress” status in my preceding comment (#issuecomment-6099759589). The monitoring agent later obtained two concordant official readings of the same turn's terminal state.
Confirmed terminal outcome
failed(the conversation was returned assystemError), notcompletedor stillactive.invalid_request_error,param: input,code: context_length_exceeded, HTTP 400,sequence_number: 2.Your input exceeds the context window of this model. Please adjust your input and try again.Interpretation and limits
This establishes the reason for the final rejected model request: input exceeded the model context window. It does not establish why the input grew, whether/when context compaction was attempted or failed, why the turn produced no useful public conclusion for so long, or whether the pending pause instruction was consumed by the active turn. The successful destination-level submission of
send_message_to_threadmust not be represented as confirmed delivery/application by the model. In particular, do not conclude the agent deliberately ignored the pause.The earlier 15-minute native helper
exitCode 1/ deadline was a separate local tool outcome, not the terminalcontext_length_exceededresponse. There is no evidence that the October 9 incident (#52694 original report) failed with the same context error.State of work and support request
The collected final state retained locally saved preparation, test and partial-result artifacts (as well as a private upload file). Their presence is not proof of full qualification or a safe overnight checkpoint. No replay, recovery experiment, or destructive cleanup was performed. The separate monitoring Watchdog remains PAUSED; a verified safe-stop boundary for the broader workflow was not established by the failed inference turn alone.
Please additionally investigate:
context_length_exceededafter more than two hours, including input construction, context-window safeguards and compaction/retry behavior.The exact app build remains unverified. This is a redacted public correction; no account, project, session, turn UUID, complete logs or private payloads are disclosed.
This is a terminal-status correction to the October 10 follow-up, not a third incident and not a claim of a shared root cause with October 9.
Hannark commentedon Oct 11, 2026
Follow-up — October 11, 2026: short retry fails in original conversation; compact handoff works in a new conversation
User-reported follow-up to the confirmed October 10 terminal failure described above. This is a continuation/recovery observation, not a new diagnosis or an independently verified runtime trace.
invalid_request_error/context_length_exceeded. The request for a safe pause had received no public acknowledgment.context_length_exceedederror, this time after 4.385 seconds (reported duration; exact timestamps and request correlation IDs not supplied).Investigative value and remaining uncertainty
The contrasting outcomes — rapid rejection in the existing conversation versus successful initialization in a new conversation with compact handoff — suggest the maintainers should compare the two requests' effective context/input construction, conversation-history inclusion, available context budget, and compaction/continuation behavior.
No exact defect has been established. These observations do not prove that retained history alone caused the failures, that compaction malfunctioned, that a particular model/update was at fault, or why the October 10 turn took so long. There is also no new evidence that the prior pause message was consumed by the affected turn.
Please retain this as an additional reproducibility/recovery clue under #52694, without merging the distinct October 9 and October 10 incidents into a single assumed root cause.
No private conversation identifiers, project details, raw logs, or payloads included.
aldi949 commentedon Oct 11, 2026
@Hannark the interesting part here is that the turn completed, but the actual work still wasn't proven done.
I've been testing a small completion verifier that checks the required result instead of trusting the agent's final message.
It's limited to Windows, Python and Codex CLI right now, so I wouldn't claim it can reproduce your Desktop issue directly.
Any chance you have a smaller Python task where Codex stopped before producing the required result? I'd like to test it against the current version and see what happens.