How to Use VS Code Variables in Settings, Tasks, and Debug Configurations

VS Code variables replace machine-specific values when a task or debug configuration runs. Instead of hardcoding a project path, use the workspaceFolder variable in a supported field and let VS Code resolve the open folder.

Variables work in tasks.json, launch.json, and selected settings, but not in every string field. A variable name goes inside dollar-sign braces, as shown in the examples below. Each configuration type decides which fields support it. See the official variables reference for the current list.

The most useful predefined variables

These variables are built into VS Code and work without any configuration:

Use IntelliSense inside a supported string value in tasks.json or launch.json to see the current predefined variables and descriptions.

Use variables in launch.json

The following complete launch.json needs Node.js and VS Code's built-in JavaScript debugger. It starts the active JavaScript file instead of storing an absolute program path.

json

{
  "version": "0.2.0",
  "configurations": [{
    "type": "node",
    "request": "launch",
    "name": "Launch current file",
    "program": "${file}"
  }]
}

Open a JavaScript file, choose Launch current file in Run and Debug, and start debugging. A debug session for the active file confirms that the variable resolved.

Use variables in tasks.json

Tasks support substitution only in the command, args, and options fields. This harmless echo task prints the resolved workspace path.

json

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Show workspace path",
      "type": "shell",
      "command": "echo",
      "args": ["${workspaceFolder}"]
    }
  ]
}

Run Show workspace path from Terminal > Run Task. The terminal should print the open folder's absolute path.

Environment variables

Use the env:NAME form to reference an environment variable that already exists in the VS Code process environment. The example below uses USERNAME, but you should substitute a variable that exists in the environment used to start VS Code.

json

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

This configuration object passes USERNAME as a normal program argument when that environment variable exists in the VS Code process. Environment variable names are platform-specific, so verify the name in your environment instead of assuming one name works everywhere.

Do not pass secrets through command arguments because they can appear in logs, terminal history, or process inspection. Use the runtime's supported secret or environment mechanism instead.

Configuration variables

Use the config:settingId form to reference a VS Code setting. For example, config:editor.fontSize reads the current font-size setting.

The destination field must support substitution and accept the resolved value. Configuration variables do not make an unsupported task or setting field substitutable.

Multi-root workspace variables

In a multi-root workspace, append a root name after a colon. workspaceFolder:Client resolves to the path of the root displayed as Client.

This is essential when you have separate frontend and backend folders and need to reference files across them:

json

{
  "type": "node",
  "request": "launch",
  "name": "Launch server with client path",
  "program": "${workspaceFolder:Server}/app.js",
  "args": ["${workspaceFolder:Client}/dist"]
}

Input variables

Input variables obtain a value when a task or debug session starts. Define them in an inputs section in launch.json or tasks.json, then reference the ID from a supported field.

Here is a task that asks which component to generate:

json

{
  "version": "2.0.0",
  "tasks": [
    { "label": "Preview component name", "type": "shell", "command": "echo", "args": ["Component: ${input:componentName}"] }
  ],
  "inputs": [
    { "id": "componentName", "type": "promptString", "description": "Component name", "default": "my-component" }
  ]
}

When you run Preview component name, VS Code asks for a name and then prints it. The input is an argument to a harmless command, not the command executable itself.

Three input types are available:

Masking a promptString hides what the user types in the prompt, but it does not guarantee that the substituted value stays out of logs or process arguments. Input variables cannot be nested.

A command input can invoke built-in or extension-provided behavior, so review the command ID and its effects before running the task or debug configuration.

Platform portability

On Windows, file paths use backslashes. On macOS and Linux, they use forward slashes. Hardcoded separators can make a composed path platform-specific.

Predefined path variables resolve using the current platform. When you construct a path from separate components, use pathSeparator or its slash shorthand:

json

{
  "command": "node",
  "args": ["src${/}app${/}index.js"]
}

For more on sharing configurations across your team, see how to share VS Code project settings with your team. To learn about task automation, read how to create and configure tasks.json.

Where variables work

Use variable substitution only where the configuration supports it:

• launch.json: supported string keys and values defined by the selected debugger
• tasks.json: only the command, args, and options fields
• settings.json: selected settings, including certain terminal cwd, env, shell, and shellArgs values
• .code-workspace files: the same supported configuration positions

Variables do not work in task labels or most settings. Check the current setting description or configuration IntelliSense when a value remains literal.