[BUG] Cloud Routine marked Auto-disabled keeps executing anyway — stuck retrying a stale trigger every ~5 min for 10 days

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest related issues identified below — none cover this specific gap; see "Why this isn't a duplicate")
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

A Cloud Routine ("mr-esp32 CI auto-repair", configured Hourly) is marked Auto-disabled in the Routines panel, but it is still actively executing — dispatching a run every ~5 minutes, continuously, for the past 10 days. The UI state and the actual execution state have diverged.

This is the second time I've hit this exact pattern. I deleted an earlier routine that showed the identical symptom (marked disabled/stopped, kept firing), on the assumption it was a one-off; recreating it now that a second instance has shown up under different circumstances.

Environment

• macOS, Claude Desktop 1.24012.9 (03c61d), built 2026-07-24T04:59:17.000Z
• Claude Code 2.1.219
• Routine type: Cloud (not Local)
• Trigger mechanism: RemoteTrigger, scheduled Hourly

Steps to Reproduce / Observed Behavior

1. Routine mr-esp32 CI auto-repair was originally set up to auto-repair on GitHub Actions CI failures for blwfish/mr-esp32.
2. At some point it began failing every execution and was marked Auto-disabled in the Routines panel (red warning badge).
3. Despite that, executions have continued firing roughly every 5 minutes — not hourly as configured — with no gap, from 2026-07-19 through the time of this report (verified via the account's session/message history: same pattern observed at 14:04, 14:09, 14:14, 14:19, 14:24, 14:29, 14:34, 14:39, 14:44, and 14:49 on 2026-07-29, i.e. still firing as this report is being written).
4. Every single execution dispatches the byte-identical payload — same trigger id, same GitHub Actions run id, same URL — not a fresh dispatch for a new CI failure:

``
Use the RemoteTrigger tool to run the routine with id trig_01JCxm9zavQpeXAz7zWTsDsQ.
This is a CI auto-repair trigger. GitHub Actions run 29681879752 for blwfish/mr-esp32 failed.
URL: https://github.com/blwfish/mr-esp32/actions/runs/29681879752
``

1. Every execution fails identically and immediately:

``
Failed to authenticate: OAuth session expired and could not be refreshed
``

1. Across roughly 10 days at ~5-minute intervals, this is on the order of 2,700+ identical failed executions of a single stale trigger, none of which the "Auto-disabled" state prevented.

Expected Behavior

A routine marked Auto-disabled should not execute. If something is durably retrying a specific already-dispatched job independent of the routine's schedule/enabled state, that retry path should still respect Auto-disabled — or, at minimum, should back off and eventually give up rather than retrying an OAuth failure identically every 5 minutes indefinitely.

Possible mechanism (speculative — I can't verify this from the client side)

The fact that every execution re-sends the exact same stale trigger id/payload rather than a new one suggests this isn't the Hourly schedule re-firing — it looks more like a stuck retry queue for one specific already-dispatched job that isn't checking the routine's enabled state at all. I don't have visibility into the backend to confirm this; flagging it as a guess, not a claim.

Related Issues

• #73565 — closest sibling in the same feature area (area:routines): routines can get silently auto_disabled_env_not_found on backend environment-id rotation and never re-enable. Related theme (routine enabled/disabled state getting out of sync with reality, causing a silent unattended-automation failure), but the actual symptom is the opposite direction of this report: theirs goes disabled and correctly stops firing (a silent gap); this one goes disabled and keeps firing anyway (uncontrolled repetition). Not a duplicate, but likely worth investigating together given the shared subsystem.
• #81937 and #79685 — both describe headless/-p invocations failing with the identical error text "OAuth session expired and could not be refreshed" while a concurrent interactive session authenticates fine, with no recovery path for unattended callers. Routine dispatch is a headless invocation, so this is likely the same root cause for why every execution here fails — but neither issue touches the disabled-but-still-executing state-desync that's the actual subject of this report, so I'm filing separately rather than commenting there.

Happy to provide more of the execution history if useful for triage.