Persistent Dock badge from orphaned scheduled-task unread IDs

Open 💬 1 comment Opened Aug 5, 2026 by inputid-Jung
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • ChatGPT/Codex desktop app for macOS: 26.730.61639 (build 6234)
  • macOS: 26.5.2 (25F84)
  • UI locale: Korean
  • Model/subscription: not relevant; this is desktop persisted notification state

What issue are you seeing?

The macOS Dock notification badge remained stuck at 30 even though:

  • there were no blue unread dots anywhere in the UI;
  • Scheduled contained no tasks or completed runs;
  • Scheduled → Mark all as read had no effect;
  • quitting and relaunching the app preserved the badge.

A new notification changed the badge from 30 to 31, and opening that notification reduced it back to 30. This showed that 30 stale unread entries were still being counted, but were not reachable from the UI.

Diagnostic evidence

The persisted atom state key unread-thread-ids-by-host-v1.local contained exactly 30 thread IDs. Every ID mapped to local thread metadata with:

  • thread_source=automation
  • source=vscode

At the same time, the current automations / automation-runs store contained zero active items.

Editing the persisted state while the app was running did not work: the in-memory state rewrote the stale values during shutdown.

Likely root cause

Unread IDs for deleted or obsolete scheduled-task runs remain in the persisted unread atom after their automation records disappear. The Dock badge still counts those IDs, while Mark all as read only processes currently visible inbox/automation items, leaving no UI path to clear the orphaned unread state.

Steps to reproduce

  1. Create a scheduled task that produces multiple unread runs.
  2. Delete or otherwise remove the scheduled task and its visible runs.
  3. Observe that the Dock badge can continue counting the old automation-run unread IDs.
  4. Open Scheduled → Mark all as read.
  5. Observe that the orphaned count remains after relaunch.

Expected behavior

Any of these should prevent the stuck badge:

  • reconcile stale unread IDs against current automation/thread state at startup;
  • when an automation is deleted, clear unread state for its historical runs without deleting thread history;
  • make Scheduled → Mark all as read clear orphaned automation unread entries;
  • only count unread items that are still reachable from the UI.

Workaround and verification

The issue was resolved by:

  1. fully quitting the app;
  2. backing up both persisted state files;
  3. removing only unread IDs whose thread metadata had thread_source=automation from the active state and its backup;
  4. preserving all thread history and all non-automation unread IDs;
  5. relaunching the app.

Verification:

  • active unread count: 30 → 0
  • backup unread count: 30 → 0
  • macOS Dock StatusLabel: 30 → empty
  • user confirmed the badge was gone

Diagnostics

A diagnostic feedback bundle including logs and the relevant conversation was uploaded through the official /feedback flow.

Uploaded feedback thread: 019fd355-5fc7-7e73-8657-1d1208975e28

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 22 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35884

Powered by Codex Action