Securely Manage Environment Variables

Secure-by-default environment variable management for Claude Code sessions, built around Varlock (varlock.dev). Its core principle: secrets must never appear in terminal output, Claude's input/output context, log files, git diffs, or error messages. It enforces this with explicit dos and don'ts, e.g.:

# NEVER - exposes secret to Claude's context
echo $CLERK_SECRET_KEY
cat .env | grep SECRET

# DO - validates without exposing
varlock load --quiet && echo "Secrets validated"

Reading .env directly, echoing secrets in test commands, or embedding them in curl calls are all flagged as unsafe; the skill routes those actions through Varlock instead (varlock load, which shows masked values like API_KEY sensitive: masked, or varlock run -- curl ...).

Use it whenever a Claude Code session needs to work with environment variables or secrets - validating, loading, or auditing them - while keeping the values out of logs, diffs, and the assistant's own context.

Install:

tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
curl -sSfL https://varlock.dev/install.sh -o "$tmpdir/varlock-install.sh"
sh "$tmpdir/varlock-install.sh" --force-no-brew
export PATH="$HOME/.varlock/bin:$PATH"

Then initialize a project (varlock init) to generate a .env.schema from an existing .env. The schema defines type, validation, and sensitivity per variable, e.g. @type=string(startsWith=sk_) @required @sensitive for a Stripe secret key, with a @sensitive annotation that redacts a variable in all output.

Anyone using Claude Code on a project with real secrets in its environment, who wants a workflow that structurally prevents those secrets from leaking into the assistant's context or command history.

The .env.schema file uses annotations for security and type validation. Security annotations: @sensitive redacts a variable in all output (API keys, passwords, tokens); @sensitive=false shows it in logs (public keys, non-secret config); @defaultSensitive=true marks every variable sensitive by default, for high-security projects. Type annotations validate values: @type=string, @type=string(startsWith=sk_) for prefix checks, @type=string(contains=X) for substring checks, @type=url, @type=port (1-65535), @type=boolean, and @type=enum(dev,prod) for a closed set of values.

• Validate before operations: varlock load --quiet || { echo "Environment validation failed"; exit 1; }, then proceed with the real command.
• Running commands with secrets: varlock run -- npm start injects validated env into the command; secrets are available to the process but never printed.
• Safe secret rotation: update the secret in its external source (1Password, AWS, etc.) and in .env manually (deliberately NOT via Claude), then validate with varlock load.
• CI/CD integration: in GitHub Actions, pull secrets from secrets.* context and run varlock load --quiet to validate without printing them.
• Docker integration: install Varlock in the image via its install script, then CMD ["varlock", "run", "--", "npm", "start"] so validation happens at container start.