Programming
Managing development credentials with Locket

I wanted a CLI tool for storing and sharing credentials across a development team. API keys, database passwords and other secrets often end up in plaintext .env files. With AI coding agents reading project files and command output, I wanted a better way to manage what those tools could see.
There were already solutions for encrypting and sharing secrets, but they did not fit the workflow I wanted. I built Locket around an encrypted vault on each developer's machine, with explicit rules for which commands can receive credentials and encrypted sharing between teammates.
Keeping values outside the project
Locket stores secret values in a local encrypted vault backed by SQLite. The project keeps a locket.toml file with configuration, secret names and command policies. Those rules can be reviewed in Git and shared with the team. A names-only .env.example records which variables the application expects.
An existing project can start by importing its environment file:
locket init --name my-app --profile dev
locket import .env
locket statusThe status and list commands show metadata without printing credential values. Importing also does not silently remove the original plaintext file. Locket asks for confirmation before deleting .env, so that copy still needs to be dealt with when moving the application to the new workflow.
Giving credentials to a command
I wanted access to be tied to the work being done. A command policy declares what to run and which credentials it needs:
locket policy add dev -- npm run dev
locket policy require dev DATABASE_URL
locket run devLocket resolves the selected policy and injects its credentials into the child process environment for that invocation. The values are not exported into the parent shell. This keeps the application working with ordinary environment variables while moving storage and access decisions into Locket.
Profiles separate sets of credentials, and command and path rules can restrict where a secret is delivered. In a monorepo, the API package can request its database credentials while another package has a different set of required variables.
Sharing with a team
Sharing was part of the original reason for building it. Locket uses encrypted invites and bundles addressed to trusted devices. A team invite names the recipient device, the profiles being shared and the member's role. Sealed export and import also support moving credentials between a developer's own machines.
That gives a team a way to exchange encrypted files without running a secrets server or copying plaintext values into a message. Each developer keeps a local vault, and the transfer goes to the intended devices.
Working with AI coding agents
I wanted an agent to understand how a project is configured without needing the actual API keys. Locket can produce project context containing secret names and policy metadata, scan for accidental leaks, and redact command output before it is shared:
locket context
locket scan --require-known .
locket ai-safe -- npm testlocket context emits metadata without values. The scanner can check for credentials already stored in the vault as well as common token patterns and high-entropy strings. With --require-known, it requires access to the known values rather than quietly skipping that part of the scan when locked.
locket ai-safe captures and redacts a command's standard output and error output. It is useful for preparing test or diagnostic output for an agent. An application still receives plaintext credentials in its own process, so the command receiving them needs to be trusted. Output redaction does not control its file or network access.
Getting started
Locket is written in Rust for macOS, Linux and Windows. The CLI works with existing commands and includes runner adapters and Docker and Compose helpers. It is focused on local development; CI and production can keep using their platform's secret store.
The project currently installs from source:
git clone https://github.com/doublesharp/locket.git
cd locket
cargo install --path crates/locket-cliThe library page has an overview, and the README covers project setup, policies, team sharing and the other CLI workflows.