Sometimes, and it depends on the product. A cloud routine in Claude Code runs without approval prompts. A Claude Code Desktop task uses a permission mode you set per task, and stalls if it needs approval. Codex style automations run unattended inside a sandbox and fail when they need more access.
Why this question matters
An interactive session has a person at the keyboard. A scheduled run does not. Whatever a prompt dialog would have caught in daylight is now decided by the settings you chose when you created the task. That makes the creation form the real security review, so it deserves the same care as a pull request that grants access.
What the vendor documentation says
The behaviors below come from the vendors' own pages, read on 19 October 2026. Several of these features are labeled research preview or are changing quickly, so recheck before you rely on them.
| Where the task runs | What happens when an action needs approval |
|---|---|
| Claude Code cloud routine | No permission mode picker. The run executes shell commands and calls included connectors without stopping for approval. |
| Claude Code Desktop local task | Each task has its own permission mode. In Manual mode a run stalls until someone approves, and the session stays open in the sidebar. |
| Claude Code session loop | Inherits permissions from the open session. |
| Codex style automation | Runs unattended under the default sandbox. Read-only and workspace-write calls that need more access fail rather than ask. |
The routines page also says that the saved prompt is treated as the assigned task, not as live user input, so it cannot act as approval or consent for actions during the run. In other words, nobody is implicitly approving anything.
Fail closed or fail open
Two designs exist for unattended work. One stalls or fails when it needs something new, which is annoying and safe. The other grants broad access up front and never asks, which is quiet and risky. Cloud routines sit closer to the second design, so the controls move to what you hand them: repositories, environment network access, and connectors.
The Claude Code Desktop page also describes a trap worth knowing. If you click "always allow" while watching the first test run, future runs auto-approve the same tools. Those approvals can be reviewed and revoked on the task detail page, so put that review on a calendar.
A practical setup order
- Write the task as a read-only job first. Summaries and reports need far less access than fixes.
- Run it manually once and watch every prompt. Approve only what the task needs.
- Remove connectors and repositories the task does not use.
- Set the narrowest sandbox that lets it succeed. Widen only after reading a few runs.
- Record who owns the task and when its approvals were last reviewed.
OWASP describes the underlying hazard as excessive agency, with three root causes: too much functionality, too many permissions, and too much autonomy. A scheduled task with no prompts and a long connector list hits all three at once. See the Cowork permission modes comparison for how one product handles the trade.
Worked example: a nightly pull request summary
Suppose a developer wants a task that reads yesterday's merged pull requests and posts a summary to a team channel. Here is how the same job looks in each setup, using only behavior the vendor pages describe.
As a cloud routine, the creation form lists repositories, an environment and connectors. Every connector on the account is included by default, and the run can use any of their tools without asking. The developer removes everything except the code host and the chat connector. The summary will post to chat on its own, because nothing pauses the run. If the chat connector also allows deleting messages or reading private channels, the run can do that too, so the developer checks what scope that connector was authorized with.
As a Desktop task in Manual mode, the first run pauses the moment it needs a tool it has not been approved for. The developer watches that first run, approves the code read and the chat post, and chooses always allow for each. Later runs will use those approvals silently. The task detail page lists them, which turns into a review item: on the first of the month, open the Always allowed panel and revoke anything the task no longer needs.
As a sandboxed automation, the job reads from the project folder and then needs the network to post to chat. Under a workspace-write sandbox the network call fails unless it has been allowed, so the run fails closed. The developer decides whether to allow that one destination or have the task write a file that a separate, narrower step posts.
What to decide at creation time
| Decision | Safer choice | Riskier choice |
|---|---|---|
| Where it runs | A place where unapproved actions fail or wait | A place with no prompts and broad connectors |
| Connectors | Only those the job names | Everything on the account |
| Output | Draft, comment or summary for a person | Direct send, delete or merge |
| Approvals | Reviewed on a calendar | Granted once and forgotten |
| Network | An allowlist of named hosts | Full access |
Questions to ask before saving any task
- If this prompt ran a thousand times with no human reading the output, what is the worst thing it could do with the tools I included?
- Which of those tools can write, send or delete, and does this job truly need them?
- If an input contained hostile instructions, would anything stop the task from following them? See prompt injection and scheduled tasks.
- Who will read the first five runs, and by when?
- How will I know if it silently stops?
Write the answers into the task description. A task that cannot explain itself in a few sentences is not ready to run unattended.
Common mistakes
Treating the first manual run as proof. A first run happens while you watch, with fresh context, on a good day. Unattended runs meet empty inputs, rate limits, changed permissions and odd data. Another mistake is confusing "approval mode" with "access". A Manual mode task that has been granted always allow on a broad tool is effectively unattended. Finally, many people assume the vendor handles safety. The routines documentation puts scoping repositories, environments and connectors in your hands, and says the session runs commands and calls connectors without stopping for approval.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the setup and note which tools a connection exposes, since those are what an unattended run can use.
Where Safeguard fits
Safeguard offers policies, gates and guardrails, an MCP Guardrail and agent identity, which are the kinds of controls that sit between an unattended agent and the systems it touches. You can also run the free scan at https://gold.safeguard.sh/scan on a repository a scheduled task works in.
Quick check
Does a green run status mean the task did the right thing?
No. The routines page says green means the session started and exited without an infrastructure error. Open the transcript to see what happened.
Can I make a cloud routine ask before acting?
The routines page says there is no permission mode picker, so the practical controls are scoping repositories, connectors and the environment, plus branch protection on GitHub.
Is Manual mode on a Desktop task the same as no access?
No. Manual mode asks the first time, but choosing always allow lets later runs use that tool without asking. Review the saved approvals on the task detail page.
Sources
- Automate work with routines (Claude Code docs)
- Schedule recurring tasks in Claude Code Desktop
- Run prompts on a schedule (Claude Code docs)
- Scheduled tasks and automations (OpenAI Codex docs)
- OWASP LLM06 Excessive Agency
Last reviewed: 19 October 2026.
