Claude Code admin automation: a safe setup guide for IT admins

What Claude Code is, and where it runs

According to the overview page, Claude Code is an agentic coding tool that reads a codebase, edits files, runs commands and integrates with development tools. It runs in the terminal, in IDE extensions (VS Code, JetBrains), in a desktop app, on the web, and in CI through GitHub Actions or GitLab CI/CD. The page says each surface connects to the same engine, so a repository's CLAUDE.md files, settings and MCP servers work across them. The Agent SDK exists for building custom agents.

For admin automation the useful surfaces are the CLI in non-interactive mode (claude -p), scheduled tasks (cloud or desktop), and the GitHub Action. The interactive terminal is where you develop and test the workflow before you automate it.

Project instruction files: CLAUDE.md

The memory page lists four places for CLAUDE.md: managed policy (/Library/Application Support/ClaudeCode/CLAUDE.md on macOS, /etc/claude-code/CLAUDE.md on Linux and WSL, C:\Program Files\ClaudeCode\CLAUDE.md on Windows), user (~/.claude/CLAUDE.md), project (./CLAUDE.md or ./.claude/CLAUDE.md) and local (./CLAUDE.local.md, to be kept out of version control).

• Files in the directory tree above the working directory load at launch and are concatenated, not overridden; instructions closer to the working directory come later. Files in subdirectories load on demand.
• Files can import other files with @path, to a maximum depth of four hops.
• The page recommends under 200 lines per file, and path-scoped rules under .claude/rules/ for instructions that matter for only part of a codebase.
• If a repository has an AGENTS.md and no CLAUDE.md, Claude Code can read the AGENTS.md instead (version 2.1.277 or later); if both exist, only the CLAUDE.md files are read unless one imports the other.

The page is explicit that Claude treats these files as context, not enforced configuration: "To block an action regardless of what Claude decides, use a PreToolUse hook." Auto memory, which Claude writes itself, is also loaded each session. For repeatable unattended jobs, decide whether you want that; non-interactive bare mode (below) skips it.

Permission modes, rules and sandbox

The permission modes page lists these modes: default (manual: reads only without asking), acceptEdits, plan, auto (a classifier model reviews actions), dontAsk (anything that would prompt is denied) and bypassPermissions (for isolated containers and VMs only). Deny rules block in every mode, including bypassPermissions. The page says the terminal's starting mode is auto from version 2.1.283, while claude -p starts in default from version 2.1.302. Because the defaults changed between versions, set the mode explicitly in unattended jobs.

The permissions page says rules are evaluated in the order deny, then ask, then allow, and the first match decides. A PreToolUse hook decision does not bypass deny or ask rules. Read and Edit deny rules, such as Read(./.env), cover Claude's file tools and recognised file commands in Bash, but the page notes limits, so do not treat a rule as a full secrets boundary.

Admins can set permissions.disableBypassPermissionsMode and permissions.disableAutoMode to "disable", and permissions.defaultMode, in managed settings. The --restricted flag refuses to start in bypass mode.

Sandbox. The sandboxing page describes an OS-enforced boundary around shell commands: Seatbelt on macOS, bubblewrap and socat on Linux and WSL2, and no sandbox on native Windows. It is off by default; enable it with /sandbox or sandbox.enabled. By default writes are limited to the working directory and a temp directory, while reads are allowed almost everywhere, including ~/.ssh and ~/.aws/credentials, unless you add deny settings. Network traffic goes through a proxy with an allowlist that starts empty. Limits: it covers shell commands only; file tools, command hooks and local MCP servers run outside it, and if the sandbox cannot start Claude Code runs commands unsandboxed unless sandbox.failIfUnavailable is true.

Integrations: MCP, plugins, skills, hooks and subagents

MCP. Add servers with claude mcp add --transport http <name> <url> or the stdio form, in local, project (.mcp.json) or user scope. In interactive sessions Claude Code prompts before using servers from .mcp.json, but the page says claude -p loads them without a prompt, so review that file in any repository you automate. Remote servers support OAuth, and ${VAR} expansion keeps secrets out of the file. The page warns to verify each server and notes prompt injection risk from servers that fetch external content. Administrators can supply managedMcpServers; the exact allowlist and denylist syntax was not on the part of the page that was read, so check the managed MCP page.

Plugins. A plugin is a directory of skills, agents, hooks and MCP servers installed as one unit from a marketplace. The overview says what a plugin runs, it runs with your user privileges, and an enabled plugin adds its skill names to context on every turn. Through managed settings an organisation can allowlist or block marketplaces and force-install plugins.

Skills. A skill is a directory with SKILL.md and optional files, stored in ~/.claude/skills/, .claude/skills/, a plugin, or the managed settings directory. Safety-relevant fields: disable-model-invocation: true stops Claude triggering a skill on its own, and allowed-tools pre-approves tools for that skill's turn, so review it in any repository skill before running it.

Hooks. Hooks run shell commands at lifecycle points such as SessionStart, PreToolUse, PostToolUse, PostToolUseFailure and ConfigChange. Exit code 2 from a PreToolUse hook denies the call, and when several hooks answer, the most restrictive result applies. The hooks guide shows a PreToolUse hook appending each Bash command to a log file and a ConfigChange hook writing settings changes to an audit log.

Subagents. Subagents are Markdown files with frontmatter in .claude/agents/ or ~/.claude/agents/. Useful fields are tools, disallowedTools, permissionMode, maxTurns and model. Subagents inherit the parent's permission rules, and if the main session is in bypassPermissions, acceptEdits or auto, that mode applies. Nesting is allowed up to three layers by default. The built-in Explore subagent is read-only.

Automation: non-interactive mode, scheduled tasks and GitHub

Non-interactive. claude -p "<prompt>" runs once and exits with a non-zero code on failure. --output-format json returns the result plus session metadata and cost, stream-json streams events, and --json-schema constrains the output. --allowedTools pre-approves tools, --permission-mode sets a baseline, and --permission-prompts none denies anything that would prompt, which the page recommends for unattended jobs such as a scheduled run. Piped input is capped at 10 MB. The page recommends --bare for scripts: it skips auto-discovery of hooks, skills, plugins, MCP servers, auto memory and CLAUDE.md, so every machine behaves the same, and it needs ANTHROPIC_API_KEY rather than a subscription login. Without --bare, claude -p runs project hooks and connects project MCP servers even in a folder you have never trusted.

Scheduled tasks. The scheduled tasks page (research preview, "behavior, limits, and the API surface may change") says cloud tasks, formerly routines, run on Anthropic-managed infrastructure or an organisation's self-hosted environment, with schedule, API and GitHub triggers. They are available on Pro, Max, Ultra, Team and Enterprise plans. Each run is a full cloud session in a selected environment with its own network access level; the default environment uses "Trusted" access, an allowlist of package registries and common services. Connectors are all included by default, so remove the ones a task does not need. Runs push to claude/-prefixed branches unless told otherwise, and the page says to use branch protection to control pushes. Cloud sessions start in auto mode when available. Scheduled runs are limited to 100 per hour per account. Desktop scheduled tasks run on your machine, and /loop repeats a prompt inside a session.

GitHub Actions. anthropics/claude-code-action@v1 runs in interactive mode on @claude mentions or in automation mode when a prompt is supplied, including on a cron schedule. Triggering users need write access, and bots are rejected unless listed in allowed_bots. The page advises storing keys as GitHub Secrets, granting the workflow only the permissions it needs, and capping work with --max-turns and workflow timeouts. It notes the Claude GitHub App has a single permission set that includes more than the Action uses, and describes a custom GitHub App as the narrower option.

Set up a safe automated workflow, step by step

1. Pick one read-only job, such as a weekly summary of failed backup jobs from an export. Do not start with changes.
2. Create a dedicated identity with read-only roles for anything the agent reaches. See the AI agent identity and least privilege guide.
3. Write CLAUDE.md with scope, allowed commands, forbidden actions, output format and where results go, under 200 lines. Put long runbooks in skills so they load only when used.
4. Set permissions in a settings file: deny rules for secrets and destructive commands, allow rules for the exact read-only commands, and an explicit mode. Use dontAsk or --permission-prompts none for unattended runs.
5. Turn on the sandbox with sandbox.failIfUnavailable and an empty or minimal network allowlist, on macOS, Linux or WSL2.
6. Connect MCP servers narrowly, with --strict-mcp-config or --bare plus --mcp-config so only the servers you named load.
7. Require structured output with --output-format json and --json-schema, and check the exit code.
8. Add logging hooks before you widen anything (next section).
9. Run by hand several times, then schedule it, and keep change actions behind a human approval. For PowerShell, see human approval before AI-generated PowerShell runs.
10. Never put secrets in prompts or CLAUDE.md. Use environment variables, and consider the sandbox credential settings that deny or mask files and variables.

What to log

Aim for a record that answers who asked, which tool ran, against what, with which approval, and what happened. The documentation gives you these sources:

• OpenTelemetry. With CLAUDE_CODE_ENABLE_TELEMETRY=1 and an exporter, Claude Code emits events including claude_code.user_prompt, tool_result, tool_decision and api_request, and metrics for cost and tokens. Prompt text is redacted unless OTEL_LOG_USER_PROMPTS=1, and tool parameters need OTEL_LOG_TOOL_DETAILS=1. Admins set the exporter in managed settings; repository settings cannot override the exporter variables.
• Hooks. A PreToolUse hook can append each command to a log file, and a ConfigChange hook can record settings changes.
• Run output. --output-format json and stream-json include session IDs, cost and, in streams, permission_denials.

Record at least a correlation ID, the identity used, the tool and redacted arguments, the permission decision, start and end time, exit status and output location. Test a few sample entries with the free AI agent audit log checker, and read AI agent audit trail for the field list. Mask secrets before logs leave the host.

Cost model

According to the costs page read on 3 November 2026, Claude Code charges by API token consumption, and plan pricing is on claude.com/pricing (not quoted here). On Team and Enterprise plans usage draws from a per-seat allowance on a rolling five-hour window and a weekly window; usage credits and spend limits can extend it. On the Console, spend is set with workspace limits, and on cloud providers billing and caps live in your cloud account. The same page states that across enterprise deployments the average is around $13 per developer per active day and $150 to $250 per developer per month, for interactive developer use; it does not give a figure for unattended automation. The scheduled tasks page says tasks draw down subscription usage like interactive sessions.

To model your own cost, count runs, include retries, subagents and plugin context, and cap each run: --max-turns, a smaller model for simple tasks, --max-budget-usd where available, and workflow timeouts. The costs page notes that --output-format json reports total_cost_usd, but calls it a client-side estimate that can differ from your bill.