›_ Codex Issues
Codex Issues / #39412

[Windows] Scheduled automation tasks are missing from Pet activity tray in Running and Ready states

Open 💬 2 comments Opened Aug 19, 2026 by dpfvc2jrv8-cpu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

26.814.5167.0 (Microsoft Store/AppX)

What platform is your computer?

Windows 11; ARM64 app package

What issue are you seeing?

Standalone scheduled automation tasks run and complete successfully, but never appear in the floating Pet activity tray while Running or after completion as Ready. Normal manually started tasks appear in the tray at the same time.

This was reproduced with a custom v2 pet. The pet itself is awake and the overlay is visible, so the evidence points to activity-tray filtering/state presentation rather than the pet sprite package.

What steps can reproduce the bug?

  1. Open Codex Desktop and wake the pet.
  2. Start or keep a normal manual task open and confirm that it appears in the Pet activity tray.
  3. Create a standalone local scheduled automation that runs for about 60 seconds and produces a non-empty final response/inbox item.
  4. Watch the Pet activity tray during the full run.
  5. After the automation completes, check the tray again without opening the completed task.

Expected behavior

The scheduled task should appear in the Pet activity tray as Running during execution, then as Ready while its completed result remains unread.

Actual behavior

Only the manual task is shown. The scheduled automation is absent from the visible tray both while running and after completion.

A controlled reproduction ran for approximately 74 seconds. During that run:

  • the scheduled thread was reported as active and later completed with no error;
  • events were routed to avatarOverlay while the overlay renderer was visible;
  • status/reasoning updates reached both the primary window and avatarOverlay;
  • avatarOverlay created one inbox item at completion;
  • the completed thread was added to the local unread-thread state;
  • nevertheless, the task never appeared visually in the Pet activity tray as Running or Ready.

Sanitized reproduction reference:

  • Test thread: 01a01838-b82e-7e83-939a-d77c1ff63d67
  • Overlay route: 2026-08-19 12:12:45 Asia/Taipei
  • Active run: 12:12:47–12:14:01
  • Avatar-overlay inbox item: 12:14:01
  • Unread-state update: 12:14:02

Additional information

  • A full app exit/restart and update to 26.814.5167.0 did not fix the issue.
  • The same behavior reproduced twice with temporary test automations.
  • The temporary automations were removed after testing.
  • No supported setting or per-task mute/hidden state was found.
  • No private logs or local paths are attached.
  • Read-only bundle inspection suggests automation-sourced threads receive special notification-tray filtering. This is an inference, but it is consistent with automation tasks being hidden despite valid overlay routing, inbox creation, and unread state.

Related, but not identical:

  • #24302 — pet tray omits active local threads
  • #32994 — Windows pet task-tracking behavior
  • #28995 — pet overlay state/animation mismatch

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 9 days ago

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

  • #39156

Powered by Codex Action

Evgeniy-Chapurin · 8 days ago

Additional Windows x64 reproduction on 26.814.5517.0

I can confirm this bug on a newer Windows x64 build with two real standalone scheduled automations running concurrently.

Environment
  • Codex/ChatGPT desktop app: 26.814.5517.0 (Microsoft Store/AppX)
  • Windows 11 25H2, build 26200.9168
  • Architecture: x64 / AMD64
  • Observed: 2026-08-20, Asia/Irkutsk
  • The pet was awake and visible.
Reproduction and evidence
  1. Two standalone local scheduled automations started in the same project.
  2. The project task list showed both automation rows with active spinner indicators.
  3. At the same time, the Pet activity tray displayed no task activity.
  4. Independent app-server snapshots confirmed that both backing conversations were genuinely active:
  • thread.status.type = active
  • latestTurn.status = inProgress
  • each conversation had current assistant progress and tool activity
  • neither conversation was waiting for input or in an error state
  1. One automation later completed successfully with no error after 945,759 ms; the other remained active and continued publishing progress. This confirms that the original Running states were not stale sidebar indicators.

The task names, contents, and thread IDs are omitted for privacy, but they were ordinary standalone cron automations with threadSource = automation.

Expected behavior

The official Pets documentation says:

  • Running means “A chat is actively working.”
  • When more than one chat has activity, the Pet prioritizes and exposes those chats in the activity tray.

https://learn.chatgpt.com/docs/pets

Both active automation conversations should therefore have appeared as Running.

Actual behavior

Both automations were visible as active in the project task list and were confirmed active by the app server, but neither appeared in the Pet activity tray.

Read-only packaged-renderer evidence

Inspection of the installed renderer bundle points to deterministic filtering rather than a lost event subscription or stale cache. In:

webview/assets/avatar-overlay-native-page-CnrjUN8X.js

the session mapping treats automation-sourced conversations as a special/suppressed branch. Simplified pseudocode of the packaged condition:

suppressed = isHeartbeatTurn || conversation.threadSource === "automation";

showInNotificationTray =
  !suppressed ||
  status === "waiting" ||
  status === "failed" ||
  (isSpecialReview && status === "review") ||
  subtitle != null;

For a normally running automation whose latest agent updates are commentary/progress messages, the automation-specific subtitle extraction returns null. As a result, showInNotificationTray is false even though the status is Running.

This exactly matches the observed behavior and also provides a plausible common cause for #39156, although this reproduction is specifically for the floating Pet tray on Windows.

Suggested fix
  • Do not suppress threadSource === "automation" conversations while their resolved status is running; or
  • add a supported setting allowing users to include running automations in the Pet tray.

Completed automation results should likewise remain visible as Ready while unread, consistent with the documentation.