Preflight Checklist
What's Wrong?
Scheduled tasks running in the cloud (Cowork) with
derived_state.permission_mode = "auto" are refused by the permission
classifier on actions the account owner explicitly authorized. The
refusal categories observed are [Real-World Transactions],
[External System Writes] and [Auto-Mode Bypass]. Read-only steps get
hit too.
The core problem is not the false positive. It is that in an
unattended scheduled run there is NO human turn, so the refusal can
never become an approval prompt that anyone could answer. The exact
same action, requested by the same owner, succeeds when run attended
in a chat session. Net effect: auto mode is the only mode in which
owner authorization cannot be expressed at all. The run dies
silently and nothing says so.
What Should Happen?
Either one of these would fix it:
(a) Let the owner pre-authorize a refusal category per scheduled
task, so an action the owner has already authorized in writing
is not re-adjudicated at run time.
(b) Make the refusal surface as a PENDING APPROVAL the owner can
answer afterwards, instead of killing the run with no record.
Today the run just ends and the owner finds out by noticing the
work was never done.
Right now the only workaround is for the owner to sit in a chat and
do by hand what the scheduled task exists to do, which removes the
reason for having scheduled tasks.
Error Messages/Logs
No verbatim log line was captured — the run ends without surfacing
one to the user. What is observable is the refusal category named in
the run: [Real-World Transactions], and in other runs
[External System Writes] and [Auto-Mode Bypass].
The task was in auto mode at the time
(derived_state.permission_mode: "auto"), so no approval prompt was
shown and nothing was pending anywhere.
Steps to Reproduce
- Create a cloud scheduled task (Cowork) whose prompt instructs an
action the account owner has authorized: e.g. register an order in
a factory's web system where the owner is the logged-in account
holder, or send an e-mail reply the owner authorized in writing.
- Confirm the task is in auto mode
(derived_state.permission_mode: "auto").
- Let it fire on its schedule, unattended.
- The action is refused by the permission classifier. No approval
prompt appears, because there is no human turn in the run.
- Run the same action attended, in a normal chat session, with the
same account and the same target system. It succeeds.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown / not applicable. No version was observed in which this worked unattended — the action has only ever succeeded when run attended, in a chat session. Other reports place the start of auto-mode refusals around 2026-09-22.
Claude Code Version
N/A — Cowork (Claude app, web + desktop), not the Claude Code CLI. No CLI version applies.
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Context: a one-person furniture sales rep in Brazil runs an "office"
of scheduled tasks. Two authorized actions break — registering
orders in a factory's own web system, and sending e-mail replies he
authorized in writing. Both work when he is watching. Both die when
he is not.
Presence is not attention. His laptop is open and minimized either
way; he is not reading the screen. The only difference between the
working case and the failing case is whether a turn exists for the
prompt to land in.
The "Real-World Transactions" label is also a misclassification for
this case. Creating an order draft in a factory portal is not a
transaction. It becomes one only when the factory accepts the order
and invoices it, which is a separate human step at the factory.
Related open issues, none with a response yet: #98287, #97308,
#97914, #97613, #84390, #40470.
Preflight Checklist
What's Wrong?
Scheduled tasks running in the cloud (Cowork) with
derived_state.permission_mode = "auto" are refused by the permission
classifier on actions the account owner explicitly authorized. The
refusal categories observed are [Real-World Transactions],
[External System Writes] and [Auto-Mode Bypass]. Read-only steps get
hit too.
The core problem is not the false positive. It is that in an
unattended scheduled run there is NO human turn, so the refusal can
never become an approval prompt that anyone could answer. The exact
same action, requested by the same owner, succeeds when run attended
in a chat session. Net effect: auto mode is the only mode in which
owner authorization cannot be expressed at all. The run dies
silently and nothing says so.
What Should Happen?
Either one of these would fix it:
(a) Let the owner pre-authorize a refusal category per scheduled
task, so an action the owner has already authorized in writing
is not re-adjudicated at run time.
(b) Make the refusal surface as a PENDING APPROVAL the owner can
answer afterwards, instead of killing the run with no record.
Today the run just ends and the owner finds out by noticing the
work was never done.
Right now the only workaround is for the owner to sit in a chat and
do by hand what the scheduled task exists to do, which removes the
reason for having scheduled tasks.
Error Messages/Logs
Steps to Reproduce
action the account owner has authorized: e.g. register an order in
a factory's web system where the owner is the logged-in account
holder, or send an e-mail reply the owner authorized in writing.
(derived_state.permission_mode: "auto").
prompt appears, because there is no human turn in the run.
same account and the same target system. It succeeds.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown / not applicable. No version was observed in which this worked unattended — the action has only ever succeeded when run attended, in a chat session. Other reports place the start of auto-mode refusals around 2026-09-22.
Claude Code Version
N/A — Cowork (Claude app, web + desktop), not the Claude Code CLI. No CLI version applies.
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Context: a one-person furniture sales rep in Brazil runs an "office"
of scheduled tasks. Two authorized actions break — registering
orders in a factory's own web system, and sending e-mail replies he
authorized in writing. Both work when he is watching. Both die when
he is not.
Presence is not attention. His laptop is open and minimized either
way; he is not reading the screen. The only difference between the
working case and the failing case is whether a turn exists for the
prompt to land in.
The "Real-World Transactions" label is also a misclassification for
this case. Creating an order draft in a factory portal is not a
transaction. It becomes one only when the factory accepts the order
and invoices it, which is a separate human step at the factory.
Related open issues, none with a response yet: #98287, #97308,
#97914, #97613, #84390, #40470.