Claude Code for DevOps: infrastructure, CI/CD and incident work with guardrails

Is Claude Code good for DevOps work?

Yes, for writing and reviewing infrastructure code, debugging pipelines and reading logs, as long as you set limits first. Claude Code runs commands in your shell with your credentials, so the same power that lets it run terraform plan or kubectl get pods also lets it run something destructive. The setup below keeps the useful part and fences off the dangerous part.

DevOps is a natural fit for a terminal agent. Most of the work already happens in a shell: reading configs, running CLIs, tailing logs and editing YAML. Claude Code lives in that same terminal, and it can also run unattended in CI. This guide covers what it does well, a workflow, example prompts, useful skills and the guardrails to set before you give it access to real infrastructure.

What can Claude Code do for DevOps?

Claude Code reads files, edits them and runs commands. For DevOps, that adds up to:

• Infrastructure as code. Write and refactor Terraform, Kubernetes manifests, Helm values, Dockerfiles and Ansible playbooks, then run the matching validate, lint or plan command to check its work.
• CI/CD pipelines. Write or fix GitHub Actions and GitLab CI files, and explain a failed build from its log.
• Logs and monitoring. The Monitor tool lets Claude "tail a log file and flag errors as they appear" or "poll a PR or CI job and report when its status changes" while the conversation continues.
• Scripting. Turn a runbook into a script, or wrap a repeated chore in a Makefile target.
• Running in pipelines. claude -p runs one task and exits, so you can put Claude inside a build script or CI job. The headless guide covers the flags.

The Bash tool runs each command in a separate process in your environment. That means it uses your installed CLIs and whatever credentials they find, such as your kubeconfig or cloud CLI profile. Plan your guardrails around that fact.

What does a safe DevOps workflow look like?

1. Use a scoped identity. Give the session read-only cloud credentials, a kubeconfig pointed at a dev cluster, or a dev account. Guardrails in Claude Code help, but the strongest limit is credentials that can't do damage.
2. Write the rules down. Put the environment map, the commands Claude may run and the ones it must never run in CLAUDE.md. See the CLAUDE.md guide.
3. Plan first. Start in plan mode with claude --permission-mode plan. Claude reads files and runs read-only commands but does not edit your source files.
4. Let Claude write, you apply. Have Claude produce the change and run terraform plan or a dry run, then read the plan yourself and apply it through your normal pipeline.
5. Review in a pull request. Infrastructure changes go through the same review as any other code.

Here is an example project settings file, not one copied from Anthropic's docs but written with the documented rule syntax, that allows the safe read commands and blocks the dangerous ones. The permissions docs explain that a deny rule always wins, and that rules apply to each subcommand in a chained command:

{
  "permissions": {
    "allow": [
      "Bash(terraform fmt *)",
      "Bash(terraform validate *)",
      "Bash(terraform plan *)",
      "Bash(kubectl get *)",
      "Bash(kubectl describe *)"
    ],
    "deny": [
      "Bash(terraform apply *)",
      "Bash(terraform destroy *)",
      "Bash(kubectl delete *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

Save it as .claude/settings.json in the repo so everyone who runs Claude there gets the same limits. The same docs note that a Bash rule matches the command text as Claude usually writes it, not every form of the program (for example bash -c '...' or a full path), so it isn't a security boundary on its own. That is why the sandbox and scoped credentials below still matter.

Which prompts work well for DevOps?

These follow the patterns in Anthropic's prompt library: point Claude at the real artifact, such as a log or plan output, and ask it to verify its own work.

The deploy job failed. Read @ci-log.txt, find the root cause, and propose the smallest fix. Do not change anything outside .github/workflows/ without asking.

Refactor the Terraform in infra/network/ into a reusable module with variables and outputs. Run terraform fmt, terraform validate and terraform plan, and show me the plan summary. Do not apply.

Review this Dockerfile for image size and security: multi-stage build, non-root user, pinned base image, no secrets in layers. Rewrite it and explain each change.

Tail logs/api.log in the background and tell me when 5xx errors start. Group them by endpoint and point me to the code paths involved.

Turn docs/runbooks/rotate-certs.md into a script with a --dry-run flag that prints every command before it runs. Stop and ask before anything that changes a live system.

The Docker prompts, Kubernetes prompts and Terraform prompts collections have more to start from.

Which skills and integrations help?

To connect Claude to GitHub, run /install-github-app in a repository. According to the GitHub Actions docs, it installs the Claude GitHub App, adds the authentication secret and prepares the workflow pull request for you. It works only with github.com repositories. For GitLab, see the GitLab CI/CD guide; Anthropic marks that integration as beta and maintained by GitLab.

Incident runbooks can also carry deep links. A claude-cli://open URL opens Claude Code in the right repo with a diagnostic prompt already typed, and nothing runs until the person reads it and presses Enter.

What guardrails should you set before giving Claude Code infrastructure access?

• Deny rules for destructive commands. As above. Remember that a broad deny like Bash(aws *) blocks even calls that a narrower allow rule matches.
• A hook as a second check. A PreToolUse hook runs before a tool call and can block it by exiting with code 2. The hooks guide shows a script that blocks edits to .env and other protected files.
• The sandbox. The sandbox limits which files and network hosts shell commands can reach, enforced by the operating system. It is off by default; turn it on with /sandbox. Note that by default sandboxed commands can still read most of the machine, including ~/.ssh and ~/.aws/credentials, so set the credentials and denyRead options too.
• Containers for unattended runs. Anthropic's permission modes table lists bypassPermissions as for "Isolated containers and VMs only." The devcontainer guide covers a ready setup.
• Bare mode in CI. Add --bare to claude -p in pipelines so runs skip local hooks, plugins, MCP servers and CLAUDE.md and behave the same on every machine.
• Prompt injection. Logs, issues and web pages can contain text written to steer an agent. Keep permission prompts on for anything that reads untrusted input. See Claude Code security.

Can Codex or Cursor be used for DevOps too?

Yes. OpenAI's Codex has codex exec for scripts and CI, and its security docs say that by default "the agent runs with network access turned off," with an OS-enforced sandbox limited to the workspace. The codex exec guide covers it. Cursor has a CLI, covered in the Cursor CLI guide. The guardrails above apply to any agent: scoped credentials, deny lists for destructive commands and human review of every apply.

How do you keep your DevOps prompts and skills in one place?

Runbook prompts and review checklists get better each incident, so keep them somewhere versioned. Kipt saves prompts and Agent Skills as Markdown in your own private GitHub repo, with {{name}} blanks for things like service or cluster names, and installs your skills into Claude Code or Codex with npx skills add. If you have a runbook prompt worth reusing, the free SKILL.md generator turns it into a skill folder.