This is a high-severity workflow breaker because it makes the editor unable to open files in a WSL workspace unless the user discovers the Connect/Open-in-WSL workaround.
-
Antigravity 1.20.6
-
Commit
135ccf460c67c4b900d -
Windows build
10.0.26200 -
WSL2 Ubuntu-24.04
Submitted via in-app Bug Report on 2026-03-24 (no receipt/ticket number was provided).
This appears to be a workspace canonicalization defect in WSL mode: the integrated terminal is correctly in WSL, but the editor/agent file provider binds to Windows UNC (\wsl.localhost\…) or an invalid Linux root like /Ubuntu-24.04/… The product should detect this and auto-convert UNC-opened WSL folders to a WSL workspace URI, or warn and provide a one-click “Open in WSL properly” fix.
Key signal (UNC path used for workspace/file URIs):
\wsl.localhost\Ubuntu-24.04\home\ken\projects\postglider2\.env.example
while the real WSL path is:
/home/ken/projects/postglider2/…
Symptoms when in the bad state:
Editor: “The editor could not be opened because the file was not found.” (for files that exist)
Agent: “Cannot list directory … which does not exist”, sometimes “Analyzed \”
Prompts: “Allow directory access to /?”
Workaround (reliably fixes):
Command Palette → Remote-WSL: Connect to WSL → Remote-WSL: Open Folder in WSL… → open /home/ken/projects/postglider2
Diagnostics:
echo $WSL_DISTRO_NAME → Ubuntu-24.04
pwd in integrated terminal → /home/ken/projects/postglider2
OS build → 10.0.26200 (Windows 11 Pro)
Antigravity → 1.20.6 (commit 135ccf460c67c4b9)
VSCode OSS → 1.107.0 (user setup)
Reproduce:
On Windows with WSL2 Ubuntu-24.04, open a WSL-hosted repo in a way that results in a UNC-rooted workspace (e.g., open folder via Windows UI or restore a recent workspace) so file URIs resolve to \wsl.localhost\Ubuntu-24.04\home\…
Confirm the integrated terminal is WSL:
echo “$WSL_DISTRO_NAME” returns Ubuntu-24.04
pwd returns /home/ken/projects/
In Explorer, click an existing file (e.g., README.md or .env.example).
Expected Behavior
When WSL mode is active:
Workspace root is a canonical WSL path/URI mapping to real Linux paths like /home/…
Editor opens files reliably.
Agent and editor share the same resolved workspace root.
The app should not prompt for broad access to / or analyze \ due to path/provider mismatch.
If a user opens \wsl.localhost\… as a workspace, the app should auto-convert to “Open Folder in WSL…” (or warn + offer a one-click fix).
Actual Behavior
Editor reports: “The editor could not be opened because the file was not found.” for files that exist.
Agent fails directory listing (“Cannot list directory … which does not exist”), sometimes shows “Analyzed \”, and prompts “Allow directory access to /?”.
Workspace/tooling may treat distro name as a fake Linux root (e.g., /Ubuntu-24.04/home/…) even though the correct root is /home/…
Error Messages
“The editor could not be opened because the file was not found.”
“Error while analyzing directory”
“Cannot list directory … which does not exist.”
“Analyzed \”
“Allow directory access to /?”
Workaround
Command Palette → Remote-WSL: Connect to WSL → Remote-WSL: Open Folder in WSL… → open /home/ken/projects/. After this, Explorer hover paths appear like ~/projects/… and files open correctly.
Meta: I submitted this via Antigravity’s in-app Bug Report on 2026-03-24, but there was no confirmation email or ticket ID. Using this thread as the public reference.
Meta (feedback on the reporting flow): I submitted this via Antigravity’s in-app “Bug Report” form on 2026-03-24, but it provided no receipt, no ticket/ID, and no confirmation email. That makes it hard to reference, dedupe, or follow up on serious workflow-breaking defects. Please add a basic submission acknowledgement with an ID (and ideally an option to include diagnostics/log bundle + screenshot capture) so reports can be tracked. Without an ID/receipt, the current “Bug Report” function is effectively a black hole.