Claude Code automation: hooks, scripts, and safe controls

What Claude Code automation actually is

Claude Code can read files, edit code, run commands, and use configured tools. Automation lets those actions happen from a defined trigger or script instead of a live interactive conversation.

The practical question is not “Can Claude Code automate this?” It is “Where should this work run, and what should prevent a bad change?”

1. Use hooks for rules that must run

Hooks are user-defined handlers that run at specific points in Claude Code’s lifecycle. The hooks guide describes command, HTTP, MCP-tool, prompt, and agent hooks. Command hooks are the right default for a deterministic rule: run a formatter after an edit, check a generated file, or block a protected path before a tool call.

Put hooks in a settings file with the scope you intend: .claude/settings.json for a shared project rule, .claude/settings.local.json for one developer, or managed settings for an organization. A PostToolUse hook is useful for validation or formatting, but it runs after an edit and cannot undo it. A PreToolUse hook can deny an edit before it happens.

Do not copy a generic path-matching shell snippet into a production guard. Hook input paths may be absolute or relative, the process working directory may not be the repository root, and a loose glob can miss a protected file or format unrelated files. Build a small repository-specific handler, test it with mocked absolute and relative paths plus a command failure, and have the project owner review it. The hooks reference documents the JSON input and the permissionDecision: "deny" response shape for a PreToolUse block.

Use a deterministic hook for a rule you have tested, not as a substitute for understanding the paths and command it will run.

Run /hooks after configuration. It shows the event, source file, hook type, and command. That makes the automation inspectable for the next developer instead of hiding it in a shell profile.

2. Use claude -p for a script or CI job

claude -p runs Claude Code non-interactively. It is useful when a script has a specific job and can pass the required context. Anthropic documents --output-format for a machine-readable result envelope, --tools to define which tools are available, and --allowedTools to auto-approve tools. --allowedTools is not a read-only restriction.

For repeatable automation, start in bare mode. Bare mode does not read OAuth credentials or the system keychain, so a subscription login is not enough for this command. Provide ANTHROPIC_API_KEY or an apiKeyHelper in the settings JSON; Bedrock, Vertex, and Foundry use their normal provider credentials.

set -o pipefail
git diff --no-ext-diff --no-textconv APPROVED_BASE_REF...HEAD | \
claude --bare -p "Review only the supplied diff for missing test coverage. Explain each proposed check and state what cannot be determined without other files. Do not claim you ran tests." \
  --tools "" \
  --disallowedTools "mcp__*" \
  --output-format json

Bare mode skips automatic discovery of CLAUDE.md, hooks, skills, plugins, MCP servers, and memory. That avoids a CI run changing because one developer has local configuration. It also means the run does not inherit your project instructions. --output-format json does not validate a schema for the response, so a script must validate fields before it acts on them. If the task needs conventions or a connector, pass them explicitly with the documented flags instead of assuming they are present.

This Bash example sends an operator-selected diff to the model, with built-in and MCP tools disabled. Replace APPROVED_BASE_REF with the reviewed base reference that exists locally, check the diff for sensitive content, and approve the API usage before running it. The model cannot inspect other files or run the proposed tests in this configuration. Check the pipeline's exit status and returned result; do not treat an empty or failed diff as a successful review. A job that later edits files or changes a cloud system needs separate access, tests, and authorization.

3. Match scheduling to where the work must live

Claude Code has several ways to run work later. The scheduling guide makes the trade-off clear:

• Routines run in Anthropic-managed infrastructure or an organization’s self-hosted environment. They can use schedules, API calls, or GitHub events and continue while a laptop is closed. They are research preview.
• Desktop scheduled tasks run on a machine and can use its local files and tools. The machine must be available.
• GitHub Actions run in your CI pipeline and fit repository events and workflow files.
• /loop is for short polling in the current session. It is not a durable scheduler.

Choose the location before you write the prompt. A nightly check that needs uncommitted local changes is not a cloud routine. A PR review that must leave its result with the pull request belongs in the repository workflow, with the repository’s own permissions and review rules.

Routines do not pause for permission prompts during a run. Their connected MCP connectors can read from and write to external services, and all currently connected connectors are included by default when a routine is created. Remove every connector the routine does not need, scope repository and environment access, and check its network policy before enabling it. Put human review after the run in a pull request or a held external action, not in a runtime prompt that will never appear.

4. Give automation a test, not a vague goal

“Review the code” is too loose for an unattended task. A useful automation prompt says what to inspect, what counts as a problem, what the output should contain, and what to do when it is unsure.

Here is a bounded pull-request review design:

1. Trigger on an opened or updated pull request.
2. Read only the diff and the project’s stated test command.
3. Report a finding only when it points to a changed line and explains the failing behavior.
4. Do not merge, deploy, change secrets, or alter repository settings.
5. A human decides whether a finding becomes a fix.

This is more useful than asking an agent to “improve quality.” It produces reviewable evidence and keeps the irreversible step with the person who owns it.

5. Hooks, permissions, and agent hooks solve different problems

These controls are easy to mix up:

Anthropic labels agent hooks experimental and recommends command hooks for production workflows. That is a sensible default. A model can help decide whether a change looks complete; it should not become the only lock on a release, secret, or customer-facing action.

A concrete automation to start with

Start with an automation that reviews an approved input without tools to edit the repository or contact customers, like the diff review above. The API still receives the supplied content and incurs usage. Add a formatter or protected-file block only after its repository-specific handler has been tested.

Then test three cases before sharing it with the team:

1. A supplied diff with a missing edge-case test: the review identifies the relevant change and proposes a concrete check.
2. A diff that lacks enough context: the review names the missing evidence instead of inventing a test result.
3. A failed input command or invalid response: the calling script stops and reports the failure instead of posting a success message.

Automation earns more access by proving it handles failure correctly. This is the same discipline for scripts, GitHub workflows, routines, and coding agents.

Apply the same controls to support automation

The useful Claude Code lesson for support is not “turn on full autonomy.” It is to make the trigger, sources, permissions, expected result, and failure path explicit. eesel offers ready-to-work teammates for helpdesk support and blog writing, with the same workspace visible in the dashboard and CLI.

eesel CLI: investigate a missing scheduled support handoff

Suppose the support lead expected a daily handoff but cannot find today's report. A person, script, Claude Code, Codex, or Cursor can use eesel CLI to inspect the same teammate and workspace as the dashboard. With Node.js 18.17 or newer, identify the signed-in workspace and have the owner confirm the exact teammate to inspect. Each command prints JSON by default.

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
HANDOFF_AGENT="REPLACE_WITH_OWNER_APPROVED_AGENT"
npx @eesel/cli status --agent "$HANDOFF_AGENT"
npx @eesel/cli automations --agent "$HANDOFF_AGENT"
npx @eesel/cli activity --agent "$HANDOFF_AGENT"
npx @eesel/cli approvals --agent "$HANDOFF_AGENT"

Record the selected ID or name before replacing the placeholder. Login stores credentials; the remaining commands inspect state. Supply the coding agent with the expected report, time zone, and destination, then ask it to distinguish three possibilities:

1. Setup mismatch: the expected automation is absent or configured differently. Inspect its details through the current command help or dashboard before proposing a correction.
2. Work recorded, delivery unclear: activity shows relevant work, but the report is missing from the expected destination. Inspect the actual delivery result; activity alone does not prove the recipient received it.
3. An action is held: an approval is waiting on an authorized reviewer. Report it as pending, not as a completed delivery or a permission to approve it automatically.

These are possible findings, not observed incidents. A limited activity view may omit older work, and an empty approvals list does not prove that a schedule ran. Preserve the evidence and uncertainty in the report rather than rerunning the job and risking a duplicate message.

The support owner can review the findings in the same dashboard and approve a specific repair. Consult current command help for that change, preview supported writes with --dry-run, then read back the result. A preview does not test a schedule. Verify the next authorized run and its real destination before saying the handoff is fixed.

Setup and observation commands are free; chat is billed work. If investigating requires a chat or a new test, get approval for that spend. Use an approved nonproduction teammate and synthetic inputs for a response-only test, with consequential actions Disabled in the actual Actions settings. A delivery test needs its own approved test destination and action permissions. A prompt does not enforce those controls.

This example workspace is not evidence of a scheduled report or its delivery. Try eesel with a defined support job and an owner who reviews the setup and results, whether the work starts in a terminal or the dashboard.