← Back to the comparison

Independent review · Full response

Herdr

Herdr · Claude Code · Security code review

2026-10-22a2008661c ↗Public-web access only

Exact prompt

Is there a security risk in installing this tool? Read the security-related code in this repository and understand its encryption and data transmission mechanisms before answering. If a mechanism cannot be verified from the accessible code, say so.
Pinned repository link supplied with the question ↗

The text below is the agent’s complete original response, with its original language identified. The introduction is editorial, not part of the original output or an independently verified conclusion. No installation or attack testing was performed.

Editorial introduction

Remote transport relies on system SSH; no hidden uploads found in inspected paths. Flags unsigned manifests, plugin execution and remote installs.

Reading scope: Checksum/update, SSH transport, local API and plugin code; some large files truncated.

Download the complete original English text · SHA-256 40cff0c8af63e52d346aa8350b1bcdd0ec9bb136cc896d017a1c3f73061e1746

Complete original response

My verdict: at this commit I found no sign of malicious behavior, telemetry, or hidden data uploads. The real risks are ordinary supply-chain ones, plus the fact that herdr deliberately runs and controls your coding agents and SSH sessions. It’s reasonable to install if you trust the herdr.dev maintainers about as much as any project you curl | sh.

I read the source through GitHub’s web pages, so I didn’t clone, build or run anything. A few large files only came back in part. Each place that limits a conclusion is marked below.

Encryption

herdr has no encryption code of its own. Its only crypto dependency is sha2, used to compare SHA-256 checksums (src/checksum.rs). There’s no TLS library, no HTTP client crate and no custom protocol. All encryption comes from two external programs:

  • curl over HTTPS, for update checks and downloads.
  • Your system OpenSSH ssh, for remote machines.

What goes over the network

What Destination Data sent Can you turn it off?
Update check at startup https://herdr.dev/latest.json (or preview.json); Homebrew installs query formulae.brew.sh A plain GET. The code adds no version, OS or ID. The server still sees your IP and curl’s User-Agent. Config has version_check and manifest_check, both on by default. I couldn’t confirm exactly what each one controls.
herdr update Binary URL taken from the manifest Plain GET Manual only. It never auto-installs.
Remote machines Hosts you choose, via system ssh Your terminal traffic, inside SSH Only used if you use remotes
Plugin install https://github.com/{owner}/{repo}.git, via git Plain git fetch Only when you install a plugin

Telemetry: I found no analytics or telemetry code and no telemetry config. “Product announcements” just reads text from the update manifest and stores it locally.

Local API: it uses only a Unix socket or Windows named pipe, with no TCP listener. The socket is set to 0600, owner only.

Risks to know about

  1. Downloads have checksums but no signatures. install.sh and herdr update both get the SHA-256 from the same herdr.dev manifest as the binary. That catches corrupted downloads, but someone who compromised herdr.dev could swap both. There’s no GPG or minisign check, and install.sh doesn’t pin curl to HTTPS (--proto =https). Preview-channel downloads may skip the checksum entirely if the manifest leaves it out.

  2. Prebuilt binaries can’t be tied to this source. Everything here applies to the code at commit a200866. I can’t prove the binaries on herdr.dev, GitHub Releases or Homebrew were built from it. Building it yourself (cargo build --release) closes that gap.

  3. The installer itself is modest. It writes only to ~/.local/bin, doesn’t use sudo, doesn’t edit your shell rc files, and doesn’t run herdr.

  4. Remote hosts:

    • Good: herdr uses StrictHostKeyChecking=yes and BatchMode=yes and stores no passwords or keys. I saw no agent forwarding (-A) or port forwarding, and SSH control sockets are carefully restricted (/tmp/hssh-<uid>, mode 0700, ownership checks).
    • Caveat: its SSH config pulls in your own ~/.ssh/config, so any ForwardAgent yes there still applies.
    • Caveat: herdr installs its own binary on remote hosts under $HOME. When the platforms match, it pipes your local binary over SSH with no checksum step that I could see.
    • Unverified: it hands your local SSH_AUTH_SOCK path to the herdr server. I couldn’t see the server-side code that uses it.

  5. Plugins run arbitrary code. Their build commands run with your full user privileges and no sandbox. Installs aren’t pinned to a commit unless you pass --ref. There’s a confirmation prompt that lists the commands first, but --yes skips it.

  6. Local trust model. Connections to the local socket aren’t authenticated; peer credentials are only logged. That’s normal for a tmux-style tool: protection comes from file permissions. Any process running as your user can drive your agent panes through the API, so this doesn’t defend against malware already running as you.

What I couldn’t verify

  • The permissions of the socket’s parent directory on Unix, and the Windows named-pipe security settings (platform/windows.rs, not reviewed).
  • The full curl wrapper flags, because part of update.rs was cut off.
  • How install.ps1 uses the checksum on Windows.
  • How the server uses the registered SSH agent path.
  • Anything on the herdr.dev server side, such as logging.

Recommendations

  • Safest: build from source at a commit you’ve reviewed, or download a release binary and compare its checksum against the GitHub release yourself.
  • Set version_check/manifest_check to false if you don’t want startup requests to herdr.dev.
  • Pin plugins with --ref <commit>, read their build commands before confirming, and don’t use --yes on plugins you haven’t read.
  • Check that your SSH config doesn’t set ForwardAgent yes for hosts you connect to through herdr.
← Back to the comparison