Proxmox VE Host Health Audit for Claude Code
Updated 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.
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
pveversionbefore 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
Edits here and in the highlighted fields inside the prompt stay in sync.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.