To find leaked secrets in VS Code before you commit, install the Safeguard extension, sign in, stage your changes, and run the command "Safeguard: Check Staged Commit for Secrets" from the Command Palette. If it flags a live credential, revoke and rotate it. Deleting the line is not enough.
How do you set it up?
The extension is on the VS Code Marketplace. From a terminal you can install it with:
code --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension
You can also open Extensions with Cmd+Shift+X on a Mac or Ctrl+Shift+X elsewhere, search for Safeguard and click Install. The extension activates when your workspace contains a manifest such as package.json, requirements.txt, pom.xml, go.mod, Cargo.toml or a Gemfile.
Sign in by running "Safeguard: Login" from the Command Palette. A browser tab opens at app.safeguard.sh with a verification code. Approve the device, return to the editor, and your tenant is filled in for you. The extension uses OAuth 2.0 device flow and keeps tokens in the IDE's credential storage. Device codes expire after about ten minutes, so rerun the login command if it times out.
What to do: how do you run the secrets check?
- Stage the files you plan to commit, in the Source Control view or with git add.
- Open the Command Palette with Cmd+Shift+P or Ctrl+Shift+P.
- Run "Safeguard: Check Staged Commit for Secrets".
- Read the findings, and fix before you commit.
The Safeguard docs describe the detection behind it. There are issuer-specific patterns for more than 200 providers and services, generic patterns for things like private keys, JWTs and connection strings, and an entropy layer for random-looking strings. For issuer-specific matches Safeguard can verify a key by making a low-privilege call to the issuer. A verified finding means the key was live at the time of the check. An unverified one is a pattern match that still deserves a look.
What does a finding mean for severity?
According to the docs, severity follows verification and privilege. A verified high-privilege credential, such as a cloud admin key, is critical. A verified lower-privilege credential is high. An unverified match for a known issuer is medium, and a generic or entropy-only match is low. Use that to order your work: handle the verified keys first.
Try the walkthrough at /demos/secrets-scanning.
What if the secret is already committed?
Then assume it is exposed. The order matters:
- Revoke the credential at the issuer, so it stops working.
- Rotate it and put the new value in a secret manager, not in the repo.
- Look at your repository history and at any place the code was copied or built, such as container images and CI logs.
- Only then consider rewriting history. A force push affects every collaborator, and it does not undo copies that already exist.
What are the limits?
Be honest about three things. First, a scan on staged files will not catch a secret that is stored somewhere else, such as an environment file you never stage. Second, the Safeguard docs say the IDE extension is the pre-push guard and that there is no CLI command yet for installing a git hook, so do not expect protection from commits made outside the editor. For a whole working tree, the docs give a CLI command, shown below. Third, an allowlist exists for fake keys in documentation and tests. Use it sparingly, because every entry hides a finding. Allowlist entries are tracked, so you can see who added each one.
safeguard detect --detect secrets
Quick check
Does deleting the secret in a new commit fix the leak?
No. The old commit still holds the value, and anyone with a clone can read it. Revoke and rotate the credential first.
Do I need to sign in for the check to work?
Public package scanning works without signing in, but some backend features need a login. Sign in so you get the full set of features, and rerun the login command if the code expires.
Sources
Last reviewed: 18 October 2026.
