Approval-free recurring automation

Design for zero run-time approvals

Treat every recurring job as detached from the start. A scheduled run happens with nobody watching, so anything that needs the user to tap approve will stall or die.
Prefer channels that carry their own authorization. A signed webhook, a one-time stored token or a pre-authorized API route lets the job finish without a human in the loop.
Give the job the smallest credential that still works. A fine-grained token scoped to one repo or one endpoint fails safer than a broad account login, and it survives longer.
Set the approval count before you schedule. Tell the user the job runs on its own from now on, and get the single setup approval up front instead of one per run.

Never add an approval step the user did not ask for and policy does not require. An invented gate trades a finished job for a waiting one.
When the user has opted out of per-action approvals, honor it in the design. One standing authorization or a no-approval channel is the correct shape, not a promise to ask each time.
Keep approvals for real boundaries. Sending money, messaging other people from the user's accounts, deleting data and changing credentials are the usual ones. Everything else should run.

Read the failure before you retry. A run cancelled on approval_wait_superseded or a worker that reports the work is not finished is a design failure, not a transient one, so another attempt on the same channel will fail the same way.
Change the channel, not the schedule. Move the delivery to a signed webhook or a pre-authorized path, then keep the cadence the user already approved.
Retire the failing channel in the same change. Disable the old job when you create its replacement so two jobs do not fight over the same task.
Confirm the replacement actually ran. Check the run's own result and the real end state, such as the live URL or the remote ref, before you call it fixed.

Use muse.connector_search to find other connectors and muse.skill_search to find related skills.
If nothing here fits, look on the web for a maintained API or MCP server and set it up with Custom Connectors and MCPs, or build a custom connector.

Prefer a pull over a push where the target can poll. A device that fetches its own data on a timer needs no credential on your side at all.
Batch the work the job does. One run that writes a complete snapshot fails less often than many runs racing over partial updates.