Inside CmdVault’s Credentials Vault: Argon2id, AES-256-GCM & Scoped Environments
Managing API keys, database credentials, and production tokens in developer environments is traditionally fraught with risk. Developers often hardcode parameters into local script files or copy plaintext credentials into temporary shell scripts. CmdVault solves this through its local Credentials Vault.
Argon2id key derivation. Private values are encrypted using AES-256-GCM authenticated encryption before being stored in the local SQLite vault database.Environment Scoping & Bulk .env Import
Variables in CmdVault are explicitly scoped by environment: Local, Staging, or Production. Updating a variable preserves its assigned scope, preventing accidental demotion of production configurations to local defaults.
With the bulk .env import tool, you can paste raw key-value files into the active environment. CmdVault automatically detects key names that resemble sensitive tokens (e.g., *_SECRET, *_PASSWORD, *_TOKEN, DATABASE_URL) and encrypts them before writing. Existing entries upsert cleanly by key name rather than creating duplicate entries on re-import.
Execution Safety Interceptor
Before any recipe or command reaches the terminal execution layer, CmdVault passes the raw string through the Execution Safety Engine. This engine uses regular expressions to detect destructive commands—such as rm -rf /, dd if=, mkfs, and disk formatting attempts.
Users can define custom blocklists, and any sudo invocation triggers a mandatory confirmation modal before execution proceeds.
Opt-In Auto-Lock & Device Key Management
Auto-lock runs on a 15-minute inactivity timer with rate-limited master password attempts. In modern CmdVault builds, auto-unlock on launch is entirely opt-in ("Stay unlocked on this device"). When enabled, CmdVault stores only the derived device key in the system keychain—never the master password itself.