A scheduled AI task misbehaved: what do you do in the first hour?

Pause the task first, then cut its access, then preserve evidence. Do not delete it yet. Use the first hour to find what it touched, decide who must be told, and rotate anything it could read. Investigation can follow once nothing else can happen.

Minutes 0 to 10: stop it

1. Pause the schedule. Products offer a pause: the on and off switch on a routine, the Paused status for a Desktop task, and the Scheduled sidebar for Cowork. Pause keeps the configuration and history, which you need.
2. Check for other triggers. A routine can have schedule, API and GitHub triggers at once. Pausing the schedule may not stop an API call or an event. The routines page says deleting a token turns off API access.
3. Check other copies. Look for the same task under other accounts and in repository workflows.
4. Stop a session loop. Press Esc to clear a pending self paced loop, or ask the session to cancel tasks. Disabling the scheduler entirely is possible with CLAUDE_CODE_DISABLE_CRON.

Minutes 10 to 25: cut access

• Revoke or rotate the API trigger token.
• Remove connector grants at the source service.
• Reduce repository access or disable the connected identity if it is compromised.
• Change secrets the task could read, including environment variables.

Order matters. Revoke the credentials that allow harm before you study the cause. See the AI agent kill switch.

Minutes 25 to 45: preserve and scope

1. Export or capture run history and transcripts before any retention window removes them. Do not rely on the status indicator, which only says whether a session started.
2. Note the prompt version, connectors, repositories and permission mode at the time.
3. List actions taken: branches, pull requests, messages, tickets, files, emails.
4. Check downstream audit logs in each affected service. Do not rely on the task's own report. See reconstructing what an agent did from its logs.

Minutes 45 to 60: decide and communicate

• Cause guess. Prompt change, model change, prompt injection through input, a connector change, or a plain bug.
• Impact. Was any data sent outside? Was production changed? Were customers affected?
• Who to tell. Task owner and sponsor, security, and the owners of touched systems. Involve legal and privacy leads if personal data may have been exposed, since notification duties depend on facts and jurisdiction.
• Recovery. Revert changes, close duplicates, correct messages.

After the first hour

Keep the task paused until you understand the cause. When you restore it, narrow its access, add an action budget, and write down what changed. Add a tabletop based on this event to your exercises, using AI agent incident tabletop scenarios.

Worked example: unexpected messages at 03:40

At 03:40 an on call engineer sees five messages in a customer facing support channel that read like internal triage notes. They were posted by a colleague's account. The colleague is asleep. The engineer suspects a scheduled task.

Minute 0 to 5: the engineer opens the colleague's routines list and finds a nightly triage routine with a schedule trigger and a chat connector. She uses the on off switch to pause it. She notes the time. She checks whether the routine also has an API or event trigger, and finds an API token. She asks the platform admin, awake in another time zone, to delete the token.

Minute 5 to 20: the admin deletes the token and revokes the chat connector grant at the chat service. The engineer deletes the five messages after capturing them as screenshots with timestamps. She posts a short holding note in the channel.

Minute 20 to 40: they open the last three runs. The transcript of the 03:30 run shows the task read a support ticket whose body included text addressed to the assistant, and then posted a summary to the wrong channel. The channel it chose was one the chat connector could reach because the grant was workspace wide. They save the transcripts and the ticket text.

Minute 40 to 60: they list what else the routine did: two ticket comments and one label change, all reversible. They revert them. They record the timeline, tell the colleague's manager and the security lead, and decide to restore the routine only after narrowing the chat grant to one internal channel and removing all write tools except one comment tool.

Roles worth assigning in advance

One person can hold several roles in a small team. Name them anyway.

Evidence capture list

1. Screenshots or exports of run history with times.
2. The full transcripts of runs around the incident.
3. The task's configuration: prompt, schedule, connectors, repositories, mode.
4. Downstream audit logs from the systems it touched.
5. The input that triggered the behavior, if identifiable.
6. A timeline with who did what and when.

What to avoid

Do not edit the task before capturing it. Do not rerun it to see what happens in production. Do not rely on the task's own account. Do not delete messages without capturing them first. Do not announce a root cause before you have checked.

Preparing before it happens

Write the playbook now, test the pause and revoke steps on a harmless task, and make sure at least two people know where each product's controls live. A tabletop that walks through this scenario takes thirty minutes and shows gaps in access, not just in documentation.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how an assistant's actions are scoped and recorded, and ask what record you would want to hold after an incident.

Quick check

Sources

• Automate work with routines (Claude Code docs)
• Schedule recurring tasks in Claude Code Desktop
• Run prompts on a schedule (Claude Code docs)
• Schedule recurring tasks in Claude Cowork (Help Center)

Last reviewed: 19 October 2026.