Most Claude Code writing assumes you’re building a web app. But a huge amount of a sysadmin’s day is text and commands — scripts, config files, infrastructure-as-code, log triage, runbooks — and that’s exactly the kind of work Claude Code is good at. The catch is that an agent with command access on a machine that touches real infrastructure needs a more careful setup than a developer’s laptop.
This guide is that setup, written for the IT and infrastructure side: where to install it, how to split user and project config, the permission and guardrail choices that keep it safe, and which MCP servers actually help with ops. It pulls together the cluster’s pieces for an ops context — the power-user guide is the general map; this is the sysadmin’s version.
Install: WSL is the better base for ops
You can run Claude Code on native Windows, but for infrastructure work WSL is usually the smoother home. The Linux tooling, path handling, and shell behavior match what most ops tools expect, and the MCP servers you’ll want behave more predictably there.
# inside WSL
npm install -g @anthropic-ai/claude-code
claudeUse native Windows when your tasks specifically target Windows-only tooling — Active Directory PowerShell modules, Windows services, that kind of thing. The WSL install guide covers getting the environment up. The Claude Code commands are identical either way; only paths and a few launch quirks differ, like the cmd /c wrapper for npx-based MCP servers covered in the MCP setup guide.
Split user and project config
Claude Code reads configuration at two levels, and using both well is most of a clean sysadmin setup.
User vs project configuration
| Lives in | Scope |
|---|---|
| ~/.claude/ | You, every machine you set up |
| .claude/ in a repo | The team, that repo |
Your personal conventions — a preferred shell-hardening skill, a status line, helper commands — belong in ~/.claude/ so they follow you onto every box you work on. Anything tied to a specific repo of playbooks, Compose files, or Terraform belongs in that repo’s .claude/ so the whole team inherits it. Start each important repo with a CLAUDE.md describing the environment.
Lock down permissions
This is the part developers can be casual about and you can’t. Claude Code’s permission settings control what needs approval before it runs. For ops, lean toward requiring confirmation on anything that changes state.
- Require approval for commands that modify systems, not just read them.
- Keep destructive operations behind explicit confirmation.
- Review the permission model in the IAM docs and set deny rules for tools or commands you never want run unattended.
Pair this with a PreToolUse hook that hard-blocks the obvious disasters — rm -rf, force pushes, dropping databases — as shown in the hooks guide. Permissions are the policy; the hook is the backstop.
Choose MCP servers with least privilege
The servers worth connecting for ops are a small, careful set. The MCP servers for sysadmins and DevOps article goes deep; the short version:
Sensible ops MCP servers
| Filesystem | Scoped to a config/IaC repo — not your home dir |
|---|---|
| GitHub | Token scoped to the repos you work in |
| Database (read-only) | Non-prod target or read replica for incident digging |
| Fetch | Low-risk way to pull in status pages and docs |
The rule throughout is least privilege. A filesystem server sees one directory. A database server connects as a read-only role against a non-production target. A GitHub token covers only the repos it needs. The server’s permissions are your safety boundary, so set them tight — and read MCP security risks and best practices before connecting anything near real infrastructure.
Build a couple of ops-focused agents and skills
Two things pay off quickly for infrastructure work:
A shell-hardening skill so any script Claude writes uses safe defaults — set -euo pipefail in bash, strict mode in PowerShell, quoted variables, no plaintext secrets. And an incident-runbook skill that encodes your triage steps. Both are in the DevOps skills roundup.
For agents, a read-only log/context explorer that gathers state without changing anything is a safe, high-value first subagent — see the subagents guide for scoping it read-only.
A starting setup
Putting it together, a sensible first configuration for a sysadmin:
Sysadmin setup checklist
- Install Claude Code in WSL (native Windows for Windows-only tasks)
- Personal helpers in ~/.claude/, repo setup in each project's .claude/
- Write a CLAUDE.md for each important infra repo
- Set permissions to require approval for state-changing commands
- Add a PreToolUse hook blocking rm -rf, force push, DROP TABLE
- Connect a small, least-privilege MCP set: filesystem, GitHub, read-only DB, fetch
- Add shell-hardening and incident-runbook skills
- Default new agents to read-only; grant write only for specific workflows
Wrapping up
Claude Code earns its place in operations work — scripts, config, IaC, log triage, runbooks are all squarely in its wheelhouse. The difference from a developer setup is caution: run it in WSL on an admin box rather than on production, split personal and repo config cleanly, require approval for state-changing commands, back that with a destructive-command hook, and connect a small set of least-privilege MCP servers. Get those guardrails right and it’s a genuinely useful pair of hands; skip them and you’ve handed command access to something that occasionally guesses.
For the server picks, see MCP servers for sysadmins and DevOps; for the safety details, MCP security best practices.
