What you’ll know by the end of this check

The four things that control what a routine can access
Why “connectors included by default” is a trap
How branch-push permissions protect you from routine runaways

The shortest possible answer

A routine’s reach is determined by four scoping surfaces. Tighten each one:

Repositories you select (and their branch-push setting)
Environment network access, env vars, setup scripts
Connectors you include (MCP servers like Slack, Linear, Google Drive)
The prompt itself — whatever it says to do

No permission prompts appear mid-run. What you configured is what runs, unsupervised, in the cloud.

Repositories: the blast radius

Each repo you add is cloned fresh on every run. Claude starts on the default branch unless your prompt says otherwise.

Branch push safety (on by default): Claude can only push to branches prefixed claude/. This stops a routine from accidentally modifying main, long-lived feature branches, or any protected branch. You have to explicitly toggle Allow unrestricted branch pushes per repo to relax this.

Default-deny here is a feature. Leave it on unless you have a specific reason to allow writes elsewhere — and if you do, narrow the routine to what actually needs unrestricted access.

Connectors: the default-everything problem

When you create a routine, every connector you have attached gets included by default. Slack, Drive, Linear, Jira, GitHub — whatever’s on your account.

That sounds convenient. It isn’t. Every connector you leave attached is a capability the routine can exercise without warning. A routine that’s supposed to triage issues shouldn’t also have the ability to write to your Drive or send Slack DMs.

Rule: after creating a routine, open it and remove every connector except the ones it actually uses. Tighten after scaffolding.

Outside the routine form, manage connectors at Settings → Connectors on claude.ai, or use /schedule update from the CLI.

Environments: network and secrets

Each routine runs in a cloud environment that controls:

Network access — which hosts the routine can reach
Environment variables — secrets, API keys, config
Setup scripts — dependencies to install, tools to configure

Configure environments before creating the routine so Claude has what it needs on first run. Tight environments are faster to start and safer to leave unsupervised.

See cloud environment docs for the full setup guide.

The identity problem

Anything the routine does through your GitHub identity or connectors appears as you. Commits come from your username. PRs are authored by you. Slack messages come from your account. Linear tickets are yours.

Two implications:

Audit trails point at you. If a routine ships a bad PR, your teammates see your name on it. Be ready to own the output.
The routine inherits your permissions. If your account can deploy to prod, the routine can too. If it can approve its own PRs, it can approve its own PRs. Most orgs don’t want that. Check your team settings before you wire cross-system automations.

Routines belong to you, not your team

A routine is scoped to your individual claude.ai account. It is not shared with teammates, and it counts against your daily run allowance. If a teammate should also run the routine, they create their own copy with their own connectors.

This will change as the product matures. For now, plan on one-person ownership per routine.

Things to try right now (10 minutes)

Open your test routine from check 02 in the web UI.
Look at the connectors list. How many are attached? Probably more than you need.
Remove every connector that isn’t directly used by the routine’s prompt. Save.
Check the repo settings. Is unrestricted branch pushes on? If so, turn it off unless the routine needs it.

The canonical version

Full official docs: code.claude.com/docs/en/routines.

Ready to verify this check?

Your test routine has only the connectors it needs. Branch-push is restricted to claude/* by default. You know whose identity the routine runs as. Mark it cleared.