CSP blocks loading extension font files when VSCODE_EXTENSIONS points to a network drive

Does this issue occur when all extensions are disabled?: Yes/No

Version: 1.136.1 (system setup)
Commit: a44adf7f53e00964ab890f9f8758a334f1fc15bc
Date: 2026-09-03T05:06:41Z
Electron: 42.10.0
ElectronBuildId: 15109253
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
@github/copilot: 1.0.81-0
@github/copilot-sdk: 1.0.11
OS: Windows_NT x64 10.0.26200

When the VSCODE_EXTENSIONS environment variable is configured to point to a network share, VS Code appears to block loading font assets from installed extensions due to CSP restrictions.

In our environment, VSCODE_EXTENSIONS is set to a UNC path like this:

\\\VMHFILE03\User-Folders$\\Documents\vscode\extensions

With this configuration, extension assets such as .woff2 font files are not loaded successfully. In the Developer Tools, the request shows as blocked:csp.

As a result, icons or other UI elements provided by the extension may not render correctly.

If the same extensions are installed in a local extensions directory instead of a network path, the font loads correctly and the icons are displayed as expected.

Steps to Reproduce
1. Set the VSCODE_EXTENSIONS environment variable to a network share / UNC path, for example:
\\\VMHFILE03\User-Folders$\\Documents\vscode\extensions
2. Start VS Code.
3. Install an extension that contains font assets, for example GitLens.
4. Open Developer Tools.
5. Trigger a view or UI element from the extension that uses its bundled icon font.
6. Observe that the .woff2 font file from the extension directory is not loaded.
7. In Developer Tools, the request is shown as blocked:csp.

Additional Information
- This only happens when the extensions directory is located on a network drive / UNC path.
- Using a local path for the extensions directory works correctly.
- We have a screenshot from Developer Tools showing the blocked:csp error.