Say hello
Menu
All notes
NoteHatim Rih

Scheduled tasks in the Claude desktop app stop at a production deploy

Claude CodeAutomationDeployment

Schedule the job up to the commit and leave the deploy to a person. A scheduled task in the Claude desktop app runs with nobody watching, and a production deploy wants someone there: in Auto mode the permission classifier blocks it, and in Manual mode the run waits at the prompt. Mine ran in Auto mode and stopped on 3 November at 08:05, one step short of publishing three pages on hrih.si, with the reason “Production Deploy”.

What the job did

ai-tells-publish was a one-time task, and its prompt held the whole release:

  1. Check the tree: main level with origin, the shared files holding only this work’s changes, nobody else’s edits.
  2. Switch the three pages from draft to published, draw their social cards, run the tests and the type check.
  3. Commit the listed files and push to main.
  4. Run bash deploy/deploy.sh.
  5. Check the live pages, write the journal, send me a notice.

Steps 1 to 3 passed: 70 tests, no type errors, commit 2139922 pushed. Step 4 was blocked. The job stopped there and didn’t look for another way round, as its prompt said to do whenever a step failed.

Why the deploy was blocked

Each scheduled task runs in the permission mode saved with it, and this one was saved in Auto mode. In Auto mode, reads and edits in the project go ahead, and every other action passes a classifier first. Production deploys are on its default block list as a soft block, which you can lift by asking for the deploy in the conversation, or with an autoMode.allow rule in your user settings.

The task’s prompt told it to deploy and quoted my approval, and the deploy was blocked anyway. Later that morning, the same command was blocked the same way in a session I was in, until I wrote “Yes, deploy it” there.

An allow rule or Bypass mode would let the job through. For a job that ships to production with nobody watching, that removes the one check I want to keep.

The state it left behind

The worse problem was main. The commit had already switched the three pages to published, so the next deploy from any session would have shipped them, checked or not. The release went out at 08:18, from a session I was in, after the pages were checked again.

The pattern that works

  • Schedule everything up to the commit: the checks, the tests, the cards, the commit itself.
  • Push to a branch, not main, when the deploy may not follow, so main never holds work that hasn’t shipped.
  • End with a notice that carries the one command to run. With ntfy:
curl -fsS -H "Title: hrih.si: release ready" \
  -d "Checks passed, pushed to <branch>. Merge it, then run: bash deploy/deploy.sh" \
  "https://ntfy.sh/$NTFY_TOPIC"

The deploy is then one command in a session where you’re there to say yes.