A few weeks ago I wrote about why I don't want to give Claude SSH access to my home server.
It's not that AI agents are useless. It's the opposite...
For further actions, you may consider blocking this person and/or reporting abuse
ran into the same reluctance - giving an AI agent root over my homelab felt like handing it to an intern on day one. the doctor pattern is cleaner: define the safe surface explicitly, the agent stays in bounds
Thanks, "intern on day one" is exactly the feeling. I just wanted a way to manage my server safely — letting an AI touch it through SSH felt way too risky. So instead of giving it a shell, I gave it a fixed set of commands that only read things or do safe ops. The agent stays in bounds because the bounds are the only thing it can see.
that constraint-by-design approach is cleaner than permission scoping - the agent can't exceed scope because the scope is its entire API surface. the edge I keep hitting is safe vs unsafe ops isn't always clear at build time. you decide 'service restart is safe' until it cascades. do you revisit the allowed command list after incidents or keep it static?
Interesting idea! Only today I had a heated discussion with my colleagues about security considerations around using AI and how much you should allow it. I think many people are still not aware of the risks it can bring. Will make sure to read your previous article.
Good luck with your project, it looks impressive! 👏🏻
Thanks Klaudia! Glad the timing lined up with your discussion 😄 Hope the previous article is useful too!
Spot on! Handing a blind weapon like SSH to an AI agent is a disaster waiting to happen.
Local ops demand strict boundary control and determinism. Using Go to build structured, read-only APIs lets the AI act as the 'interpreter' rather than the 'operator'—this is true Local-First architecture. Great work!
The "interpreter vs operator" framing is gold. That's exactly the trade-off I've been struggling with for my own homelab. A shell is a weapon with tab completion, as you put it, and I'm starting to think the right path isn't "better SSH security" but "bounded, read-only tools" like what you built here.
homebutler doctor --json is a beautiful interface for an agent. It's a perfect example of giving the AI less power but more meaning.
Are you planning to add any sort of "change detection" beyond the report command? Like alerting when a specific metric crosses a threshold without needing a full dashboard?
Glad that framing landed. And yeah, change detection is basically the direction I’m pushing toward — not just a small feature on top.
Threshold alerts already exist today:
homebutler alerts --watchpolls CPU, memory, and disk, then sends Telegram/webhook notifications when limits are crossed. Defaults are 90/85/90, so it works without a dashboard.reportalso keeps snapshots and diffs against the previous run, so you get changes like “Running containers: 4 → 3” or “Disk /: +2.3 GB since last report.” Andwatchhandles Docker events, pre-crash logs, and restart flapping.The harder part is drift detection. A container restarting five times is easy to flag. But memory slowly growing 1% every day for two weeks? That’s the thing I want to surface without pulling in a full TSDB. I’m thinking about something lightweight on top of existing snapshots — open to ideas.
Quite interesting!
Thank you! 🙏
"I don't want to give Claude SSH access" is a healthy instinct, and building a read-only doctor instead is the right pattern. The principle generalizes: give the agent rich observability and zero (or tightly scoped) mutation authority. Let it diagnose all day; make a human or a constrained, audited action path do the actual changing.
This is the same trust-boundary idea that makes agents safe anywhere - the danger isn't the model reasoning about your homelab, it's the model with a shell and sudo acting on a wrong conclusion. A doctor that reports findings keeps the failure mode at "bad advice you can ignore" instead of "rm -rf on prod." Smart build. Curious if you gave it any guarded remediation actions, or kept it strictly diagnostic?