A Claude Code skill updater failed three straight Sundays while its audit note still read "exit 0"

The timestamps say more than the error message does. The plist fires at 4:40 ^[1]. The 6 September failure was logged at 04:40:38 and the 20 September one at 04:41:35 ^[10]. If those runs started on schedule, they failed about 38 and 95 seconds in ^[1]. The cap is 600 seconds ^[4]. On those two Sundays the timeout cannot have fired. Both runs also ended sooner than the 4-minute run the August audit measured ^[1].

The 13 September entry is different. It landed at 05:27:06, 47 minutes after the scheduled start and longer than the whole 10-minute cap ^[2]. That run either began late or spent its time outside the capped command ^[2].

Between the failure lines, stderr caught npx reporting that [email protected], and later [email protected], "was not found and will be installed" ^[12]. The author attributes those lines to npx's own bootstrap ^[12]. Because the script asks for `skills@latest`, a new CLI release means a package download before any update work starts. In the script, that download runs inside the same `gtimeout 600` budget as the update itself ^[4]. The logs quoted in the post do not by themselves establish a root cause.

According to the code comments the developer published on dev.to, this is the third stretch of failure on record ^[3]. A 2026-06-11 audit found that the old script touched STAMP even when the update failed, so updates kept failing silently whenever the network misbehaved ^[6]. Later, a 45-second timeout expired on every run as skills piled up. It produced a 5,833-line failure log and not one successful update ^[5]. The 2026-08-08 audit then measured a clean 4m00s run ^[7].

The STAMP change was good engineering. Touching the success marker only on success, and writing the failure reason to skills-update.err, is why September left any trace at all ^{[6] [8]}. launchd, for its part, never missed a Sunday ^[8].

The 600-second cap was set against one measurement. The audited run on 8 August used 240 of its 600 seconds, or 40% ^[4]. The author wrote that runs stalled more often as the skill count grew ^[13].

The author drew the lesson from the comments themselves. "But those are only facts verified at that point in time. They don't prove the job keeps working afterward," the author wrote ^[14]. The script already produces the signal a check would need: STAMP's modification time is the time of the last successful update ^[6].