Using with AI agents

hushenv was built for the moment you hand your project folder to an AI agent. Here is how to use it safely with the common tools.

The baseline: nothing to read

Once your secrets are in the vault and your .env holds only references, an agent scanning the repository finds no plaintext to surface. This alone is the bulk of the protection — there is simply nothing in the file.

Block the reveal command

hushenv get reveals plaintext, and its confirmation prompt already refuses a non-interactive agent shell. As defence in depth, add a deny rule so the agent can’t even attempt it. For Claude Code, in .claude/settings.json:

{
  "permissions": {
    "deny": ["Bash(hushenv get*)"]
  }
}

The same idea applies to Cursor and other agents that support command allow/deny lists.

Let the agent run your app

The agent can still run your application normally — it just can’t see the secrets:

hushenv run -- pnpm dev

The secrets are injected into the child process, not printed, not written to disk.

An honest limit

hushenv run -- env would print that project’s resolved secrets to stdout, where an agent could read them. This is the one gap. Per-project grants, coming in v1, will narrow the blast radius to a single project’s secrets. Treat hushenv run as you would any command that has access to your environment.

Cowork

Cowork runs on the same engine as Claude Code and reads the same .claude/settings.json. The deny rule above applies, and the references-only .env keeps secrets out of the folder it works in.