honmoon-redact

honmoon-redact keeps API keys and personal identifiers out of Claude Code’s model context and out of the session transcript on disk. It rewrites the output of Read, Bash, Grep and WebFetch with stable placeholders before the model reads it, submits a redacted copy of a prompt that carries a secret, and refuses to open known credential files at all. Detection runs in honmoon, a Rust binary you install separately; the plugin is a thin shell around it.

Honmoon itself is a policy gateway, a proxy between an AI agent and the network. The proxy cannot reach what Claude Code writes to its session .jsonl before sending, which later feeds /resume, compaction and subagents; the plugin covers that.

Install

Verified by the author on Claude Code 2.1.263 with function hooks enabled. Needs the honmoon binary on your PATH: prebuilt on the Releases page for Linux x86-64, Linux arm64 and macOS on Apple silicon, or cargo install --path crates/honmoon-cli from the checkout. There is no marketplace yet; load the plugin from the clone.

git clone https://github.com/pleaseai/honmoon
claude --plugin-dir ./honmoon/packages/claude-plugin

Nothing to run afterwards; /hooks lists the three command hooks.

How it works

Two hooks. tool.call, matched on Read, Bash, Grep and WebFetch, resolves the session id and working directory, then asks the engine before a Read whether the path is a known credential store: .env*, *.pem, *.key, id_rsa, id_ed25519 and ~/.aws/credentials are denied before the file opens, while .env.example is allowed. Then the tool runs. Its result goes to the engine and comes back as the same record with every detected value replaced by a <<hs:…>> token, plus a context line for the model, honmoon: N value(s) redacted with stable placeholders. Text and notebook Read results are scanned, images and PDFs are not, and a failed command’s stderr is scanned and returned to the model as an error.

prompt.submit runs your prompt through the same detector. If the engine rewrites it, the redacted text is submitted with the same context note. The detectors match vendor-shaped keys such as sk-ant-, AKIA and ghp_, PEM private key blocks, keyword-anchored generic secrets, and identifiers including resident registration numbers, email addresses and phone numbers.

Where your text goes depends on the transport option. The default, process, runs honmoon hook as a local subprocess through $.process.run and feeds it the prompt or tool output on stdin, so nothing leaves the machine. With transport: "http" the same JSON is POSTed through $.http.fetch to hookUrl, the management API of a running Honmoon gateway, with a bearer token; the documented deployment is a gateway on the same host. Redaction is one-way: unlike secret-redactor, which restores the real value when a tool needs it, honmoon-redact keeps no reverse mapping on the client path.

Placeholders are an HMAC keyed by a random per-machine key at ~/.honmoon/hook-salt (mode 0600, created by the binary; the module writes nothing to disk) and mixed with the session id, so one secret mints one token per session whichever hook saw it, and the provider’s prompt cache prefix survives across turns. If the binary cannot read or create the key it falls back to a constant published in the repository: placeholders stay stable but anyone can forge them. Export HONMOON_AUDIT_LOG to record such degradations in a JSONL file; failing that, the module shows the line through $.ui.log, which the model does not see.

When the engine is unreachable the module fails closed by default: the tool result is withheld with honmoon: redaction engine unavailable and the prompt is dropped. Each hook phase has an 8 s budget inside the host’s 10 s limit; whatever is still pending then fails closed too. failMode: "open" passes through instead.

The author checked on Claude Code 2.1.263 that a session which read a file holding a valid RRN and an Anthropic-shaped key kept no raw copy of either in its .jsonl.

Command hooks and the module together

hooks/hooks.json also declares three classic command hooks on PreToolUse, PostToolUse and UserPromptSubmit, all calling the same honmoon hook. Without the flag only those run, and they differ: a command hook cannot rewrite a prompt, so it blocks one that carries a secret; it only acts at the high severity floor, so emails and phone numbers in prompts pass; it does not cover WebFetch; and if the binary is missing it fails open. With the flag on both layers fire on the same call: the command hook redacts first, inside the module’s next(), and the module finds nothing left, so the transcript carries one set of placeholders. Remove the hooks key from hooks/hooks.json to run the module alone.

Options

Set with /plugin configure honmoon-redact or under pluginConfigs["honmoon-redact"].options in your user, --settings or managed settings. Project settings are not read.

• transport: process (default while hookUrl is unset) or http.
• honmoonBin: the binary the process transport runs, default honmoon. The command hooks read HONMOON_BIN instead, so set both if it is off PATH.
• hookUrl: the management API endpoint, for example http://127.0.0.1:7777/api/hooks/claude-code. Setting it selects http.
• hookToken: bearer token for hookUrl, required as of honmoon 0.1.0.
• failMode: closed (default) or open.

Limitations

• The detectors are precision-first. A private key printed without its -----END footer, as head -5 id_rsa does, is not matched; the deny on whole key files is the guaranteed path.
• The generic-secret detector treats a value containing example, changeme or test as a placeholder, so a real high-entropy secret with one of those substrings can pass. Vendor-shaped keys do not consult that list.
• Only the tool output is rewritten. The hook’s raw stdin is not persisted on 2.1.263, but that is an implementation detail, not a documented guarantee: re-run the author’s transcript check on other versions.
• The command hooks ship only the process transport. Their HTTP transport is planned; the module already has one.