Skip to content

Missing leading semicolon when appending to PATH on Windows #882

Closed

Description

Type: Bug

Context:

  • VS Code version: 1.106.3 (user setup)
  • Extension version: 2025.16.0
  • OS: Windows 11 Enterprise 24H2 (26100.7171)
  • Shell: PowerShell 7.5.4
  • UV .venv (uv 0.9.9 (4fac4cb7e 2025-11-12))

Behaviour:

When the debugpy extension appends its path to the PATH environment variable, it does not check if the existing PATH ends with a semicolon. If another tool (e.g., Bun) writes a PATH entry without a trailing semicolon, the paths get concatenated:

C:\Users\ggrondin.ext\.bun\binc:\Users\ggrondin.ext\.vscode\extensions\ms-python.debugpy-2025.16.0-win32-x64\bundled\scripts\noConfigScripts

Expected:

The extension should either:

  • Prepend a semicolon before adding its path, or
  • Check if the existing PATH ends with a semicolon and add one if missing

Steps to reproduce:

  1. Have a PATH entry that does not end with a semicolon (e.g., current version of bun).
  2. Open a Python project with a venv in VSCode (e.g, current version of uv (uv 0.9.9 (4fac4cb7e 2025-11-12))).
  3. Open an integrated terminal.
  4. Check $env:PATH — the paths are concatenated without separator.

Note:

This might be related to (but probably different from) #740 which fixed double semicolons (;;). This issue is about the missing leading semicolon when appending (most probably).

Related: oven-sh/bun#16811

Activity

  1. readncode commented on Dec 4, 2025

    @readncode

    I ran into this issue and it took me a long time to track down.
    Version 2025.16.0
    vscode 1.107.0-insider

  2. rmccampbell commented on Dec 10, 2025

    @rmccampbell

    I also encountered this, but strangely it only happens in one particular workspace; in other workspaces it seems to be concatenated with a semicolon as expected.

  3. cmollgaard commented on Jan 5, 2026

    @cmollgaard

    I have the same issue where it clashes with the Databricks extension which prefix it's env variable and does not postfix it.
    I assume that the code added in #748 is set on initialization is is not dynamic enough to capture other extensions causing issues?

  4. rchiodo commented on Feb 24, 2026

    @rchiodo
    Contributor

    I believe this is a dupe of #843 which has been fixed in the latest prerelease.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    triage-neededNeeds assignment to the proper sub-team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions