There are a couple of ways to reference sensitive data from Visual Studio Code (vscode) inside launch.json without including the data in the launch.json file.

• Environment Variables
• Input Variables : Prompt
• Input Variables : Custom Command

The vscode Variables Reference documents these solutions nicely.

Environment Variables (docs)

You can put your sensitive variables in an environment variable (perhaps loaded via your shell profile such as in .bash_profile for example). You can then reference it "through the ${env:Name} syntax (for example, ${env:USERNAME})."

{ "type": "node", "request": "launch", "name": "Launch Program", "program": "${workspaceFolder}/app.js", "cwd": "${workspaceFolder}", "args": ["${env:USERNAME}"] } 

Input Variables (docs)

Prompt for Input

You can prompt for sensitive information on launch by defining a promptString input type as seen in the below configuration extracted from the docs. Below ${input:componentName} is used as an argument and defined below in an inputs section as a promptString for prompting you for the value when you run the associated task.

{ "version": "2.0.0", "tasks": [ { "label": "ng g", "type": "shell", "command": "ng", "args": ["g", "${input:componentType}", "${input:componentName}"] } ], "inputs": [ /** skipping componentType definition for brevity -- see docs for that */ { "type": "promptString", "id": "componentName", "description": "Name your component.", "default": "my-new-component" } ] } 

The definition of a promptString is as follows:

• description: Shown in the quick input, provides context for the input.
• default: Default value that will be used if the user doesn't enter something else.
• password: Set to true to input with a password prompt that will not show the typed value.

Run a Custom Command for the Input

You can also run a custom command for getting the input. The docs use the following configuration as an example. Note that like other input types that the command must be defined in the inputs section with a type.

{ "configurations": [ { "type": "node", "request": "launch", "name": "Run specific test", "program": "${workspaceFolder}/${input:pickTest}" } ], "inputs": [ { "id": "pickTest", "type": "command", "command": "extension.mochaSupport.testPicker", "args": { "testFolder": "/out/tests" } } ] } 

The other options for the command type are:

• command: Command being run on variable interpolation.
• args: Optional option bag passed to the command's implementation.

I think the simplest solution might be to provide the path of a .env file in envFile attribute in the launch configuration in launch.json.

For example in the config below, I pass in the path of an env file named flowmazonapi.env that is kept next to launch.json in .vscode folder:

"configurations": [ { "name": ".NET Core: debug in full stack", "type": "coreclr", "request": "launch", "preLaunchTask": "build-backend", "program": "${workspaceFolder}/flowmazonbackend/flowmazonapi/bin/Debug/net9.0/flowmazonapi.dll", "cwd": "${workspaceFolder}/flowmazonbackend/flowmazonapi", "stopAtEntry": false, "envFile": "${workspaceFolder}/.vscode/flowmazonapi.env", "sourceFileMap": { "/Views": "${workspaceFolder}/Views" }, "requireExactSource": false }, 

The .env file itself looks like any .env file in the Node.js or Docker Compose ecosystem:

ASPNETCORE_ENVIRONMENT=Development ASPNETCORE_URLS=http://localhost:3022 ALLOWED_CORS_ORIGINS=http://localhost:3020 

The variables set in the .env file get set as environment variables for the process being launched.

Make sure to reference the env file containing secrets in .gitignore so it doesn't get checked in. I exclude all .env files in my solution by placing

*.env 

in my .gitignore, as most of them contain secrets.

Aside: If you are configuring a .NET Core project with a .env file in a VS Code launch configuration, see my post on dev.to which shows why, and how to, configure .NET Core projects using .env files.

I've used a workaround for this which is to use the dotenv package.

Thus instead of relying on VSCode to load the environment variables, they're being loaded from within the application itself.