A job that had stopped while its Claude Code scheduled task's status was succeeded

Summary

I ran the data update job for a site that lists my research and development achievements as a scheduled task in the desktop version of Claude Code for 31 days. It ran 28 times, and of the 19 runs recorded as succeeded in the run history, the job had stopped partway in 5. I found these 5 by putting the status side by side with the data commits.

The permission mode is the setting that decides whether a confirmation is shown before a command runs. Only the 2 runs on the day of registration had this mode set to default, and every run started at the scheduled time was auto. In auto, a background classifier judges each command before it runs. So the reason the scheduled runs did not stop at a confirmation cannot be explained by the list of commands allowed without confirmation alone.

The first run ran in default mode, and an interruption was recorded after the first Bash call, yet its status was succeeded. What status a run would get if it waited at a confirmation without being interrupted cannot be told from the records of the 28 runs. Who interrupted the run, and the cause of the 4 days with no run, have not been confirmed.

What you can take away

A developer who runs jobs with scheduled tasks can take away the following 4 things from this article.

• By putting the status in the run history side by side with what the job produces, you can find job stops that do not appear in the status.
• You can gather the commands a scheduled task runs into one script, and write the steps, the conditions for stopping, and the exit codes there.
• Before checking the effect of the allow list, you can confirm, with permissionMode, which mode the run ran in.
• When you design notifications, you can check the 3 cases in which a notification written inside the job did not arrive.

This article is based on the commit history, code, run history, and session records of one job, and on official documentation.