Prevents Q UriError : Validate file URI and fallback to Path.toUri() for WSL

[Lee-WonJun]

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Description

Summary

Fix repeated UriError when Amazon Q starts with a WSL-backed workspace. We now validate the constructed file: URI and fallback to JDK’s Path.toUri() if the URI violates Rule (no authority while the path begins with //, maybe RFC 3986). This keeps legacy behavior where it’s safe, and prevents Q from rejecting the workspace folder URI.

Related issues

• Fixes/addresses: Amazon Q Chat 3.74.251 not working on WSL2 folder #5799, Error with double slash in WSL path when using Windows and WSL #5950, Amazon Q interactions not working after sign in #5947 (same failure mode reported across these)

Root cause

During InitializeParams creation, workspaceFolders receives URIs derived from VirtualFile.
Internally we were manually constructing file URIs like:

URI("file", "", file.absoluteFile.toURI().path, null)

On WSL paths this can become:

file:////wsl.localhost/Ubuntu/...

This has no authority and a path that starts with //, which violates RFC 3986. Amazon Q rejects it with:

Older versions reportedly worked because we used a fn in Nio:

file.toNioPath().toUri().toString()

[#5462](https://github.com/aws/aws-toolkit-jetbrains/pull/5462/files), when we switched away from the JDK-generated URI toward manual assembly.

What changed

• After we build the manual file: URI, we inspect the resulting URI:

  • If scheme == "file" and authority is empty and path starts with //, it’s considered non-compliant → fallback.

• Fallback uses JDK normalization:

  file.toPath().toAbsolutePath().normalize().toUri()

• jar: and jrt: handling unchanged.

Why fallback (and not just always Path.toUri())?

I personally think standardizing on file.toPath().toAbsolutePath().normalize().toUri() (or another well-defined canonicalization strategy) would be simpler and sufficient. However, to maintain backward compatibility, address this specific case, and respect any implicit intent behind the current manual construction, I implemented a conservative fallback: we keep the existing construction and only fall back to the JDK-generated URI when the constructed value would violate rule

Tests

2025-08-09.015755.mp4

• Manually verified with the plugin:

  • WSL folder workspaces: Q initializes and runs successfully.
  • File/workspace views load as expected.

• add unit test

---

Checklist

• My code follows the code style of this project
• I have added tests to cover my changes
• A short description of the change has been added to the [CHANGELOG](https://github.com/aws/aws-toolkit-jetbrains/blob/master/CONTRIBUTING.md#contributing-via-pull-requests) if the change is customer-facing in the IDE.
• I have added metrics for my changes (if required)

License

I confirm that my contribution is made under the terms of the Apache 2.0 license.