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
.sfdxfolder
π§° 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
| Purpose | Location |
|---|---|
| Global org authorization | ~/.sfdx/ or %LOCALAPPDATA%\sfdx\ |
| Project-specific environment data | <your-project>/.sfdx/ |
| Project configuration | sfdx-project.json |
| Default org setting | Stored 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.