Change:
* For shells with the CommandDetection capability, the cwd for a command relative to the line of * the particular link can be used to narrow down the result for an exact file match. */ <del> export function updateLinkWithRelativeCwd(capabilities: ITerminalCapabilityStore, y: number, text: string, pathSeparator: string): string[] | undefined { </del> <ins> export function updateLinkWithRelativeCwd(capabilities: ITerminalCapabilityStore, y: number, text: string, osPath: IPath): string[] | undefined { </ins> const cwd = capabilities.get(TerminalCapability.CommandDetection)?.getCwdForLine(y); if (!cwd) { return undefined; } const result: string[] = []; <del> if (!text.includes(pathSeparator)) { result.push(cwd + pathSeparator + text); </del> <ins> const sep = osPath.sep; if (!text.includes(sep)) { result.push(osPath.resolve(cwd + sep + text)); </ins> } else { let commonDirs = 0; let i = 0; <del> const cwdPath = cwd.split(pathSeparator).reverse(); const linkPath = text.split(pathSeparator); </del> <ins> const cwdPath = cwd.split(sep).reverse(); const linkPath = text.split(sep); </ins> // Get all results as candidates, prioritizing the link with the most common directories. // For example if in the directory /home/common and the link is common/file, the result // should be: `['/home/common/common/file', '/home/common/file']`. The first is the most // likely as cwd detection is active. while (i < cwdPath.length) { <del> result.push(cwd + pathSeparator + linkPath.slice(commonDirs).join(pathSeparator)); </del> <ins> result.push(osPath.resolve(cwd + sep + linkPath.slice(commonDirs).join(sep))); </ins> if (cwdPath[i] === linkPath[i]) { commonDirs++; }

Discussion:
<!-- 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.70.2 OS Version: Windows 10 Steps to Reproduce: file structure like this: ! a task like this: the task and you can see the output. Press ctrl+click the file path. It should jump to the "test.c" file. But actually, I need to choose which file should be opened. ! I think VSCode should open the file according to the file path in the output. or report error if the file dosen't exist.
After testing, 1.68 worked. But 1.69 and 1.70 don't work anymore.
I have same problem in 1.69
Hi, Any progress? Do you have a plan to fix it? Which version can this issue be fixed? Some extensions need the latest VSCode, but can not jump by clicking the output error is very inconvenient.
I believe this is fixed in , let me know if not
This issue still exists in 1.72.2.
It will jump to the file and line if I click the output in terminal. Like this: ! But it will ask me to choose the file if I click the output of tasks.
Hi, any progress?
Hi It still can not jump by ctrl+click the output of tasks. Can you reproduce following my step?
Hi still can reproduce on 1.73.1.
please stop pinging, it got reopened. This is one issue among hundreds assigned to me.
Note to self: Do task terminals assume the cwd is the workspace root, not the actually cwd?

It's happening because the task doesn't have shell integration's cwd coming through, as such it can't ensure it's folder is the starting cwd and falls back to search links. ! Maybe tasks should have their cwd fixed for link resolution, the only downside of this is if the task changes the cwd during execution in which case the link would be off. That seems like a minor edge case though.
I can click on the file link to open it in the editor, but the shell output that I get in pwsh is different from the output in the original report which seems to be bash or similar--for pwsh the parentheses seem to be getting stripped and the is on a newline. Is that expected? <img width="514" alt="image" src="https://user-"
does this one work? <img width="177" alt="image" src="https://user-"Outputting onto a different line is just something related to the shell which won't impact link detection.
yeah that one works, just wanted to make sure that the newlines weren't a behavior change <img width="522" alt="image" src="https://user-"