Privacy & security

Updated 16 August 2026 · written next to the code it describes

Helmry is a local tool that runs agents with your privileges on your machine. That is the honest frame for everything below: the security model is about keeping other software (and other people on the network) out, not about limiting what you can do to your own repos.

What leaves the machine

Nothing that Helmry collects. It has no telemetry, no analytics, no crash reporting and no cloud component. Your prompts, the agents’ answers, transcripts, tool inputs and outputs, diffs and file contents are never uploaded by Helmry.

Exactly two outbound requests exist, and both are yours to turn off:

Request Why Control
status.claude.com So the header can warn you when Claude itself is degraded Preferences → Network & startup → Check Claude platform status
GitHub releases Auto-update Only happens if you configured an update token

Claude Code, which Helmry drives, of course talks to Anthropic — that is the product doing its job, and it is governed by your Claude account, not by Helmry.

The network surface

The server listens on 127.0.0.1:4317 only. On top of that, every /api route is guarded by one hook that requires all of:

  • a loopback Host header (or the configured host) — a DNS-rebinding defence, so a page resolving some domain to 127.0.0.1 cannot read your sessions;
  • Sec-Fetch-Site: same-origin (or none) when the browser sends it;
  • a loopback Origin when one is present.

The embedded terminal’s WebSocket is additionally origin-checked, because a handshake carries no Sec-Fetch-Site. Non-browser local callers — the hook shim, the launcher, the permission broker — are exempt from the same-origin rules and authenticate with ~/.helmry/token instead (mode 0600).

There is no TLS and no remote access. Do not bind or forward a reachable address; see the warning in Settings.

Accounts

Signing in is mandatory: without a session cookie, every /api route answers 401, and the cockpit is not even mounted until the session is confirmed.
Password storage scrypt (memory-hard), with the cost parameters stored alongside each hash so they can be raised later without invalidating existing passwords
Brute-force defence 5 failures per (IP, email) and 20 per IP in a 15-minute window; each failure re-arms the window. A login for an unknown address spends the same CPU as a real one, so the response time does not enumerate accounts.
Cookie HttpOnly, SameSite=Strict, 30-day TTL with sliding renewal. Secure is only set over HTTPS — on plain loopback http it would be dropped by the browser.
Registration Closes itself as soon as the first account exists

The deliberate hole: an install with no accounts at all is open, because the first registration has to be able to reach the server. That is safe only while the port is loopback-only. It is also, permanently, the state of a WSL satellite server — nobody signs in to one; its only client is the host’s proxy, and the browser reaching that proxy already passed this gate.

An account is a key to the machine, not a tenancy boundary

This is the most important thing on this page, and it is a design decision rather than a gap:

  • Any signed-in account can list and read every conversation on this machine, and drive every agent.
  • Every agent spends the one shared Claude login — there is no per-user billing separation.
  • Your workspace layout and preferences are per account because a workspace is personal, not because anything is hidden.

Do not treat a second Helmry account as a way to share a machine safely. Real separation means a separate HELMRY_DATA_DIR, a separate ~/.claude, and a separate server per person.

What the agents can reach

An agent is a claude process running as you, in the repo you launched it in. Two mechanisms bound it:

Permission modes (per agent): Plan executes nothing, Ask approves every edit and command, Auto-edit applies edits but asks before commands, Full-auto asks nothing. Full-auto is the default because a fleet that stops on every edit is not a fleet — but it means arbitrary commands with your privileges, so choose it knowing that.

Allowed roots (for the app’s own file and git APIs): the repos Helmry knows plus the folders you added, which must live under your home directory. Every path is resolved through symlinks and checked to be inside a root, so .. and symlink escapes are rejected. Note that this bounds Helmry’s file browser and git operations, not what a command the agent runs can touch.

Observed sessions: the sanitizer

For observed terminal sessions, the hook shim reports lifecycle metadata and a whitelist sanitizer runs before anything reaches the database. The following never leave your machine and are never stored:

prompt text · assistant responses · transcripts · full bash commands · tool inputs and outputs · environment variables · file contents · secrets

Bash commands are classified for test-detection in memory and then discarded.

Logs and secrets on disk

  • ~/.helmry/logs/main.log holds metadata and decisions only — never prompt or response text, tool I/O, or secrets. Same discipline as the sanitizer.
  • Secret files are mode 0600: the ingestion token (~/.helmry/token) and the auto-update token.
  • The update token is deliberately not put into the environment: the app spawns claude, git and your terminal, and all of them would inherit it.
  • Writes that matter are atomic (temp file + rename), so a crash cannot leave a half-written config or credential.

Deleting your data

rm -rf ~/.helmry          # sessions, events, accounts, chat index, prompts, logs, archive

Claude’s own transcripts are not Helmry’s to delete; they live in ~/.claude/projects. If you installed hooks, helmry uninstall-hooks (or editing ~/.claude/settings.json) removes them.