How to Share VS Code Project Settings with Your Team

Share VS Code project settings by committing reviewed files from the .vscode folder to the repository. Applicable workspace settings take effect when the folder opens, while tasks, debug configurations, and recommended extensions remain visible actions that the teammate chooses to run or install.

Keep the shared configuration small, portable, and limited to the project's actual workflow.

What to put in the shared .vscode folder

Add team-wide workspace settings

Create .vscode/settings.json with rules the whole team agrees on. Run Preferences: Open Workspace Settings (JSON) from the Command Palette to create it.

Focus on settings that prevent diff noise and express agreed project conventions:

json

{
  "editor.tabSize": 2,
  "editor.insertSpaces": true,
  "editor.trimAutoWhitespace": true,
  "files.insertFinalNewline": true,
  "files.trimTrailingWhitespace": true
}

Do not put personal preferences here. Font size, color theme, and cursor style belong in user settings.

Recommend shared extensions

Create .vscode/extensions.json with the extensions every contributor should review. Run Extensions: Configure Recommended Extensions (Workspace Folder) from the Command Palette.

json

{
  "recommendations": [
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode"
  ]
}

These identifiers are the ESLint and Prettier examples used in the official VS Code documentation. Keep them only if the project actually uses those tools. Before committing any recommendation, open its Marketplace details and review the publisher, current availability, price, runtime access, telemetry, and workspace requirements.

When a teammate first opens the workspace, VS Code prompts them to review and install its recommendations. The file does not install or trust an extension automatically.

For a deeper guide, see how to recommend VS Code extensions with extensions.json.

Add shared debug configurations

Create .vscode/launch.json so every developer can start debugging with the same setup. Open the Run and Debug view and click create a launch.json file to generate one.

json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceFolder}/src/index.js"
    }
  ]
}

Use VS Code variables like ${workspaceFolder} instead of absolute paths. This keeps the configuration independent of where the project is cloned.

Add build and test tasks

Create .vscode/tasks.json with commands the team runs regularly. Run Tasks: Configure Task from the Command Palette and pick a template.

Here is an example with a build task:

json

{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "script": "build",
      "group": { "kind": "build", "isDefault": true },
      "label": "npm: build"
    }
  ]
}

You can add a test task by adding another entry to the tasks array. After committing, anyone can press Ctrl+Shift+B (Windows/Linux) or Cmd+Shift+B (macOS) to run the default build task.

After a teammate opens the project, confirm the shared values under the Workspace tab in Settings and run Extensions: Show Recommended Extensions to inspect the recommendation list. Review task and debug commands before running them, install their documented prerequisites, and then confirm that the expected build output or debug session starts without a machine-specific path error.

Keep settings portable

Follow these rules so settings work on Windows, macOS, and Linux:

• Use VS Code variables instead of absolute paths
• Use forward slashes in paths. VS Code normalizes them on Windows.
• Avoid hardcoded paths like C:\Users\name\tools

If a task needs a tool that is not guaranteed to be installed, document it in the project README.

Review .vscode changes like code

Treat .vscode file changes as you would any other code change:

• Review them in pull requests
• Discuss setting changes with the team before committing
• Explain why a setting is needed in the commit message
• Keep settings minimal: only add what the project genuinely requires

For the same setting type, a workspace value overrides a user value. Language-specific settings have separate precedence, and administrator policy settings override all user-configurable scopes.

A teammate can test a local edit to .vscode/settings.json, but that edit appears as a repository change and should not be committed without team agreement.

What not to share

Keep these out of the committed .vscode folder:

• Absolute paths that only work on your machine
• Secrets, tokens, or API keys: use environment variables or a secrets manager, and keep local secret files out of version control
• Personal preferences: theme, font family, cursor style, zoom level
• Unsupported executable settings: VS Code ignores git.path and terminal.external.windowsExec, terminal.external.osxExec, or terminal.external.linuxExec at workspace scope. Keep executable selection in user settings instead of trying to work around the restriction.

Workspace Trust safety reminder

When VS Code asks whether a teammate trusts a new repository, they should leave it in Restricted Mode until they have reviewed the authors and contents. VS Code disables or limits AI agents, the terminal, tasks, debugging, workspace settings, and extensions that cannot run safely without trust.

This is expected. Review the repository authors and .vscode files before trusting the folder, especially executable paths, task commands, and debug configurations.