← All articles

Secrets in IDE Config and Editor Files: The Credentials Hiding in .vscode, .idea, and dotfiles

June 28, 2026

The Credential Risk You're Committing Every Day Without Noticing

When developers think about leaked secrets, they think about .env files or hardcoded strings. Rarely do they think about the folder their editor silently created the moment they opened the project. Yet .vscode/, .idea/, and a sprawl of dotfiles are committed to repositories every day — and they frequently carry credentials along for the ride.

This isn't a theoretical risk. It's a routine finding during security audits: a launch.json with an environment variable containing a database password, a JetBrains run configuration with an embedded AWS key, or a shell history file in a dotfiles repo exposing a curl command with a Bearer token. The exposure surface is wide and the signal is quiet.

Where Exactly Do These Files Carry Secrets?

VS Code: .vscode/launch.json and .vscode/settings.json

VS Code's launch configurations let developers inject environment variables directly for debugging sessions. It's convenient — and dangerous when committed.

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "name": "Launch API",
      "env": {
        "DATABASE_URL": "postgres://app:s3cr3tpassword@prod-db.internal:5432/app",
        "STRIPE_SECRET_KEY": "sk_live_xxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  ]
}

This file lives inside .vscode/launch.json. It's not a .env file, so it often escapes .gitignore rules that only target .env. Many teams add .vscode/ to .gitignore at the workspace level — but that protection disappears when someone explicitly stages the file, or when a new repo is created without inheriting the global gitignore.

.vscode/settings.json can expose secrets too: REST client extensions (like the popular "REST Client" for VS Code) allow variable definitions directly in settings, and developers sometimes store real API keys there for quick testing.

JetBrains IDEs: .idea/ Run Configurations

IntelliJ IDEA, PyCharm, GoLand, and other JetBrains products store run configurations as XML inside .idea/runConfigurations/. Environment variables defined in a run config are written to these XML files in plaintext.

<configuration name="Run Server">
  <envs>
    <env name="OPENAI_API_KEY" value="sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" />
    <env name="SENDGRID_API_KEY" value="SG.xxxxxxxxxxxxxxxxxxxxxxxxxxxx" />
  </envs>
</configuration>

JetBrains' own documentation recommends against committing the .idea/ folder in its entirety. Despite this, countless public and private repositories contain the full folder because teams share run configurations for convenience — a legitimate use case that silently bundles secrets.

Dotfiles Repositories

The developer practice of maintaining a public dotfiles repo on GitHub to sync shell configs across machines is widely celebrated. It's also a reliable way to expose credentials. Files that commonly carry secrets include:

  • .bashrc / .zshrc — export API_KEY=... lines added for convenience
  • .netrc — stores credentials for HTTP clients and package registries in plaintext
  • .aws/credentials — AWS access keys; sometimes accidentally included in dotfiles syncs
  • .config/gh/hosts.yml — GitHub CLI OAuth tokens
  • .npmrc / .pypirc — registry authentication tokens
  • .gitconfig — can contain credential helper configurations that expose tokens

When a developer makes their dotfiles repo public (common, for sharing with the community), these files become globally readable. Even in private repos, a misconfigured access policy or a future change to org visibility settings can expose them instantly.

Shell History Files

Shell history files (.bash_history, .zsh_history) are occasionally included in dotfiles repos. A single curl command or CLI invocation with an inline secret is enough:

curl -H "Authorization: Bearer ghp_xxxxxxxxxxxxxxxxxxxx" https://api.github.com/user
aws s3 ls --aws-access-key-id AKIA... --aws-secret-access-key ...

These are real credentials, in context, ready to be replayed by anyone who finds them.

A Practical Checklist: Locking Down IDE and Editor Files

1. Audit Your Global and Repository .gitignore

Your global gitignore (typically at ~/.config/git/ignore or ~/.gitignore_global) should include:

# IDE and editor configs
.vscode/
.idea/
*.iml
*.iws
*.ipr

# Shell and tool configs that may carry secrets
.netrc
.bash_history
.zsh_history
.env.local
.aws/credentials
.config/gh/

For repository-level .gitignore, be specific: if your team shares some VS Code settings legitimately (e.g., recommended extensions), explicitly ignore only the risky files:

.vscode/launch.json
.vscode/settings.json
.idea/runConfigurations/

2. Move Secrets Out of Editor Configs Entirely

The root fix is not ignoring files — it's not storing secrets in them in the first place. Use a proper secret injection mechanism instead:

  • For local development: Store secrets in a .env file (not committed), and load them with dotenv or equivalent. Then reference ${env:DATABASE_URL} in your launch.json rather than hardcoding the value.
  • For team environments: Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password Secrets Automation) and inject values at runtime.
  • For CI/CD: Keep run configuration XML files out of version control entirely; generate them from templates or use environment-specific overrides.

3. Scan Before You Push

Add a pre-commit hook to catch secrets before they ever leave your machine. Tools like detect-secrets or gitleaks can be configured as pre-commit hooks and will flag high-entropy strings and known key patterns in any staged file — including XML run configurations and JSON launch files.

# Install gitleaks as a pre-commit hook
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.2
    hooks:
      - id: gitleaks

4. Audit What's Already in Your Repository History

If your team has been committing .idea/ or .vscode/launch.json for months or years, assume secrets are already in your history. Purging them requires more than just deleting the files — the git history must be rewritten using git filter-repo or BFG Repo Cleaner, and all existing clones and forks must be refreshed.

Before that surgery, you need to know what's actually exposed. To run a free GhostCred scan takes about 60 seconds and surfaces secrets across your repo and history — including in XML configs and dotfiles — mapped to the compliance controls (SOC 2, HIPAA) that require you to act on them.

Why This Keeps Happening

The root cause is a mismatch between developer workflow and security posture. Developers add environment variables to run configurations because it's fast and it works. The IDE makes it easy. Nothing warns them at commit time. The secret sits in version control, usually in a private repo, until something changes — a repo goes public, an employee leaves, a GitHub token gets over-scoped, or a breach at a third party exposes the repository contents.

The fix is systemic, not individual. Global gitignore defaults, pre-commit hooks, secret reference syntax (rather than inline values) in editor configs, and periodic scanning of historical commits together close the gap. No single measure is enough on its own.

Key Takeaways

  • .vscode/launch.json and .idea/runConfigurations/ store secrets in plaintext and are frequently committed accidentally.
  • Public dotfiles repositories are a well-known but underappreciated credential leakage vector.
  • Global and per-repo .gitignore rules must be explicit — broad patterns get overridden.
  • The correct fix is reference-based config (point to env vars, not their values) combined with pre-commit scanning.
  • If these files have ever been committed, treat them as already exposed and rotate any credentials they contained.

See what's exposed in your own code.

Run a free scan