When using Cursor with WSL, creating a new file via Quick Open (Ctrl + P) with a nested path incorrectly handles path separators. If a path such as my/new/file.tsx is entered and Cursor offers to create the file, the resulting file is created as a single filename using Windows-style backslashes (my\new\file.tsx) instead of creating the expected directory structure (my/new/file.tsx). This behavior only occurs when the file does not already exist and is specific to Cursor running in a WSL environment.
Steps to Reproduce
Open Cursor connected to a project running under WSL.
Press Ctrl + P to open Quick Open.
Type a nested file path that does not exist, for example: my/new/file.tsx
Select “Create File ‘my/new/file.tsx’”.
Observe that Cursor creates a file named my\new\file.tsx instead of creating directories my/new/ and a file file.tsx inside them.
Expected Behavior
When creating a new file via Quick Open using a nested path (e.g., my/new/file.tsx), Cursor should create the required directories and the file using POSIX path separators under WSL, resulting in my/new/file.tsx.
Hey, thanks for the report. The issue with Windows backslashes instead of POSIX forward slashes when creating files via Quick Open in WSL is a classic path handling bug between Windows and Linux.
On version 2.2.20, the screenshot shows Cursor suggesting my\new\file.tsx instead of the proper directory structure my/new/file.tsx.
This isn’t the first report about WSL path separator issues. There are similar bugs in shell integration and interpreter mode, all related to Cursor sometimes using Windows path logic in a WSL environment.
For now, please try:
Create nested files via the terminal: mkdir -p my/new && cursor my/new/file.tsx
Or create directories first in File Explorer, then the file via Quick Open
Use Ctrl+N for a new file, then Ctrl+S Save As with the full path
I’ll pass this to the team. This looks like a path normalization bug in the WSL context.
Certainly. I’m well aware what the root cause is. My follow-up questions would be…
Cursor is forked from VSCode, which has a very polished WSL story. Why doesn’t Cursor? Why is Cursor not leaning on the battle-tested environment handling and path resolution that VSCode has already established?
The WSL and devcontainer bugs are really starting to pile up. Is there any official statement from the Cursor crew on where improved WSL support falls on the roadmap and list of priorities?
With Cursor in its current state, I’m at the point where I’m going to try uninstalling Cursor from the Windows host and reinstall directly within the WSL environment as a Linux GUI app. This is atypical, but should in theory resolve many of the bugs I’ve ran into. Are you aware of any pitfalls here? Do you agree with my assessment?
