[UriError]: Scheme contains illegal characters

[vdevmt]

already existing closed issue #93220

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

• VS Code Version: Version: 1.100.2 (system setup) Commit: 848b80aeb52026648a8ff9f7c45a9b0a80641e2e Date: 2025-05-14T21:47:40.416Z Electron: 34.5.1 ElectronBuildId: 11369351 Chromium: 132.0.6834.210 Node.js: 20.19.0 V8: 13.2.152.41-electron.0 OS: Windows_NT x64 10.0.26100

• OS Version: Windows 11 Pro

Steps to Reproduce:

const url = 'https://www.google.com/'; (or https://dev.azure.com/) const encodedUrl = encodeURI(url); const uri = vscode.Uri.parse(encodedUrl); vscode.env.openExternal(uri)

Result: [UriError]: Scheme contains illegal characters

Only the value 'https://github.com/' works fine. How is this possible?

[sjoukedv]

I have the same for many extensions; GitLab Workflow, Gemini Code Assist, etc.

[UriError]: Scheme contains illegal characters.

Version: 1.100.2
Commit: 848b80aeb52026648a8ff9f7c45a9b0a80641e2e
Date: 2025-05-14T21:47:40.416Z
Electron: 34.5.1
ElectronBuildId: 11369351
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Linux x64 6.11.0-26-generic

[vdevmt]

I have the same for many extensions; GitLab Workflow, Gemini Code Assist, etc.

[UriError]: Scheme contains illegal characters.

Version: 1.100.2
Commit: 848b80aeb52026648a8ff9f7c45a9b0a80641e2e
Date: 2025-05-14T21:47:40.416Z
Electron: 34.5.1
ElectronBuildId: 11369351
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Linux x64 6.11.0-26-generic

I have problems with GitLens Extension

[augmentmoogi]

I just had a user complaining about the same problem, on the same vscode version..

[sjoukedv]

This appears to be an issue with "Command Palette" > "Manage Trusted Domains". If I insert "*" at the top, the link opens just fine. I had several entries in there without a protocol, adding https:// to all them solve the issue for me.

[vdevmt]

This appears to be an issue with "Command Palette" > "Manage Trusted Domains". If I insert "*" at the top, the link opens just fine. I had several entries in there without a protocol, adding https:// to all them solve the issue for me.

Thanks @sjoukedv , In my trusted domain list there was an entry like this: *.mydomain.com:8080. I replaced this entry with *.mydomain.com (without port number) and now I can use all commands that open specific URLs.

In the previous version of vscode this entry worked fine. Unfortunately the error message was not very clear.

Thanks again have a nice day

[vdevmt]

For Vscode development team (@jrieken ): The new rule *.mydomain.com does not work. I get this confirmation window:

and after selecting the "Configure trusted domains" option:

• Trust http://srv-bcdev2.mydomain.com:8080: It works fine because it adds "http://srv-bcdev2.mydomain.com:8080" to the list of trusted domains.

• Trusted mydomain.com:8080 and all its subdomains: It does not work because it adds "*.mydomain.com:8080" to the trusted domains list and as a result all commands that open a URL do not work (this is my original problem). I believe this option should add the *.mydomain.com entry without the port number to allow all URLs of the entire domain to open. If I manual remove the port number from this entry, the rule does not work.

Can you solve this problem?

[happycollision]

Here is where the failure is occurring:

You can see from the docs about trusted domains, that a domain starting with a * is supposed to be legal.

And yes, adding https:// to the front of the three highlighted trusted domains in my config does solve the problem.

The failure is not with the utility in pictured above, because it is indeed validating an invalid URI. The problem is that these trusted domain lists are not necessarily valid URIs, and should probably not be checked as such.

I am guessing that this bit right here changed recently:

[TylerLeonhardt]

It's the ones without a scheme but a port. Nice find. This code changed recently due to a security vulnerability... where wildcards were leaking in to other parts of the url... let me see what can be done for this.

[happycollision]

That was fast. I thought I’d be digging in farther to this! Thanks!

[TylerLeonhardt]

Honestly gotta give a shout out to Agent mode.

1. I wrote a 1 line test that indeed failed - a glob with both no scheme and a port,
2. asked Agent mode in Chat to fix the test
3. It ran the test, saw the failure, made a code change, ran all the Trusted Domain tests and they passed
4. I reviewed the small code change and it looks great!

[vdevmt]

Great! When is this fix expected to be released?

[vdevmt]

has the functionality that automatically adds a trusted domain rule based on these options also been fixed?

[TylerLeonhardt]

@vdevmt tomorrow in Insiders (which you can side-by-side install with stable), 2 weeks for Stable. Yes, that quick pick is fixed.

[eleanorjboyd]

Hello! Has anyone been able to verify if this release works? If you could let us know so we can mark this as verify that would be great!

[vs-code-engineering[bot]]

This bug has been fixed in the latest release of VS Code Insiders!

@vdevmt, you can help us out by commenting /verified if things are now working as expected.

If things still don't seem right, please ensure you're on version 1ca21f8a13ad30d022e80888716156f4264297d0 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.

Happy Coding!

[vdevmt]

/verified

It seems to work fine. I would avoid declaring the port number in the automatic trusted domain rules. So instead of *mydomain.com:8080, I would simply add *mydomain.com