[Windows Desktop] Heartbeat automation ignores RRULE COUNT=17 and ran 116 times

What version of the Codex App are you using?

• Codex Desktop: 26.825.4187.0
• Active bundled CLI: codex-cli 0.150.0-alpha.12.2

What subscription do you have?

Account and plan details are intentionally omitted from this public report. A private Support request is being prepared for usage-accounting review.

What platform is your computer?

• Microsoft Windows 11 Home, version 10.0.26200, build 26200, x64
• Time zone: Europe/Istanbul

What issue are you seeing?

A same-thread heartbeat automation with the bounded schedule below continued firing long after its requested count had been exhausted:

FREQ=HOURLY;INTERVAL=1;COUNT=17

Read-only inspection of the thread rollout found 116 actual user heartbeat messages, from:

• first: 2026-09-02T00:44:14.903Z
• last: 2026-09-08T14:47:54.304Z

The count was restricted to top-level response_item records whose payload was a user message beginning with the heartbeat envelope; compacted-history copies, tool-command strings, and documentation examples were excluded. The persisted automation still contained COUNT=17 and was later manually paused.

During part of this period the user also observed roughly 12 hours in which the task appeared to be working but produced no corresponding repository progress, later surfaced a Codex error, and depleted usage. This report does not claim that the RRULE bug caused the stall or that it shares the root cause of the control-queue problem described in #43525. Repeated unintended wake-ups are, however, a plausible amplifier worth correlating in telemetry.

What steps can reproduce the bug?

1. Create a same-thread heartbeat automation with:

   FREQ=HOURLY;INTERVAL=1;COUNT=17
   

2. Leave the desktop app and thread available across multiple days.
3. Inspect the persisted automation configuration and the thread's top-level heartbeat messages.
4. Observe that executions continue after the seventeenth occurrence while the stored RRULE still contains COUNT=17.
5. Pause the automation manually to stop further executions.

This is an observed production sequence, not yet a minimal isolated scheduler test.

What is the expected behavior?

• The scheduler must stop dispatching the automation after exactly 17 occurrences.
• The automation should transition to a clearly completed/exhausted state when COUNT is reached.
• No later heartbeat turn should be created or consume usage.
• The UI should expose an auditable per-run count/history and flag any mismatch between the RRULE limit and actual dispatch count.
• Recovery/restart logic must preserve the consumed occurrence count and must not silently reset it.
• If execution cannot be bounded reliably, the automation should fail closed and report an actionable error.

Additional information

• The automation is now paused to prevent additional unintended usage.
• Thread ID, automation ID, account details, repository paths, task contents, and raw logs are omitted from this public issue.
• A private account-support request separately asks OpenAI to inspect server-side usage accounting and restore any allowance proven to have been consumed incorrectly.
• Public service incidents on September 3 and 4 may overlap in time, but no causal claim is made here.

No repository files or tests are named, and the report is not yet a minimal isolated scheduler test. Start by locating the heartbeat automation scheduler and persisted RRULE handling, then trace dispatch, restart recovery, and completion state. Done means COUNT=17 reliably limits dispatches, preserves the consumed count across recovery, and provides a regression test for the observed mismatch.