fix(core): preserve full path in workspace validation for non-existent segments

[AnushkaPandit-21]

Summary

Fixes path validation failures on Windows when accessing non-existent files through UNC paths (e.g. WSL \\wsl.localhost\...).

Root cause: When fs.realpathSync fails with ENOENT on a non-existent path, Node's error object (e.path) only contains the resolved path up to the last existing segment, silently truncating the rest. For example:

Input:  \\wsl.localhost\Ubuntu\home\project\nonexistent\deep\file.txt
e.path: \\wsl.localhost\Ubuntu\home\project  (truncated!)

fullyResolvedPath() in workspaceContext.ts was returning this truncated e.path directly, causing downstream path comparisons to operate on incomplete paths. On regular Windows drive paths (C:\...) the truncation is less visible because path.relative still produces a valid sub-path, but on UNC paths (especially WSL paths accessed via MinGW) this leads to confusing "Path not in workspace" errors.

Fix: Compute the full resolved path before calling realpathSync, then on ENOENT append the remaining non-existent segments from the original path to e.path, preserving the full intended path for workspace boundary checks.

Changes

• packages/core/src/utils/workspaceContext.ts — Fix fullyResolvedPath() to append remaining segments when realpathSync returns a truncated e.path
• packages/core/src/utils/workspaceContext.test.ts — Add tests for deeply nested non-existent paths (both inside and outside workspace)

Reproduction

On Windows with WSL installed:

const fs = require('fs');
try {
  fs.realpathSync('\\\\wsl.localhost\\Ubuntu\\home\\nonexistent\\deep\\file.txt');
} catch (e) {
  console.log(e.path);
  // \\wsl.localhost\Ubuntu\home\nonexistent  (truncated!)
}

Test plan

• Existing workspaceContext.test.ts tests pass (29 passed, 11 skipped on Windows)
• New test: deeply nested non-existent path inside workspace → accepted
• New test: deeply nested non-existent path outside workspace → rejected
• ESLint + Prettier pass
• Pre-commit hooks pass

Fixes #18594

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical path validation bug affecting Windows users, particularly those interacting with WSL UNC paths. By ensuring that fullyResolvedPath() accurately returns the complete path for non-existent files, it prevents erroneous "Path not in workspace" errors and improves the reliability of workspace boundary checks.

Highlights

• Corrected Path Truncation: Addressed an issue where Node.js's fs.realpathSync would truncate non-existent UNC paths (e.g., WSL paths on Windows) in its error object (e.path), leading to incorrect path validation.
• Preserved Full Path: Modified fullyResolvedPath() to reconstruct and return the full intended path by appending non-existent segments from the original path when fs.realpathSync fails with ENOENT.
• Enhanced Test Coverage: Introduced new tests to specifically validate the handling of deeply nested non-existent paths, both inside and outside the workspace, ensuring the fix works as expected.

Changelog

• packages/core/src/utils/workspaceContext.test.ts
  • Added two new test cases to verify the correct handling of deeply nested non-existent paths within and outside the workspace.
• packages/core/src/utils/workspaceContext.ts
  • Modified fullyResolvedPath to correctly reconstruct the full path from e.path when fs.realpathSync throws an ENOENT error, preventing truncation of non-existent segments.

Activity

• Existing tests for workspaceContext.test.ts were confirmed to pass, with Windows-specific skips noted.
• New tests for deeply nested non-existent paths were added and passed, covering both in-workspace and out-of-workspace scenarios.
• Code quality checks (ESLint, Prettier, pre-commit hooks) were successfully run.
• This PR addresses and fixes issue Path validation fails for WSL paths on Windows (MinGW) #18594.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request addresses an important path validation issue on Windows, especially for UNC paths, where fs.realpathSync can return a truncated path for non-existent files. The approach of reconstructing the full path is correct.

However, the implementation has a significant flaw on case-insensitive filesystems like Windows. It doesn't account for potential casing differences between the user-provided path and the canonical path returned in the error object, which can lead to creating a malformed path. I've left a critical comment with a suggested fix to make the path reconstruction robust against casing differences, referencing relevant rules on path sanitization and internal validation.

[gemini-code-assist]

This logic for reconstructing the path is not safe on case-insensitive filesystems like Windows. fs.realpathSync (which sets e.path) returns a path with canonical casing (e.g., C:\Users), while fullPath (from path.resolve) preserves the user's input casing (e.g., c:\users).

If the casing of the prefix differs, fullPath.substring(resolvedPrefix.length) will produce an incorrect remainder because substring is case-sensitive, leading to a malformed path (e.g., C:\Userss\...). This could cause incorrect workspace validation.

To fix this, we should perform a case-insensitive check to ensure resolvedPrefix is a prefix of fullPath before attempting to get the remainder.

        const resolvedPrefix = e.path;
        // On case-insensitive filesystems (e.g. Windows), `e.path` and `fullPath`
        // can have different casing, making `substring` unsafe.
        if (fullPath.toLowerCase().startsWith(resolvedPrefix.toLowerCase())) {
          return resolvedPrefix + fullPath.substring(resolvedPrefix.length);
        }
        // Fallback to the truncated path to avoid creating a malformed path.
        return resolvedPrefix;

References

1. Sanitize user-provided file paths used in file system operations to prevent path traversal vulnerabilities.
2. Utility functions that perform file system operations should validate their path inputs internally to prevent path traversal vulnerabilities, rather than relying solely on callers to perform validation.

[AnushkaPandit-21]

Good catch — fixed in 83d500c. Now using a case-insensitive startsWith check before reconstructing the path, with a fallback to the truncated prefix if casing doesn't align.

[AnushkaPandit-21]

Closing this — the underlying issue was addressed by #21487 which refactored fullyResolvedPath to use resolveToRealPath with a recursive parent-resolution approach in robustRealpath. That handles the truncated e.path problem more cleanly than my prefix-matching fix.

The deeply-nested path tests I added here might still provide useful coverage — happy to resubmit those as a standalone test PR if the team thinks it's worth it.