[macOS App] Active task can silently stop making progress and remain active across an OS-update reboot

What version of the Codex App are you using?

Codex in ChatGPT for macOS, framework version 151.0.7922.174.

What subscription do you have?

ChatGPT subscription (not believed to be relevant; account details omitted).

What platform is your computer?

macOS 26.6.2 (25G83)
Darwin 25.6.0 arm64 arm

What issue are you seeing?

A long-running persistent Codex task/goal silently stopped making progress while it was still presented as active. It had no running tool call, no pending approval/input, and no wait operation recorded, but it was neither marked paused/failed/needs-attention nor surfaced to the user.

Later, macOS installed an update and rebooted. After the app came back, the task was still represented as active and its visible duration appeared to start from post-reboot Computer Use activity (~46 minutes), rather than preserving the original task lifetime or explicitly showing an interruption/recovery state.

This makes an unattended task look healthy even though it has stopped. The OS update/reboot is not the reported root cause; it exposed the missing task watchdog and restart-recovery state handling.

Steps / observed timeline

This is an observed production incident rather than a deterministic minimal reproduction. Times below are local time (UTC+8); private prompts, paths, and session IDs are omitted.

1. Start a persistent multi-step task/goal in the macOS Codex App and allow it to continue autonomously.
2. At 01:41, the task resumed and made several short read-only checks through 01:42.
3. From 01:42:06 to 03:21:34, the thread event log had no assistant message, tool invocation, tool result, user input, pending approval, or explicit wait event. The task nonetheless remained active.
4. It made a short set of successful checks from 03:21 to 03:22 (including a Codex App Server smoke call and local capability checks).
5. From 03:22:17 to 05:43:11, the thread again had no recorded progress or explicit terminal/blocked transition.
6. macOS Software Update initiated its restart flow at 05:34 and the machine rebooted at 05:39. The update history records macOS 26.6.2 installed at 05:34:01; no kernel panic evidence was found.
7. After the app recovered, Computer Use activity started at 05:43. The UI then showed an execution duration of about 46 minutes, with no indication that the original active task had been silently idle and interrupted by a reboot.

I searched open issues for task stuck active reboot timer, restart task recovery, and task execution duration; I found related restart-continuity reports but no matching report for the combination of silent no-progress active state plus misleading post-reboot duration.

Expected behavior

• A persistent active task should have an observable progress/watchdog contract. If it has no active tool, child task, waiting state, or user-input requirement for a configurable interval, it should transition to needs attention / paused / failed and notify the user instead of continuing to display as healthy active work.
• A host restart should explicitly transition active work to interrupted (or safely resume it only after restoring its execution state). The UI should distinguish original task wall-clock lifetime, active compute/runtime time, and time since recovery; it should never silently reset the meaning of the duration label.
• The event timeline should expose the reason for the transition so a user can tell whether the cause was a runtime stall, an app restart, host shutdown, or an external wait.

Additional information

• No long-running terminal session, device/OAuth-login wait, approval prompt, or active child task explained either idle interval in the main task event stream.
• The reboot was a normal Software Update restart; I found a shutdown-stall diagnostic but no kernel panic report.
• I can provide a redacted event-log excerpt and diagnostic metadata privately if maintainers need it.

Start by reviewing the reported event timeline and any related restart-continuity reports, then trace how persistent tasks represent active, waiting, stalled, and recovered states. Use the redacted event-log excerpt if maintainers provide it. Done should include visible handling for prolonged no-progress periods and host-restart interruption, with task duration and transition reasons preserved in the UI.