[BUG] Cloud routine hangs on a permission prompt for the built-in Artifact tool, contradicting "routines run autonomously"

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 3, 2026

A weekday routine created at claude.ai/code/routines invokes the first-party /morning skill, which renders a brief and publishes it as a private artifact. Every run parks in REQUIRES_ACTION on a pending permission prompt — update the artifact "Morning Brief" — with nobody awake to answer, so the run dies there and the closing summary never arrives either.

This contradicts the documentation. Routines are described as having "no permission-mode picker and no approval prompts during a run", and the scheduling comparison table lists Cloud routines as "Permission prompts: No (runs autonomously)."

The routine's stored config carries allowed_tools: [Bash, Read, Write, Edit, Glob, Grep, WebFetch, WebSearch] — no Artifact. A routine created through the MCP create_trigger path instead stores config: {} with no tool list at all, so the restriction appears to follow the creation surface.

There is no user-facing workaround: routines expose neither a permission-mode picker nor a tool picker; project permissions.allow doesn't gate Artifact (tested); permissions.defaultMode: auto is documented not to take effect from project or local settings; and environments have no permission-mode variable, with setup scripts skipped whenever a cached environment exists.

Why it matters: the shipped /morning skill's own description offers to "set it up as a recurring weekday task", and its output is an artifact. So a first-party skill's advertised scheduled use case can't work on cloud routines.

Expected: either routines include Artifact in their tool set, or a run fails loudly instead of parking indefinitely on a prompt no one can answer.

Possibly related: #88731 (Artifact tool absent in sdk-cli entrypoint sessions), #61196 (closed; the MCP-connector analog on remote routines).

View original on GitHub ↗