[Bug] Scheduled task fires 12x instead of once — duplicate sessions with unique task IDs

[pfilbin90]

Description

A single scheduled task configured to run once daily is firing multiple times per trigger, creating duplicate sessions with unique task IDs. Additionally, completed sessions are being re-triggered back to "Planning" state.

Bug 1: Duplicate Session Firing (Confirmed Recurring)

April 2, 2026 (first occurrence)

1. Scheduled task A (Daily at 2:30 AM CDT): fired 12x instead of 1x
2. Scheduled task B (Daily at 12:30 AM CDT): fired 6x instead of 1x
3. Other tasks (3 others): fired correctly 1x each
4. Impact: 32/100 daily sessions consumed instead of ~11. 10 near-identical PRs from task A, 6 from task B.

April 3, 2026 (second occurrence — bug is ongoing)

1. Scheduled task C: fired 13x instead of 1x (6 completed, 7 stuck "Awaiting User Feedback")
2. Scheduled task D: fired 8x instead of 1x (1 completed, 7 stuck)
3. Other tasks fired correctly 1x each
4. Impact: ~21 wasted sessions, 3 duplicate PRs closed manually

Pattern

• Longer-running tasks duplicate more (12-13x) while quick tasks run correctly once
• Suggests a timeout/retry mechanism in the scheduler is re-dispatching before confirming the first execution started

Bug 2: Completed Sessions Re-triggering (NEW)

During monitoring on April 3, two sessions that had reached "Completed" status reverted to "Planning" and began re-executing:

• Session 12377317433143918846: was "Completed", switched to "Planning" ~15 min later
• Session 14017486297168102612: was "Completed", switched to "Planning" ~30 min later

This is a separate issue from Bug 1 — these are not new sessions, but completed sessions being zombied back to life.

Reproduction

1. Create a scheduled task set to run daily
2. Use a prompt that triggers moderate work (file reads + code analysis + potential PR creation)
3. Wait for the scheduled trigger
4. Observe via jules remote list --session that multiple sessions are created with unique task IDs

Expected Behavior

1 session created per scheduled trigger, 1 task ID assigned. Completed sessions stay completed.

Actual Behavior

• 6-13 sessions created from a single scheduled trigger, each with a unique task ID
• Some completed sessions revert to "Planning" and re-execute
• "Awaiting User Feedback" sessions accumulate with no way to dismiss via CLI

Impact

• Session quota: 40-50 of 200 daily sessions consumed by duplicates across two nights
• PR noise: Duplicate PRs require manual cleanup
• No CLI mitigation: jules remote has no cancel, reply, or dismiss command, so stuck sessions can only be managed via TUI/web UI
• Ongoing: Bug has reproduced on consecutive nights (April 2 and April 3, 2026)

Environment

• Jules CLI: @google/jules@0.1.41
• 11 scheduled tasks configured, all "Active", all set to daily
• Repository: private Flutter/Dart monorepo
• Prompts contain no loops, retry logic, or task-creation instructions

Prompt Example

Read the shared preamble for execution rules, then read project conventions, then read the agent-specific instructions and execute the mission described. You are unattended — no questions, no status. Either fix an issue and create a PR, or exit silently.

Requested Fixes

1. Dedup scheduled triggers — a scheduled task should create exactly 1 session per trigger
2. Completed sessions must not revert — once "Completed", a session should be immutable
3. CLI session management — add jules remote cancel/dismiss --session <id> for stuck sessions
4. Visibility — expose session conversation history via jules remote view --session <id> (currently only diffs are available via pull)

[pfilbin90]

Update (April 3): This bug has reproduced on a second consecutive night. New findings:

1. A different scheduled task fired 13x (was a different task at 12x yesterday)
2. Another task fired 8x
3. New bug discovered: Two completed sessions reverted from "Completed" back to "Planning" state and began re-executing — zombie sessions
4. Total wasted sessions across 2 nights: ~50 out of 200 available

The issue body has been updated with full details. This is actively consuming session quota and requires urgent attention.

cc @davideast — tagging as you appear active on this repo. Is there a better channel to escalate scheduled task bugs? Also cross-posted to google-labs-code/jules-awesome-list#99 for visibility.

[pfilbin90]

Update (April 3, follow-up): Duplication is non-deterministic and rotates agents

Comparing the two nights of data, the duplicated agents rotated completely:

Night	Duplicated Agents	Clean Agents
April 2	Task A (12x), Task B (6x)	Tasks C-K (1x each)
April 3	Task C (13x), Task D (8x)	Tasks A-B, E-K (1x each)

Key observations:

• Same prompts, different outcomes — Task A duplicated 12x on night 1 but ran cleanly on night 2. Task C was clean on night 1 but duplicated 13x on night 2.
• Not correlated with task complexity — Task D (lightweight analytics scan) duplicated 8x on night 2, while Task A (heavier code analysis) ran clean on the same night.
• Possible time-of-day clustering — on night 2, duplication occurred at ~1:00 AM CDT and ~5:00 AM CDT with a clean window in between, suggesting transient infrastructure conditions.

This points to a backend scheduler idempotency issue — likely the dispatch mechanism retries when it doesn't receive a timely ACK from the worker pool, and the retry creates a new session instead of recognizing the original was already started. The non-deterministic rotation rules out prompt content or task complexity as contributing factors.

Daily session usage: 31/100 consumed today, with only ~10 being intentional.