Claude for sysadmins: everyday server jobs

Claude for sysadmins: advice first, execution second

Claude for sysadmins works best as a reviewer. You paste a log excerpt, a config file, a command you do not recognise, or an error string, and you get back an explanation you can check before you change anything on the box. A wrong answer costs you nothing until you run it, so keeping the model on the advice side of that line is the whole safety model.

Six jobs come up every week on a rented Linux VPS (virtual private server). Each one below has a prompt pattern that works, the command that proves the answer, and the failure mode you should expect. None of them need the model to have access to your server.

The order matters on a production box: read the explanation, run the check yourself, then decide. Autonomy is fine on a scratch VM. On the box that serves your customers, review wins, because the model cannot see the state it is guessing about.

What you must never paste

Everything in the prompt leaves your server. Four categories stay on the box:

• Private keys: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key, and any TLS (transport layer security) key under /etc/letsencrypt/live/.
• Credential files: .env, ~/.aws/credentials, /root/.docker/config.json, and database passwords in any file or any log line.
• Account data: /etc/shadow and /etc/gshadow. No sysadmin question needs a password hash to answer it.
• Anything belonging to your users: email addresses, order rows, request logs carrying session cookies or PII (personally identifiable information).

Public keys are safe to paste. Private keys are not, and the two files look similar at a glance, so read the first line before you copy: a file whose first line contains BEGIN OPENSSH PRIVATE KEY never goes in a prompt. Keeping your SSH key material straight is worth ten minutes on its own.

Redact before you paste, rather than trusting yourself to spot one token in 200 lines:

sudo journalctl -u myapp -n 200 --no-pager | sed -E 's/(token|secret|password|api[_-]?key)[=:][^[:space:]]+/\1=REDACTED/gI'

One trap is specific to Docker. docker compose config interpolates your .env values into the output it prints, so that output is a secret even though the file on disk was not. Use docker compose config -q, which validates and prints nothing. For the wider policy on what an agent is allowed to see, keeping secrets out of AI agents covers the environment side.

Job 1: why did this service fail?

Start with the two commands that hold the answer:

systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service -b -n 100 --no-pager -o short-iso

Paste both, with the context the model cannot guess: the distribution and version, what you changed last, whether it ever worked, and how long ago it broke. Ask for the mechanism first.

Ubuntu 24.04. myapp.service was fine until I edited the unit an hour ago. Here is systemctl status and the last 100 journal lines. Which line is the first real error, and what does it mean? No fix yet.

"No fix yet" is doing real work in that prompt. Logs bury the first failure under the retries it caused, so a model asked for a fix will explain the last line it saw. The line that matters is usually twenty lines above the noise.

The payoff is a line like Main PID: 1841 (code=exited, status=203/EXEC). Exit status 203/EXEC means the kernel could not execute the file named in ExecStart: either the path does not exist, or the file exists and is not executable. A #! line naming an interpreter that is not installed produces the same status. All of that is testable with ls -l and head -1.

Failure mode: an invented cause. Paste too little and the model fills the gap with something generic, such as "the port is already in use". The cure is one question back: "which line in what I gave you supports that?" A cause nobody can point at in the text is a guess.

Job 2: draft a systemd unit or a cron entry

Give it the facts a unit file needs: the exact command, the user it runs as, the working directory, whether it must wait for the network, and what should happen when it exits non-zero. Then verify what comes back before you enable anything.

sudo systemd-analyze verify /etc/systemd/system/myapp.service
sudo systemctl daemon-reload
sudo systemctl start myapp.service
systemctl status myapp.service --no-pager

systemd-analyze verify parses the file the way systemd does, so it catches what a human eye slides past. A misspelled directive prints /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring. A missing binary prints Command /usr/local/bin/myapp is not executable: No such file or directory. Both stay silent during daemon-reload, which is why a unit can load cleanly and still fail the moment it runs.

Two drafting mistakes show up again and again. The first is After=network.target, which only means the network stack is configured, not that an address exists yet. A service that binds to a specific IP then fails at boot with bind: Cannot assign requested address, and the fix is Wants=network-online.target together with After=network-online.target. The second is Type=simple for a program that daemonises: systemd treats the first process as the service, the parent exits straight away, and the unit is marked dead while the real process keeps running unmanaged.

For a schedule, check it instead of reading it:

systemd-analyze calendar 'Mon *-*-* 04:00:00'

That prints the normalised form and the next time the expression will fire, which settles any argument about what it means. If you are choosing between a timer and a crontab, systemd services and timers on a VPS covers the trade.

Cron has a trap no model will warn you about unless you ask. Cron runs jobs with a minimal environment, so PATH is roughly /usr/bin:/bin and your shell profile is never read. A job that works when you paste it into your terminal fails under cron with /bin/sh: 1: docker: not found, because that binary lives in /usr/local/bin. Use absolute paths in crontabs.

Job 3: review an nginx or Compose file before it goes live

This job has the best return. Paste the file, state what it is supposed to do, and ask for a line by line account of what it actually does.

This vhost should serve example.com over HTTPS and proxy /api to a local service on port 8080. Read it back to me and name anything that does not match that description.

Then run the tool that knows the grammar:

sudo nginx -t
docker compose config -q

nginx -t prints nginx: configuration file /etc/nginx/nginx.conf test is successful, or it names the file and the line, as in nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12. docker compose config -q prints nothing when the file parses, and something blunt like yaml: line 7: did not find expected key when your indentation slipped.

Neither tool checks intent. A config that passes nginx -t can still proxy to the wrong port, or listen on 0.0.0.0 when you meant 127.0.0.1. That gap is where the model earns its place, and it is also where it fails: asked to fix one directive, it often returns the whole file rewritten with two of your directives quietly missing. Ask for the changed lines and the reason for each, then edit by hand.

Confirm what you actually exposed:

sudo ss -tulpn

Without sudo you see the listening sockets but not the processes that own them. If that output surprises you, what ports are and how Linux binds them is the shorter read.

Job 4: explain an unfamiliar command before you run it

Paste the command and ask four questions about it: what does each flag do, what does it write, what does it delete, and what happens if I run it twice. The last one catches more damage than the others.

Take find /var/log -name '*.gz' -mtime +7 -delete. A good answer tells you that -mtime +7 counts whole 24 hour periods and discards the fraction, so it matches files at least eight days old rather than seven. It also tells you that find evaluates its expression left to right, so moving -delete in front of -name deletes everything under the starting path. That second point sits in the find man page as a warning, and it has cost people their /var/log.

Or take rsync -a --delete /srv/app/ /backup/app/. The trailing slash on the source means "the contents of this directory". Drop it and you get /backup/app/app/. Add --delete and anything in the destination that is missing from the source is removed, which is correct for a mirror and a disaster when the source path is wrong.

Verify with the tool, not with the model:

rsync -a --delete --dry-run /srv/app/ /backup/app/ | head -20
find /var/log -name '*.gz' -mtime +7

Run the find without -delete and you get a list instead of a loss.

Failure mode: flag hallucination. The model is reliable on tools with thirty years of documentation and much weaker on vendor CLIs (command line interfaces) and recent subcommands, where it produces a flag that reads perfectly and does not exist. --help settles it in one second. Quoting is the other soft spot, so when a command wraps a $(...) expression, read how command substitution expands before the command runs rather than trusting the explanation.

Job 5: turn your shell history into a runbook

You just spent two hours getting something working. That knowledge lives in your scrollback and it will be gone next month.

history 200 > /tmp/session.txt

Read that file and delete every line holding a password, a token, or a customer identifier before it goes anywhere. Shell history is one of the most reliable places to find a secret on a Linux box, because everyone types one inline at least once. Set HISTCONTROL=ignorespace in your ~/.bashrc and a command typed with a leading space is never written to history at all.

The prompt that produces a usable runbook asks for checks, not only steps:

This is a shell session that took a fresh Debian 13 box to a working Postgres install. Write it up as a numbered runbook. One command per step. After each step, give the command that proves it worked and describe what healthy output looks like. Mark any step that depended on my specific host.

Failure mode: a tidy story. Your session had a step you got wrong twice before fixing, and that is the step the model smooths away, because the transcript reads cleaner without it. Compare the runbook against your history and put the correction back. It also invents plausible verification commands, so run every check it writes before you save the file. If the runbook covers a first boot, read it against the first ten minutes on a new VPS so you are not writing down a worse version of a solved problem.

Job 6: turn an error message into a fix

Paste the exact string, the command that produced it, and the one thing you changed before it appeared. Ask for ranked causes with a distinguishing command for each, which forces the answer into something testable.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). Rank the likely causes and give me one command per cause that confirms or rules it out.

For that error the mechanism is not ambiguous: another process already holds port 80, and sudo ss -tulpn | grep ':80 ' names it. Often it is a second nginx master left behind by a failed reload, or Apache pulled in as a dependency and started by its own package.

Failure mode: a fix that works by hiding the cause. chmod 777, --privileged, disabling SELinux, and running the service as root all make the error disappear. Refuse any fix that widens permissions until the model has explained why the narrow permission failed. That explanation is the actual answer. A workaround only makes the error quiet.

What it gets wrong, reliably

• It cannot see your box. Every answer is a function of what you pasted, and it will not tell you the excerpt was too short.
• It drifts on versions. Package names and default flags move between distributions and releases, and the model averages over all of them.
• It is fluent when it is wrong. A hallucinated mechanism reads exactly like a correct one, which is why every cause above comes with a command that tests it.
• It loses the thread in long sessions. Facts from the top of a two hour conversation stop shaping the answers at the bottom.

That last one is a working problem more than a model problem, and managing context in a long Claude Code session is the practical fix: shorter sessions, one task each.

Putting the agent on the server itself

Everything above is copy and paste, so the model never touches your machine. Once it runs on the box, reading files and executing commands, the shape of the risk changes: a wrong command now costs you a service. Give it its own unprivileged user rather than root, keep it off the production box while you learn its habits, and take a snapshot first. Running Claude Code safely on a VPS covers the sandboxing and the permission model. Driving Claude Code inside tmux solves the other half, since a dropped SSH (secure shell) session kills a foreground agent halfway through its work. Build the account the way you would build any service account, which least privilege users on a VPS spells out.

FAQ

Can Claude read my server logs directly?

Not by itself. The chat interface only sees the text you paste into it. Claude Code, run on the server as a command line tool, can read files and run commands with the permissions of the user that started it, which is a larger trust decision. For an ordinary support question, pasting a redacted 100 line excerpt is faster and safer than giving an agent shell access.

What should I never paste from a server?

Private keys, .env files and other credential stores, /etc/shadow, and any data belonging to your users. Redact tokens out of log excerpts before they reach the prompt. One non-obvious case: the output of docker compose config has your .env values interpolated into it, so use docker compose config -q, which validates the file and prints nothing.

Is it safe to let Claude run commands on a production VPS?

Treat it like a new admin with no context: fine for reading, review needed for writing. On production, ask for the explanation and run the command yourself. If you do want an agent executing, give it a dedicated unprivileged account without blanket sudo, and start on a staging box where a mistake costs you a rebuild instead of an outage.

Why does Claude suggest a flag that does not exist?

Because it predicts plausible text, and a plausible flag looks the same as a real one. It happens most with vendor CLIs and newer subcommands, where the documentation behind the model is thin or has since changed. --help and man are the arbiter, and any command that deletes or overwrites deserves a dry run first.

How do I check a systemd unit before I enable it?

Run sudo systemd-analyze verify /etc/systemd/system/myapp.service. It parses the file with systemd's own parser, reports unknown directives with their line numbers, and flags an ExecStart binary that is missing or not executable. Then run daemon-reload, start, and read systemctl status before you enable it, because a unit that loads cleanly can still fail on its first run.