▓SORDINO
GitHubGet Started

Documentation

Two commands and a restart — that's the whole install. Everything else on this page is optional depth for when you want it.

install
Install into Claude Code
Run these inside a claude session— they're Claude Code slash commands, not shell commands.
/plugin marketplace add FailSpy/sordino
/plugin install sordino
[restart Claude Code]
Add Sordino to Claude Code

Opens Claude Code with the first command above pre-filled (requires Claude Code already installed) — run /plugin install sordino yourself after.

That's it. The plugin ships prebuilt binaries — no compile, no download — and auto-routes this project the moment it sees it. After the one-time restart, masking is live.

/sordino:status

Run that to confirm masking is on. If it isn't, /sordino:doctor catches the usual causes — a local firewall/AV intercepting 127.0.0.1, or a busy static port.

View on GitHub

What's detected out of the box

  • API keys (common provider formats) and bearer tokens / OAuth secrets
  • Passwords and connection strings
  • Emails and phone numbers (context-boosted)
  • Credit cards, IBANs, and SSNs
  • Credentials embedded in URLs (always on, any profile)

Two honest edges: SSH/PEM private keys have no reliable regex signature — register them as secrets and they mask unconditionally, on every profile. Bare IPs, URLs, and MAC addresses live in the Network category, which is off in the default (Balanced) profile — enable it if your infrastructure topology is itself sensitive.

Need to mask PII, customer data, or code? Sordino Enterprise supports fully custom rules.

How masking works

Sordino is a hybrid: a reverse proxy is the data plane, and thin Claude Code hooks are the control plane. Your coding tool natively honors ANTHROPIC_BASE_URL, so there's no TLS interception and no certificates to install — the proxy simply re-originates a fresh TLS connection to the provider. When a request is about to leave your machine, Sordino scans its content surfaces — your typed prompt and the tool output the agent gathered — against its detection rules. Matches are replaced with deterministic tokens: the same value always maps to the same token within a project, which keeps multi-turn sessions coherent and the provider's prompt cache stable.

One proxy per project. Each project gets its own proxy on an OS-assigned ephemeral port, with its own key, salt, and token store — two projects can never collide or cross-contaminate a response, and concurrent claude sessions in different projects never interfere with each other.

The token ↔ value mapping is stored locally in an encrypted (AES-256-GCM) session store. When a response references a token, Sordino restores the original value locally before you see it. On the masked wires the proxy is fail-closed: mask or refuse — if masking fails, the request is rejected rather than forwarded unmasked. Sordino itself has no accounts, no cloud component, and no telemetry.

Go further

Configuration, the optional local ML model, building from source, and safe uninstall — expand only what you need.

Limitations

Stated plainly, because they shape what Sordino is for:

  • Detection is pattern-based (plus the optional ML model) — recall is not 100%. A value matching no recognizer and no custom rule goes through unmasked. Registered secrets are the exception: they mask unconditionally.
  • The scope is the LLM wire. Sordino is not a sandbox — an agent with shell access can still read local files — and it doesn't sit on non-LLM egress like a curl in a tool call or a git push.
  • Base64-encoded images/documents and file/batch upload endpoints pass through unscanned (masking would corrupt them).
  • Your coding tool's own local transcripts still contain plaintext — masking happens on the wire, not on your disk.

The complete, mechanism-cited version of this list lives in the project's threat model.