Fixed using Copilot with Claude Opus 4.8 in VS Code (after reproing/debugging it).

Summary: It was using the older Program Files clang-format instead of the newer bundled one.

Problem

When resolving the clang-format / clang-tidy path, the extension shells out to the bundled binary to read its version (getClangPath in settings.ts). On Windows this could throw:

Error: Command failed: 'c:\...\Extension\LLVM\bin\clang-format.exe' --version
The filename, directory name, or volume label syntax is incorrect.

The failure happened in the bundled-binary try block, silently falling through to the catch ("Unable to invoke our own clang-*") and skipping the bundled-vs-system version comparison entirely.

Root cause

The bundled invocation used shell-quote's quote() to build the command string:

execSync(quote([bundledPath, '--version']))

quote() produces POSIX-style single-quoted output ('c:\...\clang-format.exe' --version). On Windows, execSync runs the command through cmd.exe, which does not accept single quotes for quoting, so the command failed. The binary itself was fine — only the quoting was wrong.

quote() was originally added in #11841 ("Address issues reported by compliance tooling") to stop building a shell command from an unescaped variable. So we cannot simply revert to raw string interpolation.

Fix

Switch both version-probe invocations from a shell command (execSync + quoting) to execFileSync, which invokes the executable directly with an argument array and no shell:

execFileSync(bundledPath, ['--version'])
execFileSync(path, ['--version'])

Because no shell is involved:

• No quoting is required, so the Windows single-quote bug cannot occur.
• Paths containing spaces (and other special characters) work correctly on Windows, Linux, and macOS.
• The original compliance concern that motivated quote() is addressed more directly — there is no shell command constructed from a variable, which is the canonical remediation for that class of finding.

The shell-quote import is removed since it is no longer used.

What is preserved

• The flexible regex-based version extraction from clang-format/tidy version comparisons fail for some builds #12813 ("clang-format/tidy version comparisons fail for some builds") is unchanged: output.match(/(\d+\.\d+\.\d+)/)?.[1] on both paths. That scenario does not regress.
• The try/catch structure is unchanged. getExtensionFilePath() stays inside the try, so if the extension path is not yet initialized and it throws, the error is still caught and we fall back to the system clang-* gracefully.
• Behavior is otherwise identical: parse the bundled version, compare against the system version, and prefer the newer one; fall back to the system binary if the bundled one can't be invoked or parsed.

Testing

• Verified the bundled and system --version calls succeed on Windows where the previous single-quoted command failed.
• Confirmed paths containing spaces no longer break the invocation.
• No functional change to the version-comparison logic.