Claude Automations

From tool to system

Most intermediate Claude users run everything manually: open a session, paste context, ask a question, close. This works. But there's a level of productivity above it that manual operation can't reach — one where Claude does defined work on a schedule, fires when something happens, or runs as a step in a pipeline you set up once and don't touch again.

Getting there requires two things: understanding how Claude Code's hook system works, and knowing how to invoke Claude non-interactively from the command line. Neither is advanced. Together they open a different category of use.

Injecting persistent behavior into every session

Claude Code supports a hooks system configured in settings.json. Hooks are shell commands that fire at defined lifecycle points: PreToolUse (before Claude runs a tool), PostToolUse (after), Stop (when Claude finishes responding), and Notification (when Claude sends a status event). You can also target specific tools — fire only when Claude is about to run a bash command, for example, or only when it edits a file.

What hooks are useful for: logging every Claude action to a file, running a linter after every code edit, posting a summary to a channel when Claude stops, enforcing guardrails before a destructive tool runs, or updating a status file that another process monitors. None of these require you to remember to prompt for them — they happen automatically in every session once configured.

The hooks configuration lives in .claude/settings.json at the project level, or in ~/.claude/settings.json for user-wide behavior. The format is straightforward: an array of hook definitions, each with a type, an optional matcher (which tool to target), and a command to run.

Claude from the command line, without you in the loop

Claude Code can be called as a CLI tool with a prompt argument. The flag is --print (or -p) for non-interactive mode — Claude reads the prompt, runs, prints output, and exits without waiting for a conversation. Combine this with input piping to feed it a file, and you have a building block for real automations.

Once you can call Claude from a shell command, you can call it from anything that can run a shell command: cron on Linux/macOS, Task Scheduler on Windows, a git pre-push hook, a GitHub Actions workflow step, a file watcher triggered by a directory change, or a webhook handler in a simple web server. The pattern is: event fires, shell command runs, Claude gets a prompt and some context, output gets written somewhere useful.

Long-running Claude work you don't wait for

Some Claude tasks are slow enough that you don't want to wait for them interactively. Generating a full draft from notes, auditing a codebase for a specific pattern, processing a batch of documents — these are candidates for background execution. Claude Code supports a --dangerously-skip-permissions flag for fully automated runs where no human approval step is possible; understanding when and whether to use it is part of building responsible automations.

The practical pattern for background Claude tasks: invoke with nohup or as a detached process, redirect stdout to a log file, and write a completion signal (a sentinel file, a database update, a webhook call) when Claude finishes. Another process or a simple monitoring loop can watch for the signal and act on the output.

What breaks, and how to catch it before it does

Automated Claude runs have a different failure mode than interactive sessions. When something goes wrong interactively, you see it immediately. When something goes wrong in a background cron job, you find out when the downstream effect shows up — a missing summary, a corrupt file, an empty output that got logged as success. The discipline for reliable Claude automations is: always write to a log, always check exit codes, and always define what a successful run looks like before you ship the automation.

Patriola's Guide to Claude: Automations covers the full automations system: hook patterns by use case, the non-interactive CLI in depth, scheduling on Windows and Linux, and the monitoring patterns that make background Claude work trustworthy.

More on this

Two automated pipelines built on these patterns: Autonomous Morning Reports and Overnight Brainstorming. For running several Claude instances as a coordinated team rather than one scheduled job, see Claude Multi-Agent Systems. For the specific hook mechanics behind these automations, see Claude Code Hooks.