Using WSL2 causes commands to freeze

[zdelta]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s terminal integration fails to load properly in WSL2 environment due to a path separator conflict in the shell integration script. The script attempts to source a file using Windows-style backslashes (\) in a Linux environment where forward slashes (/) are required.

Root Cause Analysis:
Cursor’s shell integration script generates a path with mixed separators: bash: \home\zdelta\.cursor-server\bin\9455eaa4c87f2bad91eda3f2bc9b42b16eae1080/out/vs/workbench/contrib/terminal/common/scripts/shellIntegration-bash.sh: No such file or directory
The path contains Windows-style backslashes (\) instead of Unix-style forward slashes (/)
This causes the source command to fail with “No such file or directory” error
The shell integration script fails to load, preventing proper terminal functionality

Steps to Reproduce

Add the following to ./bashrc

 exec 1> >(tee -a ~/cursor_debug.log)
 exec 2> >(tee -a ~/cursor_debug_err.log)

Run tail -f ~/cursor_debug*.log

Open Cursor with terminal integration enabled from the WSL2 environment

The following output is obtained from the log files

==> /home/zdelta/cursor_debug_err.log <==.
 "\home\zdelta\.cursor-server\bin\9455eaa4c87f2ba
==> /home/zdelta/cursor_debug.log <==
. "\home\zdelta\.cursor-server\bin\9455eaa4c87f2ba
==> /home/zdelta/cursor_debug_err.log <==
d91eda3f2bc9b42b16eae1080/out/vs/workbench/contrib
==> /home/zdelta/cursor_debug.log <==
d91eda3f2bc9b42b16eae1080/out/vs/workbench/contrib
==> /home/zdelta/cursor_debug_err.log <==
/terminal/common/scripts/shellIntegration-bash.sh"
==> /home/zdelta/cursor_debug.log <==
/terminal/common/scripts/shellIntegration-bash.sh"
==> /home/zdelta/cursor_debug_err.log <==


==> /home/zdelta/cursor_debug.log <==


==> /home/zdelta/cursor_debug_err.log <==
bash: \home\zdelta\.cursor-server\bin\9455eaa4c87f2bad91eda3f2bc9b42b16eae1080/out/vs/workbench/contrib/terminal/common/scripts/shellIntegration-bash.sh: No such file or directory

==> /home/zdelta/cursor_debug.log <==
bash: \home\zdelta\.cursor-server\bin\9455eaa4c87f2bad91eda3f2bc9b42b16eae1080/out/vs/workbench/contrib/terminal/common/scripts/shellIntegration-bash.sh: No such file or directory

==> /home/zdelta/cursor_debug_err.log <==

Expected Behavior

Shell integration script should load successfully with proper Unix-style path separators.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.6.6 (user setup)
VSCode Version: 1.99.3
Commit: 9455eaa4c87f2bad91eda3f2bc9b42b16eae1080
Date: 2025-09-11T01:16:54.096Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the report. It seems this is already fixed in version 1.6.14. Try updating and let me know if the issue persists.

[zdelta]

Even after connecting to the Early Access branch and updating, the same logs are being output

Version: 1.6.14 (user setup)
VSCode Version: 1.99.3
Commit: 64b72c9cd7e38203078327f881d5fe74930b2600
Date: 2025-09-11T21:41:40.820Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

It seems there were two issues here, and one of them has been resolved.
(Fortunately, the one critical to work has already been fixed.)

1. Commands not executing
   This has been fixed.

2. Startup script path used by cursor contains mixed / and \
   This appears to still be present.

It doesn’t seem to be a major issue, but could you investigate point 2?

Also, is there any public documentation available indicating when the GA for 1.6.14 will be?

[ravirahman]

Hi @zdelta, could you try upgrading to version 1.6.35? This version fixed a lot of the issues with the new shell integration.

[zdelta]

I tried 1.6.45 and it worked!

However, an earlier version (I forget the details, but it was causing issues in another thread) wasn’t working, so I was temporarily using 1.5.11.

I’d be happy if stable updates were guaranteed.

Version: 1.6.45 (user setup)
VSCode Version: 1.99.3
Commit: 3ccce8f55d8cca49f6d28b491a844c699b8719a0
Date: 2025-09-22T18:22:38.013Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100