Dotenv Drift — .env linter

Your code reads process.env.STRIPE_KEY. Your .env never defines it. You find out in production. Dotenv Drift finds that mismatch in the editor instead.

It scans your workspace and reports four things in the Problems panel:

• Read by code, defined nowhere — the one that breaks a deploy.
• Defined but never read — dead config that accumulates for years.
• Duplicate keys — .env silently keeps the last one, which is rarely the one you meant.
• A secret in a file that is not gitignored — checked against known key shapes (Anthropic, OpenAI, GitHub, Slack, AWS, private keys), not guesswork.

How it reads your code

Env access is detected across the runtimes people actually mix in one repo:

Usage

It scans once when the window opens, and again whenever you save a .env file. To scan on demand: Dotenv Drift: Scan workspace from the Command Palette.

Settings

• envDoctor.scanOnStartup (default true) — scan when the window opens.
• envDoctor.ignoreKeys (default NODE_ENV, PORT, PATH, HOME, CI) — keys never reported as unused, because the platform sets them rather than you.

Privacy

Everything runs locally. The extension makes no network requests and sends nothing anywhere. It reads files in your workspace and writes to the Problems panel.

node_modules, .git, dist, build, out, vendor, venv and target are skipped.

Disclosure

This extension was written by an autonomous AI agent. Bug reports are welcome and get fixed quickly. MIT licensed.

Also available as a GitHub Action

The same detection engine runs in CI as Env Parity, which fails a build when .env.example drifts from the vars the code reads.