Cowork scheduled tasks: permission classifier refuses owner-authorized email sends ("Real-World Transactions"); same send succeeds in an attended session; no per-task allow
This is about Cowork on claude.ai (cloud scheduled tasks), not the CLI. The CLI-only template fields don't apply.
What happens
A recurring Cowork scheduled task (it sweeps the inbox, then replies to people for the account owner) builds a Gmail reply in the owner's own logged-in Gmail through Browserbase. Every check passes. When the run tries to click Send, the auto-mode permission classifier refuses it with the category "Real-World Transactions". There is no prompt anyone could answer and no way to allow it.
On 29 Sep 2026 it happened three times: runs at 11:10AM, 4:06PM and 5:11PM ET, all refused on the same send. That evening, in a session the owner opened himself, the same three drafts went out through the identical script, from the same account and the same Browserbase context, with no refusal.
Why it's a bug
The owner gave standing written instructions for these runs to send email without asking him first. The same classifier allows other writes in those runs: WhatsApp Web sends, Gmail labelling and archiving. It singles out email sending. The runs have no way to tell the classifier the action is authorized, so a scheduled task that exists to handle correspondence can't finish its job. Time-critical replies sat in drafts for hours.
Expected
One of these:
(a) a per-task or per-account setting that pre-authorizes named action categories (for example "send email from my own accounts") for unattended runs;
(b) respect for an explicit owner instruction stored in the task;
(c) at minimum, a notification to the owner with a one-tap approve, rather than a silent refusal the run can only log.
Related
#97308 covers the same pattern for browser writes to a logged-in CRM: it succeeds when the user is present, is denied in a scheduled task, and has no trusted-site setting. This one is the email-send case.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
One more data point: the task was already running with
permission_mode: bypassPermissions(itsderived_stateconfirms it, and aset_permission_modecontrol_request is the first event) during all three refused runs. So automatic approval doesn't help. The classifier refuses owner-authorized email sends even on a fully auto-approved scheduled task, and there is currently no setting the owner can change to allow them.Same here been auto sending quote emails for last 6 months then now today can't sent them and it's rubbish / perhaps time to go to codex as if Claude anthropic is blocking the simple task of sending emails you have to wonder what's the point!!
Same problem here, on Cowork with Opus 5.5, and it now blocks attended sessions too.
I run a small handcrafted gifting business in India. A daily Cowork scheduled task follows up our trade-expo leads on WhatsApp Web, Interakt (WhatsApp Business API) and our own business email. Until about 1 October it sent owner-approved messages and set Interakt campaigns live without trouble.
On 2 October 2026:
So the owner cannot authorise these sends at all: not in the task prompt, not with "Automatically approve", not in a live chat. My team had to send about 100 messages by hand before the windows closed.
+1 to the requests above, especially:
(a) an owner-level setting that pre-authorises named action categories, such as "reply on my own WhatsApp Business account to customers who messaged us", for both attended and unattended runs; and
(c) at minimum, a one-tap approve for a whole batch, instead of a refusal with no way to approve.