I Just Want to Tell Claude to “Go Fix That Pi in the Attic”

How a weekend of frustration turned into an MCP server that lets Claude SSH into any of my machines

Announcing Claude Remote Agent — an open-source MCP server that lets Claude CLI interact with remote Linux, macOS, and Windows systems via SSH. Clone it, configure your hosts, and start telling Claude to manage your fleet of machines without leaving your desk.

👉 Get it on GitHub

The Problem: Claude is Great, But It’s Stuck on This Machine

I’ve got a problem. Well, actually I’ve got about a dozen problems, and they’re scattered across my house on various Raspberry Pis.

There’s the one in the attic running an ADS-B receiver, tracking aircraft overhead. Another one in the garage running RTL-SDR for weather satellite reception. A Pi in the basement monitoring my weather station. And a handful more running various radio experiments because apparently I can’t say no to a $35 computer that receives signals from space.

Here’s the thing: Claude Code is incredible for working on these systems. Need to debug a GNURadio flowgraph? Claude’s got me. Trying to figure out why dump1090 stopped feeding data to my aggregator? Claude knows. Want to tweak the gain settings on my RTL-SDR? Claude can walk me through it.

But there’s a catch. Claude only works on the machine it’s installed on.

And I am absolutely not installing Claude Code on every Pi in my house. Half of them are running on SD cards that are probably held together by hope and thermal paste. Some don’t have the compute to spare. And honestly? I don’t want to SSH into the attic Pi, fire up Claude, do the thing, then SSH back out. That’s too many steps.

What I want to do is sit at my desk and say:

“Hey Claude, check if the ADS-B receiver on pi3 is still feeding data to FlightAware”

And have Claude just… do it. From here. Without me touching SSH at all.

The SSH Frustration

“But wait,” I hear you say, “can’t Claude just SSH into things?”

Technically? Sure. Claude can run ssh commands via Bash. But it’s clunky. Every command is a new SSH connection. There’s no persistence. If I want to cd somewhere and then run a command, that’s two separate SSH calls, and the cd is forgotten by the second one.

And don’t even get me started on interactive sessions. Want to tail a log? Good luck. Want to run something that needs a TTY? Nope.

I tried various workarounds. SSH command chaining. Heredocs. Multiplexing. Nothing felt right. I was fighting the tool instead of using it.

So I did what any reasonable person would do on a Saturday morning: I decided to build a solution.

Introducing Claude Remote Agent

So I built one. It’s called Claude Remote Agent, and it lets Claude interact with any of my remote systems via SSH.

The key features:

Persistent Connections: SSH connections stay open and get reused. No more connection overhead on every command.

Real File Operations: Read, write, and edit files on remote systems via SFTP. Not hacky cat commands—actual file operations.

Session Management: Start a session, run multiple commands, maintain state (like working directory), then close it. Just like a real SSH session.

Host Groups: Define groups like “all-pis” or “sdr-receivers” and run commands across all of them.

Security Policies: Per-host rules for what commands are allowed. My production server gets “confirm everything” while my dev Pi gets “do whatever.”

And it’s all local: Your SSH keys never leave your machine. Claude sees command output, not credentials.

How It Actually Works

Here’s what I can do now. I just talk to Claude:

“Check the uptime on all my Pis”

Claude uses the remote_execute tool across my all-pis host group:

pi1 (192.168.10.131): up 45 days, 3:22
pi2 (192.168.10.163): up 12 days, 7:15
pi3 (192.168.10.150): up 89 days, 14:02
pi4 (192.168.10.13):  up 3 days, 22:45
pi5 (192.168.10.211): up 67 days, 8:33
pi6 (192.168.10.97):  up 23 days, 11:18

“The ADS-B feeder on pi3 seems stuck. Check the dump1090 service and restart it if needed.”

Claude SSHes into pi3, checks systemctl status dump1090-fa, sees it’s failed, checks the logs, restarts it, and confirms it’s running.

“Show me the last 50 lines of the rtl_433 log on the weather station”

Done. No SSH. No remembering which Pi is which. Just asking for what I want.

“Edit the gain setting in /etc/rtl_433.conf on rtlsdr—change it from 40 to 35”

Claude reads the file, makes the edit, shows me the diff, and asks if I want to restart the service.

This is the dream.

The Fun Stuff: SDR From the Couch

The real payoff is with my SDR setups. These things are finicky. Gain settings need tweaking. Services crash. Antennas get unplugged by curious cats.

Now I can diagnose and fix them without leaving my desk:

“Why isn’t the weather satellite decoder producing images?”

Claude checks the rtl_sdr process, looks at the logs, finds that the SDR device disconnected, suggests unplugging and replugging the USB (some things still need human hands), and waits for me to confirm before restarting the pipeline.

“Set up a new frequency capture on the adsb receiver—I want to log 433MHz traffic for the next hour”

Claude starts rtl_433, sets up the logging, and even offers to check back in an hour to grab the results.

It’s like having a sysadmin who knows all my systems and never judges me for having too many Raspberry Pis.

Security: Because We’re Not Monsters

I know what you’re thinking: “This sounds like a great way to accidentally rm -rf / on production.”

Fair. That’s why the agent has security policies:

• Blocked Commands: Some things are just never allowed. rm -rf / is on the list by default.
• Confirmation Levels: Set per-host. My dev Pis run with “destructive_only” (confirm deletes, kills, reboots). Production boxes require confirmation for everything.
• Command Allowlists: For really sensitive systems, you can whitelist only specific commands.
• Audit Logging: Every command gets logged with timestamps, exit codes, and (sanitized) output.
• Output Sanitization: Passwords, API keys, and tokens get automatically redacted from logs.

And crucially: your credentials stay local. The MCP server runs on your machine. SSH connections go directly from you to your hosts. Nothing goes through Anthropic’s servers. Claude sees the output of commands, never your keys.

Getting Started

If this sounds useful to you, here’s how to get going:

# Clone and build
git clone https://github.com/haxorthematrix/claude-remote-agent
cd claude-remote-agent
npm install
npm run build
npm link

# Initialize config
claude-remote-agent init

# Register with Claude CLI
claude mcp add remote-agent -- claude-remote-agent serve

Then edit ~/.config/claude-remote-agent/hosts.yaml to add your hosts:

hosts:
  pi-attic:
    hostname: 192.168.1.50
    user: pi
    auth:
      type: agent  # Uses your SSH agent
    policy:
      confirmation_required: destructive_only

That’s it. Next time you chat with Claude, you can start managing remote systems.

What’s Next?

The core is solid, but I’ve got ideas:

• WinRM Support: For Windows boxes that aren’t running SSH
• Docker Integration: Run commands in containers without SSH
• Kubernetes: kubectl exec integration
• Multi-host Orchestration: More sophisticated workflows across multiple machines

But honestly? Right now it does exactly what I built it for: I can sit on my couch and tell Claude to go fix that Pi in the attic.

And that’s pretty great.

👉 Claude Remote Agent on GitHub — Star it, fork it, contribute, or just use it to finally stop SSHing into things manually.