Secrets-LE: Zero Hassle Secret Detection

Find hardcoded credentials across your workspace, then redact them in place
API keys, tokens, passwords, private keys — 100% local, nothing leaves your machine

Useful? A star or rating is how other developers find it — ★ GitHub · ★ Open VSX · ★ Marketplace

What it does

Open a workspace, press Ctrl+Alt+S (Cmd+Alt+S on Mac), and every detected secret lands in a results document — grouped by file, with line/column positions pointing at the value itself. Run Secrets-LE: Sanitize Secrets to replace the secrets in the active file with a placeholder. Works in VS Code and in VS Code–based editors like Cursor and VSCodium (installable from Open VSX).

Detection is regex-based over the full text of each file, so it works on any text format — code, configs, .env files, YAML, JSON, logs. It is a pre-commit safety net, not a guarantee: a scanner built on patterns can miss secrets and can flag non-secrets. Review the results.

Install

Use it from an AI agent

The same engine runs as an MCP server, so an agent can call it directly instead of you running a command.

detect_secrets(content, sensitivity?, includeApiKeys?, includePasswords?, includeTokens?, includePrivateKeys?, maxResults?)

Reports each finding by type, confidence, key name and 1-based position. Values are never returned — previews are truncated and length-annotated, and the context line has the secret masked out, so a finding can be located without the credential leaving the machine it was found on.

The server takes content and returns data — it reads no files and makes no network requests of its own. Published as secrets-le-mcp on npm and as io.github.nolindnaidoo/secrets-le in the MCP registry.

{
  "mcpServers": {
    "secrets-le": {
      "command": "npx",
      "args": ["-y", "secrets-le-mcp"]
    }
  }
}

npm install -g secrets-le-mcp

{
  "mcpServers": {
    "secrets-le": { "command": "secrets-le-mcp" }
  }
}

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y secrets-le-mcp

The CLI

The same detection runs from a terminal or a CI step: a Rust CLI in crate/, sharing one pattern table with the extension — crate/signatures/patterns.toml — so the two can never disagree about what counts as a credential.

secrets-le .                        # scan a tree
secrets-le --sensitivity high .     # only high-confidence findings
secrets-le --no-ignore --hidden .   # reach .env and everything git ignores
secrets-le mcp                      # the same detection over MCP on stdio

The exit code is the answer: 0 nothing found · 1 findings · 2 the question was malformed — so secrets-le . is a CI step as it stands.

It never prints a credential. A scanner's output goes into a CI log, which is archived, often world-readable, and outlives the secret; a scanner that printed what it found would disclose it more widely than the commit would have. Previews are capped at eight characters and at half the value's length, context lines are masked, and there is no flag that changes either. The extension is the half that can fix what it finds; the binary only reports.

What gets detected

Thirty-four patterns, in crate/signatures/patterns.toml — the one table both frontends load.

Key-based patterns accept quoted and unquoted keys, so JSON ("apiKey": "…"), YAML (api_key: …), env (API_KEY=…), and code (apiKey = '…') all match.

Intentional non-detections: template placeholders (${VAR}, {{var}}, <your-key>, xxxxxxxx), version numbers and hostnames that merely look dotted (1.2.3 is not a JWT), GCP project ids (identifiers, not credentials), and database URLs without embedded credentials.

Known limitations: detection is pattern-based — obfuscated, split, or unconventionally named secrets are missed; JWTs whose header isn't standard base64 JSON (eyJ…) are missed; a high-entropy string without a recognizable key name or prefix is not reported.

Commands

Settings