πŸ” Understanding Where Salesforce (SFDX) Environments Are Stored in VS Code

When you’re working with Salesforce DX (SFDX) in Visual Studio Code, you often connect to multiple Salesforce orgs β€” such as Developer Orgs, Sandboxes, or Scratch Orgs.
But have you ever wondered where these environments are actually stored?

Let’s break it down in simple terms πŸ‘‡


🧩 What Are Salesforce (SFDX) Environments?

In SFDX, β€œenvironments” refer to the Salesforce orgs you’ve authorized for development or deployment.
Each time you run a command like:

sfdx force:auth:web:login -a DevHub

you’re creating a local authorization record on your system that tells VS Code (via the Salesforce CLI) how to connect to that org.


πŸ—‚οΈ Where Are These Environments Stored?

All your connected Salesforce environments are stored locally by the Salesforce CLI β€” not inside VS Code itself.

The exact location depends on your operating system:

πŸͺŸ On Windows:

C:\Users\<your-username>\sfdx\

🐧 On Linux / macOS:

~/.sfdx/

Inside this folder, you’ll find JSON files containing information about each authorized org, such as:

  • Access tokens
  • Instance URLs
  • Aliases
  • Username details

For example, you might see files like:

auth.json
DevHub.json
MySandbox.json

These represent the Salesforce orgs you’ve connected to.

Note: Aliases are storied in alias.json


βš™οΈ How VS Code Uses These Environments

VS Code itself doesn’t store your environment details β€” instead, it uses the Salesforce CLI (sfdx) to fetch and manage them.

When you open your Salesforce project in VS Code:

  • It reads the project structure from sfdx-project.json
  • It looks for your default org (specified in the same file or via CLI)
  • It communicates with the org using credentials stored in the .sfdx folder

🧰 Viewing Your Authorized Orgs

To see all your connected environments, run:

sfdx force:org:list

This command displays:

  • Aliases (friendly names you set)
  • Usernames
  • Org IDs
  • Connected status
  • Expiration date (for scratch orgs)

Example output:

=== Orgs
     ALIAS        USERNAME                    ORG ID              CONNECTED STATUS
 ───  ───────────  ──────────────────────────  ──────────────────  ───────────────
     DevHub        admin@mydevhub.com          00D5g00000XXXXXXX   Connected
     MySandbox     sandbox@appohm.com          00D9H00000YYYYYYY   Connected


🧹 Removing Unused Environments

If you no longer need an org, you can remove its local authorization using:

sfdx force:auth:logout -u <username or alias>

To remove all authorized orgs:

sfdx force:auth:logout --all

This clears the corresponding files from the .sfdx directory.


πŸ’‘ Pro Tip: Setting a Default Org

You can set your default org (used for push, pull, and deploy commands) with:

sfdx force:config:set defaultusername=<alias>

To verify:

sfdx force:config:get defaultusername


πŸ“ Project-Specific Environment Data

Each SFDX project also contains a hidden folder:

<your-project>/.sfdx/

This folder stores environment-specific metadata for that particular project, including:

  • Local scratch org settings
  • Cached connection details

It’s safe to delete this folder when cleaning your workspace β€” it will be recreated as needed.


βœ… Summary

PurposeLocation
Global org authorization~/.sfdx/ or %LOCALAPPDATA%\sfdx\
Project-specific environment data<your-project>/.sfdx/
Project configurationsfdx-project.json
Default org settingStored via sfdx force:config:set

🧠 Final Thoughts

Your Salesforce environments are not stored in VS Code itself, but rather managed by the Salesforce CLI.
VS Code simply acts as the development interface, reading your CLI configurations to connect, push, and retrieve metadata seamlessly.

Next time you switch orgs or clean your setup, you’ll know exactly where those environment details live and how to manage them safely.

Published by Sandeep Kumar

He is a Salesforce Certified Application Architect having 11+ years of experience in Salesforce.

Leave a Reply