anthropics / anthropics/claude-code
[BUG] Title: Routine-driven ArtifactData writes trigger per-write consent dialogs, contradicting documented "no approval prompts during a run" behavior
- Dominant language
- Python
- Stars
- 145k
- Forks
- 23.1k
- PR merge metrics
- PR metrics pending
Description
### Preflight Checklist
- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
### What's Wrong?
An hourly Claude Code Remote Routine (scheduled trigger bound to a persistent session) writes to a published Artifact's shared database via the ArtifactData tool (batch/set/update/delete against a db capability collection). Every single write from this automated routine triggers a client-side "Allow Claude to edit this artifact's data?" consent dialog in the artifact owner's browser — requiring a manual click to Allow — even though the routine runs unattended on an hourly cron and the owner is frequently not present to approve it.
Expected behavior (per docs):
The Claude Code Routines documentation states routines "run autonomously as full Claude Code cloud sessions: there is no permission-mode picker and no approval prompts during a run," and that included connectors can write "without asking for permission during a run."
Actual behavior:
Every ArtifactData write issued by the routine's session surfaces a browser-side consent dialog to the artifact owner.
If the owner isn't present/reachable to click Allow, the write fails outright with an error like: this write reads back the stored document (a str_replace, or a write pinned with if_version) and has no approval record in this session — nothing was written; retry so it is checked again. There's no queuing behavior — it's an immediate failure, requiring the calling session to retry.
The dialog's own text implies the approval "covers the rest of the session," but in practice it recurs on subsequent writes from the same persistent session, sometimes within the same hour and sometimes after having been approved earlier that same day.
The consent payload uses an internal shape distinct from the documented ArtifactData tool contract — {action: "write_db", db_op: "batch", writes: [...]} — and includes a field __artifactConsentAskCanReachUser: true.
Impact:
This defeats the purpose of an hourly unattended routine that writes dashboard/status data to a shared artifact — a core supported use case. The routine's writes only succeed when the human owner happens to be at their browser to click Allow at the moment of the write, which for an hourly cron firing throughout the day means near-constant manual intervention.
Environment:
Trigger type: scheduled cron Routine (7 * * * *), bound to a persistent session
Tool: ArtifactData, action batch (also reproduces on set/update/delete)
Target: a published Artifact with db capability declared
### What Should Happen?
Either (a) honor the documented "no approval prompts during a run" guarantee for ArtifactData/artifact-db writes originating from a Routine-bound session the same way it applies to other connector writes, or (b) if per-write consent is intentional for artifact-database writes specifically, update the docs to say so explicitly and give routine owners a way to grant standing write consent (e.g., at artifact-sharing level) instead of a per-write dialog that doesn't actually persist as advertised.
### Error Messages/Logs
```shell
```
### Steps to Reproduce
Publish an Artifact with the db capability declared (capabilities: {db: {}}).
Create a scheduled Routine (Claude Code Remote trigger) on a recurring cron schedule (e.g. hourly), bound to a persistent session.
Give the routine a prompt that has it call the ArtifactData tool against that artifact's database — e.g. action: "batch" with a mix of set/update/delete writes to a collection.
Let the routine fire on its schedule without the artifact owner having the artifact page open in a browser at that moment.
Observe: the ArtifactData call does not complete. It returns an error along the lines of "this write reads back the stored document ... and has no approval record in this session — nothing was written; retry so it is checked again."
Have the artifact owner open the artifact in a browser. A dialog appears: "Allow Claude to edit this artifact's data?" Click Allow.
Retry the same tool call — it now succeeds.
Wait for the routine's next scheduled firing (or issue another ArtifactData write later in the same persistent session) without the owner re-opening the artifact tab.
Observe: the same consent dialog is required again, despite its own text implying the approval covers "the rest of the session" — the approval does not persist across the routine's subsequent firings, even though it's the same persistent session each time.
### Claude Model
None
### Is this a regression?
I don't know
### Last Working Version
_No response_
### Claude Code Version
Claude Code version 2.1.270
### Platform
Anthropic API
### Operating System
macOS
### Terminal/Shell
Terminal.app (macOS)
### Additional Information
_No response_
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the scheduled Routine using ArtifactData batch writes against a published artifact with a db capability, then trace where the client-side consent is requested and recorded. Compare the documented no-prompt behavior with the repeated approval flow and its session payload. Done means routine-bound writes no longer require repeated owner dialogs, or the documentation and standing-consent behavior explicitly match the intended policy.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, authorization, databases
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100