[Windows app] Finished historical Work activity keeps timing and suppresses the next waiting indicator

App version, subscription, and platform

Microsoft Store package OpenAI.Codex 26.901.6511.0, application 26.901.51231; Pro 20×; Windows 11 x64.

Issue and reproduction

An earlier Work turn can keep accumulating elapsed time for hours after work has stopped and later turns have completed. A subsequent turn may initially show only its user message, without the normal waiting indicator, while progress is visible on the web.

The historical timer can be reproduced without a new model call: render an earlier reasoning group with a pending TODO or a tool record missing its individual completion marker, then a later, different turn. In the original converter, the earlier group remains in progress despite completed source messages. The waiting predicate also scans every historical turn, so that stale group suppresses the latest turn's loading indicator.

Findings and repair boundary

The distributed aWr / lWr history path conflates unfinished retained activity records with current turn liveness. Zm uses the live clock when the resulting group lacks a completion time. A fresh execution of the original converter reproduced the state, so this is not established merely from a stale render cache.

The repair closes only historical Work activity followed by a different turn, leaving the latest turn and same-turn steering alone. Plans and tool records are preserved rather than marked successful. Existing end timestamps are retained; missing ones use the last recorded completed activity before the next prompt as a bounded fallback, not an asserted exact server stop time. The waiting predicate now checks only the latest turn.

For a visible active Work conversation with no recent updates, a guarded read-only snapshot recovery uses existing client APIs and server timing hints. Newer local data, changed requests, navigation, stopping, and authorization failures prevent stale application. This is a recovery measure; it is not a claim that every transport failure has the same cause. Reports such as #38908 concern related child-agent summary symptoms, while this reproduction targets the main Work conversation history.

Validation

Thirteen helper cases and eight native view/read-path cases cover timing, unchanged plan status, pending indicators, branch protection, cancellation, and polling. The user confirmed that the historical timer now stops. No model request was sent for validation.

Entry points: assets/local-work-progress-v1.mjs, tests/work-progress.mjs, and tests/work-progress-native.mjs.

Reproducible repair

Complete English implementation, English release, and focused findings. The original project is wjtianze/codex-desktop-repair, with Chinese documentation on main. A star is appreciated if these repairs or reproductions are useful.

Both language editions passed 287 cases: 105 portable and 182 cases using functions extracted from the exact official installation. The public package contains patch fragments, independent helpers, tests, and documentation, not complete client bundles or account data. This is an evidence submission and local repair, not an upstream source merge.

Start by reading assets/local-work-progress-v1.mjs, then run the cases in tests/work-progress.mjs and tests/work-progress-native.mjs. Compare the historical Work timing and latest-turn waiting behavior with the documented repair boundary. Done means the listed timing, indicator, plan-status, branch-protection, cancellation, and polling cases pass without sending a model request.