When no person is present, an MCP tool approval either stalls the run, was granted earlier, or never existed. Anthropic's Desktop tasks stall on tools that need approval, and tools marked as requiring user interaction prompt on every call. Cloud routines call included connector tools without asking. Decide per tool, ahead of time.
What an approval means in an unattended run
In an interactive session, an approval prompt is a moment of human judgment. In a scheduled run, there are only three possibilities.
- The run stalls. Anthropic's Desktop page says that if a task in Manual mode needs a tool it has no permission for, the run stalls until you approve, and the session stays open in the sidebar. Nothing happens until someone looks.
- A prior approval applies. If you chose always allow while watching a test run, later runs use that tool without asking. You can review and revoke those approvals on the task's detail page. Allow rules from the user's settings file also apply.
- No approval layer exists. The routines page says cloud routines have no permission mode picker and call included connector tools, including writes, without asking.
OpenAI's page describes a fourth pattern: in sandboxed unattended runs, a call that needs access beyond the sandbox fails.
Tools that always ask
The Desktop page states that MCP tools marked as requiring user interaction prompt on every call, with no always-allow option, so runs that call them stall each time. Tool authors can use this for sensitive actions such as sending money, deleting data or posting externally. If you build or choose MCP servers for scheduled use, ask which tools carry that mark, and keep them out of any task that must finish unattended.
A tool by tool plan
| Tool type | Example | Unattended policy |
|---|---|---|
| Read, narrow scope | Read one project's issues | Allow |
| Read, broad scope | Search all mail | Allow only with a documented reason |
| Write, reversible | Add a label or comment | Allow with a log and a review |
| Write, external or visible | Post to a shared channel | Draft for a human, or allow to one test channel |
| Destructive | Delete, merge, publish | Do not allow unattended |
| Money, access or identity changes | Anything touching payments or permissions | Never unattended |
Classifying tools by read, write, delete and send expands on this table.
Add a layer that does not depend on the model
A model's judgment is not a control. Put a check between the assistant and the tool. A guardrail at the MCP layer can evaluate each call against rules before it runs: which tool, which arguments, which destination, how often. That makes a rule such as "this task may post only to one channel" something that is enforced, not requested. Safeguard's MCP Guardrail is a GA capability for this kind of control. It is one layer: scoping the connector and the grant at the source service still matters.
Worked example: a triage task with a guardrail
A task reads support tickets through one MCP server and comments on a tracker through another. The team writes rules in the guardrail layer: the ticket server is read only; the tracker server allows comments, not status changes or deletes; comments are limited to the triage project; no more than ten comments per run. During a test, a ticket contains planted text asking the assistant to close several issues. The assistant tries a close call. The guardrail denies it and logs the attempt. The run completes with comments only, and the log gives the owner something to review.
Approval fatigue and stale approvals
Approvals decay. A prompt you answered three months ago, with a task that has since gained new instructions, may now cover actions you never meant to allow. Anthropic's Desktop page lets you review and revoke saved approvals per task, so put that review on the same monthly cycle as the register. When you edit a task's prompt or add a connector, clear its saved approvals and rebuild them while watching a run.
Also beware of approving too broadly under time pressure. If a task stalls at 08:00 and a manager is waiting, the temptation is to allow whatever it asked for. Create a short list ahead of time of tools that may be approved on the spot and tools that need the owner. Keeping approvals meaningful covers the human side of this problem.
Finally, remember that an approval granted to a tool is an approval for every use of it that the model decides to make. A tool that can read all mail, approved once, can read all mail forever. Prefer narrow tools and narrow grants over a broad tool with a careful prompt.
Testing approvals before go live
- List every tool the task can reach, using the connector's tool list.
- Run the task manually and watch each call.
- Remove tools it never needs.
- Try a hostile input in a test environment and see which calls are attempted.
- Confirm that denied calls fail visibly and are logged.
- Review saved approvals monthly.
See giving an agent read only access through MCP for a worked setup.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a tool call is checked against a rule, and try to think of the rules your own scheduled tasks would need.
Quick check
What happens when a Desktop task in Manual mode needs an unapproved tool?
The run stalls until someone approves it. The session stays open in the sidebar, per Anthropic's Desktop documentation.
Can I make a tool always ask, even in scheduled runs?
For MCP tools marked as requiring user interaction, yes. They prompt on every call and offer no always-allow option, so unattended runs that call them stall.
Is a guardrail a replacement for scoping the connector?
No. Use both. Scope the grant at the source and enforce rules on calls as a second layer.
Sources
- Schedule recurring tasks in Claude Code Desktop
- Automate work with routines (Claude Code docs)
- Scheduled tasks and automations (OpenAI docs)
Last reviewed: 19 October 2026.
