Secret Locker

Real secrets for humans. Safe context for AI.

A local-first VS Code extension that keeps real environment values encrypted while developers and approved commands continue to work normally.

AI coding tools are useful, but an unrestricted workspace can expose .env and local configuration credentials through file reads, search, indexing, diffs, or accidental Git staging. Secret Locker replaces protected values in the workspace with deterministic synthetic values, stores the originals in authenticated local vaults, and maintains a required external plaintext recovery copy selected by the user.

Developers can inspect or edit real values in a purpose-built secure view. Approved development commands receive only the variables explicitly allowed for that command and folder.

What Secret Locker provides

How it works

Real .env values
      │
      ├── encrypted locally ──> per-file AES-256-GCM vault
      ├── mirrored plainly ───> required external recovery folder
      │
      └── replaced on disk ──> deterministic synthetic values
                                      │
                         ordinary editors, Git, search, AI

Approved command + matching folder + selected keys
      └── signed local policy ──> real values injected into that child process

The extension owns enrollment, secure editing, recovery, sharing, and policy configuration. A minimal bundled native helper validates signed command rules and injects only selected values into matching child processes. It does not expose a public secret-reading CLI.

Quick start

1. Install Secret Locker and open a trusted workspace.
2. Open the Command Palette and run Secret Locker: Protect Environment File.
3. Select the required plaintext recovery folder outside every workspace, Git repository, shared folder, and unencrypted cloud-sync location.
4. Choose the .env file to protect and save the recovery key in a password manager outside the repository.
5. Open Secret Locker: Open Security Center to choose authentication, manage protected files, and configure approved commands.
6. Use the preview icon in an ENV editor title, or press ⌘⌥R on macOS (Ctrl+Alt+R elsewhere), for the timed read-only view.

New ENV files are protected only when you explicitly enroll them. Automatic protection is available as an opt-in setting.

Mandatory plaintext recovery folder

Secret Locker will not protect, import, or save real values until a separate recovery folder is configured. The selected folder must be completely outside every open VS Code workspace; neither a workspace may contain it nor may it contain a workspace.

Backups use an approachable mirrored structure:

Selected recovery folder/
├── Project A/
│   ├── .env
│   ├── .env.production
│   ├── apps/api/.env
│   ├── RECOVERY-INSTRUCTIONS.txt
│   └── .secret-locker-backup.json
└── Project B/
    └── .env

Projects with the same folder name receive a short hash suffix to prevent collisions. Each backup is written atomically, verified after writing, and restricted to the current OS user where supported. After uninstalling Secret Locker, copy the required files from this mirror back to their matching project paths.

These recovery files are intentionally not encrypted by Secret Locker. Any process that can access the selected folder can read them. Use an encrypted disk or independently encrypted storage, and never select a source repository, AI-accessible workspace, shared folder, or unencrypted cloud-sync directory.

Custom protected files

Open the Security Center and select Customize under Protected file patterns. Secret Locker always includes common ENV conventions plus secret.local, secrets.local, and common secrets.*.js, CJS, and MJS names. Add up to 50 relative globs using names, folders, *, **, and ?.

Dotenv-compatible custom files protect every assignment. For JavaScript, TypeScript, or JSON object configs, Secret Locker protects only secret-classified static string properties. For example, GOOGLE_API_KEYS: "…" and PASSWORD: '…' are replaced while ENVIRONMENT: 'DEVELOPMENT' and ENABLE_LOCAL_CONFIG: false stay unchanged. Dynamic expressions and template literals containing ${…} are deliberately ignored.

Synthetic strings are deliberately readable and key-specific. For example, GOOGLE_API_KEYS="…" becomes GOOGLE_API_KEYS="Your_secret_locker_google_api_key". Providers that require strict formats, such as Stripe, AWS, GitHub, Slack, or database URLs, continue to receive clearly fake format-compatible values.

Static source configs have an important runtime limitation: an application importing the protected file reads its synthetic on-disk values. Environment injection cannot override a hard-coded object literal. Use environment-variable lookups in application code, or authenticate and turn folder protection off for a real-value launch.

Secure viewing and editing

• The structured dotenv editor masks values by default and supports per-value timed reveal.
• The raw secure editor handles bulk paste, additions, corrections, and deletions, and is used automatically for protected source configs.
• Saving re-encrypts the complete content and regenerates the synthetic workspace file.
• Secure views clear sensitive DOM content on expiry, blur, or inactivity where applicable.
• The ordinary VS Code tab always displays the synthetic file while protection is enabled.

Folder protection controls

The Security Center can disable protection for a selected folder after authentication. This deliberately restores enrolled ENV files as plaintext and pauses signed command injection for that folder. Enabling protection again re-encrypts the values using the existing local key.

Treat the disabled state as unprotected: ordinary extensions, AI tools, search, and Git may be able to read those plaintext files.

Approved development commands

Select Discover in the Security Center to read supported build manifests and task definitions. Secret Locker detects commands from:

• package.json scripts with npm, pnpm, Yarn, or Bun;
• Make, Taskfile, Just, Composer, Rake, and Docker Compose;
• Python pyproject.toml, Tox, Nox, Django, and scripts/ or tools/ programs;
• Maven, Gradle, Rust, Go, .NET, CMake, Meson, Swift, Elixir, and Dart projects.

Discovery is read-only: it never executes a command or authorizes a result automatically. The selection screen shows the exact command, working folder, ecosystem, source file, and underlying script or task definition. After selecting commands, choose the real variables each folder may receive and confirm the final rules.

Discovered entries become exact, non-recursive folder rules—not regex or wildcard permissions. Generated directories, dependencies, symlinks, nested protected projects, oversized sources, unsafe command syntax, and bounded-scan overflows are skipped.

Rules are workspace-scoped and contain:

• an exact command, safe glob, or anchored regular expression;
• a recursive folder scope; and
• the specific environment-variable names the command may receive.

When a new integrated terminal runs a matching command from an allowed folder, the bundled helper injects only the selected values into that child process tree. Non-matching commands run normally with synthetic values. Keep rules narrow, especially when an AI agent can execute commands.

Share an encrypted project folder

1. Protect the folder's ENV files and open the Security Center.
2. Choose Create sub-vault, select the folder, and select only the ENV files to include.
3. Share the folder normally. Its .secret-locker-project.vault sidecar contains the encrypted selection and applicable command rules.
4. Send the stable SECRET-LOCKER-PROJECT-… access code through a different secure channel.
5. The recipient opens the copied folder, chooses Load shared folder, and enters the code.

Never store the access code in Git, AI chat, logs, or beside the encrypted sidecar. Anyone holding both the sidecar and its code can decrypt that sub-vault. Rotating the code invalidates the previous code for future refreshed copies; this shared-code model does not provide per-recipient revocation.

Security boundary

Secret Locker reduces accidental disclosure and routine AI access; it is not an operating-system sandbox. It cannot protect a secret from:

• an administrator or root process;
• unrestricted malicious code or another extension running as the same OS user;
• screen or clipboard capture while a value is visible;
• a program authorized by an approved command rule; or
• terminal output produced by an authorized program.

Read the full security model before using Secret Locker for high-value production credentials.

Platform support

The TypeScript code includes cross-platform paths, but packaged native helpers must be built and validated separately before Linux, Windows, or macOS Intel command injection can be claimed as supported.

Development

Requirements: Node.js 20+, npm, Rust stable, and VS Code 1.85+.

npm ci
npm run lint
npm run build
npm test
npm audit --offline

cd native-helper
cargo fmt --all -- --check
cargo test --all-targets
cargo build --release

Copy the release helper into the appropriate bin/<platform>-<arch>/ directory, then run npm run package from the repository root.

Privacy, security, and licensing

• Public documentation and support: Secret Locker on GitHub
• Secret Locker has no telemetry and no runtime network requirement. See PRIVACY.md.
• Report vulnerabilities privately using the instructions in SECURITY.md.
• Secret Locker is available under the MIT License.
• Required upstream attribution is retained in NOTICE.

Author

Created and maintained by Shiv Awasthi.

This project includes modified MIT-licensed work from Cloak by Daniel Tamas. See NOTICE for details.