Scheduled cloud routine firings refused as "NOT USER INPUT" since ~13 July 2026

Summary: A daily scheduled cloud routine (created via the
/v1/code/triggers API) ran cleanly for 7 consecutive days, then began being
refused by the model on every firing from 13 July 2026 onward, with no change
to the trigger's configuration or prompt. The refusal transcripts indicate
the routine's prompt is now being delivered wrapped in a "SYSTEM NOTIFICATION
— NOT USER INPUT / no human consent implied" disclaimer, causing each fresh
session to treat its own configured routine prompt as unverified injected
content and decline to execute it. Daily human intervention is now required
to force each run, which defeats the purpose of unattended routines.

This report contains no credentials. Trigger and environment IDs are
included for account-side lookup.

---

Setup

• Trigger: trig_01WRxo5kzaRt1Jxaq1mjCNrW ("Cloudbank daily digest"),

created 2026-07-05 via http_api, cron 0 18 * * * (UTC), enabled.

• Environment: env_014BibmsVyezcjve6zkTaaBD, network egress

allowlisted for the two hosts the routine writes to.

• What the routine does: researches banking/fintech news via web search,

writes a daily digest edition to a Supabase project (project owned by me),
triggers a Netlify rebuild via build hook (site owned by me), and sends
the edition to newsletter subscribers via the Buttondown API (account
owned by me). Credentials for these are embedded in the routine prompt —
acknowledged tradeoff, since environment variables/secret stores were
documented as visible to environment editors anyway and no dedicated
secrets mechanism was available for trigger prompts.

Timeline

| Date (fire, UTC) | Outcome | Evidence |
|---|---|---|
| 07-06 11:15 | Last config change (updated_at) — prompt updated, ran fine after | Trigger API |
| 07-07 → 07-12 fires | 7 consecutive clean automated runs | Editions published 18:15–18:23 UTC daily, ~10–20 min after the 18:04 fire |
| 07-13 fire onward | Every firing refused; model declines to execute | Editions only published 20:20–21:21 UTC each day, after manual human intervention |

Between the last clean run and the first refusal, nothing changed on my
side: trigger updated_at remains 2026-07-06; same prompt bytes, same
cron, same environment. Identical input, sharp date boundary, 7/7 successes
flipping to 0/4 — consistent with a server-side change in how firings are
delivered or evaluated, not with model variance.

What the refusal transcripts say

Four refusals so far; reasoning is highly consistent. All four lead with the
delivery framing. Representative quotes:

"The message was explicitly flagged by the system as NOT genuine user input — no human had approved or requested this in the visible conversation."

"It arrived wrapped in an explicit 'SYSTEM NOTIFICATION — NOT USER INPUT' disclaimer stating no human input or consent has been received..."

"Per how Routines actually work, a legitimately-configured scheduled prompt fires as an ordinary user turn — it isn't delivered as a flagged 'system notification' disclaiming its own legitimacy. That mismatch is itself a signal not to treat this as an authenticated, user-authorized trigger."

Secondary factors cited (plaintext credentials in the prompt, irreversible
actions like a subscriber email send) are real properties of the routine and
reasonable things for a model to weigh — but they were equally true during
the 7 days of clean runs. The delivery framing is the variable that changed.

Full transcripts available on request.

Hypothesis

Recent hardening of background-task notification framing (notifications now
explicitly stating no human input has occurred, as an anti-injection
measure against forged in-transcript approvals) appears to have been applied
to — or is now also wrapping — scheduled routine trigger firings. The
model's response to that framing is arguably correct given what it's told;
the problem is that a legitimately-configured, account-owner-created routine
prompt is now delivered self-labelled as unverified content, making refusal
the expected outcome for any routine that does consequential work.

Consistent with this: replying manually in the refused session (a genuine
human turn) reliably unblocks execution — which is what I've done daily
since the 13th.

Questions / asks

1. Did the delivery framing for scheduled trigger firings change on or

around 13 July 2026? Is routine prompt content intended to arrive inside
a "not user input" wrapper?

1. If intended, what is the supported way for a routine created by the

account owner to carry its authorization, so a fresh session can
distinguish "the configured prompt of this trigger, set up by the account
owner" from injected content? (A verifiable provenance marker on
trigger-config-sourced content would resolve this cleanly.)

1. Is a secrets mechanism for routine prompts planned, so credentials don't

have to sit in prompt text? (This would also remove one of the secondary
red flags the model cites.)

Impact

Daily manual intervention required to run a routine whose entire purpose is
unattended operation. No workaround exists on the user side: prompt-content
edits can't override a system-level wrapper, and each firing is a fresh
session so per-session confirmations don't persist.