Proxmox VE Host Health Audit for Claude Code

July 19, 2026 Updated July 20, 2026 Claude Opus 4.8

Drives Claude Code through a read-only health audit of a Proxmox VE host over SSH and produces a prioritized report of risks and fixes.

DevOps Claude Code proxmox homelab audit ssh

Tested on: Claude Opus 4.8 Claude Fable 5 Claude Opus 4.7

Prerequisites

SSH access to the Proxmox VE host Key-based auth for root or a sudo-capable user; Claude Code runs the audit over SSH.
Proxmox VE 9.x on the target host Verify with pveversion before running the audit.
Claude Code with Bash tool permissions enabled The audit only reads system state, but the session must be allowed to execute shell commands.

Variables

Host*

SSH host alias or user@address of the Proxmox VE host.

Audit the health of the Proxmox VE host {{host}} over SSH. Work strictly read-only: run only the commands listed below, and never run anything that mutates state (no restarts, no config edits, no package operations). If the SSH connection itself fails (host unreachable, authentication denied, wrong key), stop immediately: report the exact error and ask ONE focused question. Never try alternative hosts or credentials on your own. For any other blocker, state your assumption and continue. Step 1. Collect, via `ssh {{host}}`, the output of each command. If the SSH user is not root, prefix every command with `sudo` (each command remains read-only). If one command fails, record the error and continue: ``` pveversion --verbose uptime df -h zpool status -x pvesm status qm list pct list free -h sensors journalctl -p err --since "7 days ago" --no-pager | tail -n 100 systemctl --failed pveperf ``` Step 2. Produce a report with exactly these sections: 1. Host summary: PVE version, kernel, uptime, load. 2. Storage: capacity and health per pool or storage; flag anything over 80 percent full or not ONLINE. 3. Guests: running versus stopped VMs and containers; flag any guest whose status is not exactly `running` or `stopped` (for example paused, suspended, or locked). 4. Errors: distinct error patterns from the journal and failed units, each with a one-line probable cause. 5. Risks, ranked: each risk with severity (HIGH, MEDIUM, LOW), the evidence line from Step 1, and the exact remediation command or config change to propose. Do not execute remediations. Step 3. End with a single verdict line: HEALTHY, DEGRADED, or AT RISK, plus the top reason.

Why this works

Every command is read-only and enumerated up front, so the agent cannot wander into mutating actions. The fixed report structure makes runs comparable across hosts and dates.