[Windows Desktop] Scheduled tasks wake, acknowledge or report status, then stop without completing assigned work

Summary

A thread-attached 30-minute heartbeat showed a 64-minute start-to-start gap. Across five examined wakes, each start occurred approximately 30 minutes after the immediately preceding task turn completed—including an intervening owner turn.

This is an observed incident with independently recomputed timestamps, not a deterministic reproduction of a dropped occurrence. Completion/activity anchoring is the leading explanation; intentional fixed-delay semantics, deadline reset, and other deferral mechanisms cannot be distinguished from the available records.

Please clarify the intended interval semantics and expose occurrence-level delivery outcomes. If “every 30 minutes” is fixed-rate, unrelated task activity should not continually postpone the deadline.

Environment

• Windows 11, OS version 10.0.26200.0.
• Installed/running package at submission-time inspection: OpenAI.Codex_26.903.9818.0_x64. This is not independently established as the exact package revision at every incident timestamp.
• Model in examined turns: gpt-6-astra.
• Local heartbeat attached to an existing long-running task.
• Saved recurrence: RRULE:FREQ=MINUTELY;INTERVAL=30.
• Examined execution policy: on-request, reviewer auto_review, workspace-write, restricted network.
• Local time zone: America/New_York. All timestamps below are UTC.
• Public source reviewed at 944d6fd1ba4baab69dbedd205282dc72ec20abb5; this source revision is not asserted to match the installed binary.

Expected behavior

An interval automation should have understandable, stable scheduling semantics. If due while its task is busy, it should retain pending work and report the deferral, then run within a documented bound after admission becomes possible. If multiple checks are coalesced, that disposition should be visible.

The user should be able to distinguish a planned deadline, an attempted submission, an accepted turn, a completed turn, and an actionable result. A last-run timestamp alone is insufficient.

Actual timing

These are lifecycle timestamps from the original task rollout, not estimates from the UI.

The interval from 22:35:49.702 to 23:39:50.634 is 64m 0.932s.

For a fixed-rate interpretation, 23:05:49.702 would be the next analytical deadline after the first start. That is not a recovered persisted due timestamp.

The Governor task completed a turn at 22:49:48.055 and had no intervening task start until an owner turn at 23:09:08.447. Therefore continuous execution of that task does not explain the entire interval containing the analytical deadline.

Local logs contain activity in every five-minute bucket from 22:30 through 23:45. The 23:05–23:10 bucket contains 89 records from four processes. This weakens a simple whole-host outage explanation, but does not prove uninterrupted uptime or exclude a short dispatcher stall. No usage-cap error was identified as the cause of this gap.

What the retained state can and cannot establish

Read-only inspection found:

• Actual heartbeat starts in the rollout and canonical task history.
• Zero rows for this automation in the inspected automation_runs table. This does not mean the heartbeat never ran; it means that table did not provide its occurrence history.
• Submission logs under general session logging targets, including incoming heartbeat payloads. No matched planned-due/admission/deferral/disposition chain was recovered.
• No occurrence ID or planned-due field identified in the inspected incoming payloads.
• The final saved last_run_at was 70 ms before the final recorded lifecycle start. That sample cannot prove whether a failed attempt would also advance it.
• The automation was later paused and remains paused. Current next_run_at = null and an empty queue snapshot are not evidence of historical delivery loss.

The investigation did not unpause the production automation or alter permissions to reproduce the incident.

Workflow leading to the observation

1. Use a recurring 30-minute heartbeat attached to a persistent local task.
2. Continue ordinary owner interactions between scheduled checks.
3. Compare scheduled starts with both previous scheduled starts and the most recent turn completions.
4. Observe the timing above and the lack of an occurrence-level reason for the longer interval.

This sequence documents what happened. A controlled minimal reproduction is still needed; it has not been demonstrated that every owner message resets the timer.

Suggested maintainer test: use a fake clock around the actual dispatcher, send owner input shortly before due time, then repeat with sustained sub-interval activity. Compare behavior against a fully idle control. Include busy admission, restart, coalescing and pause/edit races.

Public source boundary and narrow investigation direction

The public core already exposes start-if-idle and typed admission outcomes:

• start_turn_if_idle
• Turn submission outcomes
• Admission checks

These mechanisms do not prove that the Desktop dispatcher drops refused work. The recurrence dispatcher was not located in the inspected public checkout.

Please investigate whether next due is anchored to scheduled time, last completion, or last activity, and how NotIdle/PendingTriggerTurn are retained or retried. If fixed-rate delivery is intended, a narrow repair would preserve due-occurrence identity across admission attempts, fence by schedule revision, and avoid resetting the deadline on unrelated input. After an ambiguous submission timeout, reconcile the occurrence with its turn before replaying it to avoid duplicate actions.

Useful diagnostic fields: automation and occurrence identity, schedule revision, planned due, attempted/accepted/start/completion timestamps, turn identity, admission outcome, retry reason and coalesced count.

Related observations: not asserted as the timer's cause

The same task also exhibited these separately evidenced behaviors:

• Two owner instructions ended with acknowledgment-only responses and zero tool calls. These were owner turns, so they do not establish a scheduler-only model failure.
• Subsequent scheduled checks read usage and room state without advancing dependent work. Some quiet monitoring was consistent with the saved instructions; no-tool/no-edit counts are not a failure-rate metric.
• All 96 indexed automation inputs were automation_update function outputs without a call ID. The public toolOutput branch constructs that shape. No strict-provider HTTP 400 was observed in this native-Astra incident.
• Scheduled filesystem profiles contained 18 entries versus 11 for manual turns, but both resolved to the same 11 unique entries, including project write access. A specific automatic-review rejection was recorded; lost human approval or a blanket permission downgrade was not proved.
• A later compaction rewrite occurred after the examined no-op checks. It does not prove that earlier instructions were erased.

These observations explain why the user experiences unreliable unattended progress, but should not be collapsed into one unverified root cause. No patch, end-to-end fix, or zero-regression guarantee is claimed.

Related issues / duplicate check

• #44123: macOS 25-minute heartbeat with an unexplained next-run gap after a schedule update. This adds a Windows completion-relative sequence and an identified idle interval; please consolidate if the same underlying behavior is already tracked.
• #44723 and #44519: separate unpaired-tool-output/provider failures.
• #41995: scheduled NOTIFY result visibility after reload.
• #29610: permission snapshot/default fallback report; this incident did not reproduce effective access loss.
• #37556: background task-management calls hanging; no pending call explains the zero-call owner acknowledgments here.
• #43632: scheduled task answers an older request; related symptom, not a demonstrated common cause.

Prepared with GPT-6 Astra from read-only original-record inspection and public-source review. Only sanitized timestamps, settings and aggregate observations are included. Raw conversations, private project prompts and paths, credentials, account details, and task/automation identifiers are omitted.