Question 1

Does it work with a company HTTP proxy?

Accepted Answer

Tokenhush does not add a proxy of its own, and the strict config schema has no proxy key. The gateway makes a normal outbound HTTPS connection to the provider origin you configure, so it needs the same outbound reachability your tool has. If access in your environment goes through a corporate proxy, treat the gateway like any other CLI on the machine.

Question 2

Does Tokenhush see my keys?

Accepted Answer

Yes, in process and in memory: it has to read each request body to find and replace secrets. What it never does is persist them. No request or response bodies, no detected secrets, and no placeholder-to-secret mapping are written to disk. The redaction log is masked and goes to stderr only.

Question 3

Does it slow me down?

Accepted Answer

It runs in the request path on loopback, walks the request body, and forwards it to the provider. It does not terminate TLS and adds no network hop beyond the one your tool already makes. Measured overhead is not published yet, so treat any figure you see as unverified.

Question 4

Does it work offline?

Accepted Answer

The gateway binds loopback and forwards to the provider you configured, so it needs the same network reach your tool needs. Its own vendor-bound requests are exactly two, both command-scoped and switchable off: update check runs only on tokenhush update, rule sync only on tokenhush rules sync. Beyond those two, the gateway makes no other outbound request of its own.

Question 5

Does it write secrets to disk?

Accepted Answer

No. The only files it writes are metadata: run.json (pid, port, addrs, started_at), the 0600 control token, the verified rules cache, and the update anti-rollback mark. Bodies and the placeholder mapping stay in memory. The session files under the data directory are removed on a clean shutdown.

Question 6

How do I install Tokenhush?

Accepted Answer

macOS: brew install --cask fregie/tap/tokenhush. Linux: curl -fsSL https://raw.githubusercontent.com/fregie/tokenhush/main/install.sh | bash. Windows: irm https://raw.githubusercontent.com/fregie/tokenhush/main/install.ps1 | iex. The Linux and Windows installers verify the archive's sha256 against the release checksums.txt before installing anything, need no admin rights, and accept a pinned version. To build from source instead, use Go 1.25 or newer with go build -o tokenhush ./cmd/tokenhush.

Question 7

Where do the two vendor requests go, and can I turn them off?

Accepted Answer

Both go to updates.tokenhush.com. Both are command-scoped: update check runs only on tokenhush update, rule sync only on tokenhush rules sync, and each short-circuits before any network call when its switch is set. Retention for both is 30 days. Switch them off with TOKENHUSH_NO_UPDATE_CHECK=1 and TOKENHUSH_NO_RULE_SYNC=1. tokenhush privacy prints the disclosure.

Question 8

Which platforms are supported, and how do I keep the gateway running?

Accepted Answer

macOS, Linux, and Windows, each on arm64 and amd64. The binary is pure Go built with CGO_ENABLED=0, so it cross-compiles cleanly and needs no C toolchain. Start it with tokenhush run. There is no built-in service command: to keep it running across logins, wrap tokenhush run in your operating system's own tooling — a launchd agent on macOS, a systemd user unit on Linux, or a Task Scheduler entry on Windows. TOKENHUSH_HOME moves config and data to one root.

Question 9

Will it break my tool's function calling?

Accepted Answer

The five detectors on by default are the conservative set. entropy is off by default precisely because its false positives on long tool names and session ids broke function calling in testing; leave it off unless your workload carries no images, data URLs, or long random identifiers. Placeholders are stable per session and restored on the response path, so the tool still receives the values it sent.

Tokenhush FAQ