Widgets freeze on stale timeline: chronod reloads fail with CHSErrorDomain 1050 while extension logs success; killing CodexBarWidget is the only fix

Start by reproducing the stale timeline on macOS 26 and compare chronod's CHSErrorDomain 1050 logs with the widget extension's timeline request logs. Inspect the widget timeline reload path and WidgetFormat.relativeDate; done means persistent reload failures are detected and recovered from or surfaced clearly to the user.

Summary

Desktop/Notification-Center widgets can get stuck on a stale timeline indefinitely: chronod fails every reload with CHSErrorDomain Code=1050 "timelineReloadFailed" while the widget extension itself logs every render as success. The failure loop survives an app relaunch — the only thing that fixed it was killing the stale widget-extension process, after which the next reload succeeded immediately.

Environment

• CodexBar 0.56.2 (build 133)
• macOS 26.0 (26A5421a)
• Widgets: CodexBar Switcher (systemLarge) and CodexBar Burn Down (Combined) (systemMedium), placed on the desktop

Observed behavior

The app side was completely healthy the whole time:

• widget-snapshot.json in the app-group container was republished every ~60 s (mtime advanced continuously).
• The main app logged reloadAllTimelines() - reloaded all timelines every ~40–60 s.
• Codex history/quota captures kept updating.

But the widgets never took the new timelines. In chronod's log, every reload of both widgets failed, with retries exhausting and the next attempt being pushed a full hour ahead each time:

chronod[1459] [com.apple.chrono:timeline.store] Task [108017] [com.steipete.codexbar::com.steipete.codexbar.widget:CodexBarCombinedBurnDownWidget:...] Reload failed; 0 retries remaining: CHSErrorDomain (1050) Error Domain=CHSErrorDomain Code=1050 "timelineReloadFailed" UserInfo={NSDebugDescription=timelineReloadFailed}
chronod[1459] [com.apple.chrono:timeline.store] Task [108018] [com.steipete.codexbar::com.steipete.codexbar.widget:CodexBarSwitcherWidget] Reload failed; next attempt due at 2026-09-01T11:59:39: CHSErrorDomain (1050) ...

Meanwhile the extension process (pid 8337, alive long before the app relaunch discussed below) believed every request succeeded:

CodexBarWidget[8337] [com.apple.chrono:timeline] Request began for CodexBarSwitcherWidget:systemLarge:(noIntent) - to archive: /private/var/folders/.../com.apple.chrono/TemporaryItems/NSIRD_chronod_.../systemLarge...chrono-timeline
CodexBarWidget[8337] [com.apple.chrono:timeline] Request ended for CodexBarSwitcherWidget:systemLarge:(noIntent) - success

Around the failures, chronod also logged the extension session tearing down and the extension being suspended while not visible:

chronod[1459] [com.apple.chrono:session] [codexbar.widget-…] Session deinit
chronod[1459] [com.apple.runningboard:monitor] Received state update for 8337 (extension<com.steipete.codexbar.widget[...]>, running-suspended-NotVisible)

So the extension renders the archive, but the handoff to chronod dies (XPC session teardown / suspension), and chronod records a hard failure for every attempt. The mismatch between the extension's "Request ended - success" and chronod's timelineReloadFailed is the notable part.

Why an app relaunch does not fix it

Restarting the main CodexBar app (new pid, fresh publishing) did not resolve the freeze: the CodexBarWidget extension process survived the app relaunch and kept failing the same way. From the user's perspective the widget stays frozen no matter how often the app is restarted.

Workaround that actually fixed it

killall CodexBarWidget

LaunchServices/chronod respawned the extension immediately (new pid), and on the very next reload cycle:

chronod[1459] [com.apple.chrono:timeline.store] Task [108072] [com.steipete.codexbar::com.steipete.codexbar.widget:CodexBarSwitcherWidget] Reload success
chronod[1459] [com.apple.chrono:timeline.store] [com.steipete.codexbar::com.steipete.codexbar.widget:CodexBarSwitcherWidget] Reload state reload -> clean
chronod[1459] [com.apple.chrono:archiving] [..CodexBarSwitcherWidget:systemLarge:..] destroying promise for 'Accepted successfully to file://.../Containers/com.steipete.codexbar.widget/Data/SystemData/com.apple.chrono/timelines/...'
chronod[1459] [com.apple.chrono:timeline.store] Task [108073] [..CodexBarCombinedBurnDownWidget] Reload success

The widgets picked up fresh timelines right away and rendered current data.

Minor UX note

The widget's "updated N ago" label is baked at render time (RelativeDateTimeFormatter in WidgetFormat.relativeDate), and the last accepted render happened seconds after its publish — so a widget frozen for hours can still display a fresh-looking "6 sec. ago" label, which makes the staleness hard to notice.

Requested follow-up

• Consider detecting this state (extension alive but chronod reloads failing persistently with 1050) and recovering, e.g. asking the system to respawn the extension, or surfacing a "widgets are stale — tap to reload" state.
• If this turns out to be an OS-level issue (extension suspension vs. chronod handoff on macOS 26), it may be worth a radar/Feedback as well.

Happy to grab more logs if useful.