Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.76.1 OS Version: macOS 13.2.1 (22D68) an that uses a schema other than or . For example, : text renders as a hyperlink (dotted underline), but isn't cmd/ctrl+clickable like other like OSC 8 hyperlinks with the / scheme. Other OSC 8-capable terminals (like ) will open the link correctly. Here's a video demonstrating the issue with several other URL schemes: https://user- As you can see, only and URL schemes result in clickable links. If I remember correctly, this regressed in the 1.74 -1.75 update, which leads me to believe it might be related the introduced in that version. This functionality can be super useful for tools like , which let you add hyperlinks to line numbers in diffs. When this functionality worked in VS Code 1.74, those links would be clickable: !
Since everything supported this, I relied on it, damn. Would be amazing to have this back. Only non-heuristic way to get clickable file links in the terminal that handle all paths (e.g. paths with spaces)
We currently do not allow non-http(s) links due to allowNonHttpProtocols here: This may just be a case of adding that property to , but we need to make sure it won't introduce a security issue.
Hm, running code in a terminal generally means one trusts it. After all at this point it has access to a lot of things. Displaying data from untrusted sources without stripping ANSI escapes is more a problem of the tool displaying the data. I think when a terminal link is hovered, VS Code should just show a little link target floaty thing that shows where the link points to. Other terminal emulators do that. If you’re being paranoid, show a little when a link label looks like an URI but the corresponding link points to another URI. But that’s a situation people have in the web all the time, so they should know it can happen.
sure, but you can some file and it will evaluate sequences which is a common attack vector. The user is typically unaware that could result in execution and/or malicious links being inserted. The hover is probably sufficient, I would want to double check with someone on the team who has done some general URI handling when looking at the PR.
I understand the reasoning for disabling this, as VS Code focuses pretty strongly on security given its popularity (workspace trust, confirmations when opening links, well-defined extension API), but would it be possible to allow non-HTTP hyperlinks in the terminal via a setting? Something like ? It seems like implementing this would be a simple pass-through to 's property on (which you previously linked to). The setting could even have a security warning in its description. It'd be really nice to have this functionality back.
Who needs to sign off on a decision here? This is affecting me pretty much daily (since my testing framework uses this and I simply can’t make VS Code behave)
If would be nice to support at least links, so that one could open files within VS Code, by clicking on a link in a terminal.
+1, our framework uses OSC 8 links as one of the exclusive features vs competitors. Missing support in VS Code makes it irrelevant and degrades our productivity.
Easy testing below, only the first 2 work: Note that we wouldn't be able to support any arbitrary link without additional work as there are security concerns.
bash should work
yeah the file needs to exist for it to work
are you connected to the window via the Remote - WSL extension? If not this is as expected currently.
created to track your 1. For 2 right now proper WSL link support only works within Remote - WSL windows, so making this work well in local windows would be a new feature request.

Related discussion:
text: windowsEnableConpty: boolean; wordSeparators: string; enableFileLinks: 'off' | 'on' | 'notRemote'; <ins> allowedLinkSchemes: string[]; </ins> unicodeVersion: '6' | '11'; localEchoLatencyThreshold: number; localEchoExcludePrograms: ReadonlyArray<string>;