The Definitive Fix for the WSL Terminal Bug (Garbled Commands, '<' Symbol)

How To
1

Hi everyone,

This is a definitive guide to solve a persistent and frustrating bug that occurs when using Cursor on Windows with a WSL (Windows Subsystem for Linux) backend.

The Problem

You’ve likely experienced one or more of these symptoms:

  • The integrated terminal hangs or becomes unresponsive in Agent Mode.
  • Long commands are garbled, truncated, or fail to execute.
  • A strange < symbol appears at the beginning of your command, like <rt or <thon.
  • The issue is worse when commands contain multi-byte UTF-8 characters (e.g., in file paths or comments).

This bug is the root cause of issues reported in other threads, which were sometimes described unclearly. For example, it is the underlying problem in:

The Root Cause: The Faulty WSL Bridge

The problem is not your shell, nor is it SSH. It’s the default communication bridge that Cursor uses to talk to the WSL environment. This bridge is fragile and corrupts commands before they even reach your shell.

The Solution: Use a Direct SSH Connection Instead

The solution is to stop using the default WSL integration and treat your WSL instance like a proper remote server. We will run Cursor’s own server component inside WSL and have the main Cursor app connect to it via a standard, stable SSH connection.

This bypasses the faulty bridge entirely.

How To Do It:

The workflow is simple:

1. Start the cursor-server inside your WSL instance.
You need a running process inside WSL for Cursor to connect to. Open any terminal (Windows Terminal is great for this), get into your WSL, and run:

# First, ensure an SSH server is running in your WSL
sudo service ssh start

Keep this terminal window open. The server needs to stay active.

2. Connect to it from your main Cursor for Windows app.
Now, in your main Cursor window, connect to the server you just started.

  • Press Ctrl+Shift+P and select Remote-SSH: Connect to Host…
  • Enter the connection string: your-wsl-username@localhost (e.g., root@localhost).

That’s it. A new Cursor window will open, running in a stable SSH session connected to your WSL.

With this setup, all terminal bugs will be gone. Interestingly, AugmentCode also failed to launch in the default WSL mode.

1 Like
3

This bug is super annoying - is it on the roadmap to be fixed?

5

Could you share a screenshot / screen cast for what is happening?

6

I’ve updated to the Cursor WSL and that seems to improved things a lot e.g. New In-house Extensions (C++, C#, SSH, DevContainers, WSL, Python) - Discussions / Featured Discussions - Cursor - Community Forum

What seems to happen before was that the first shell command to say bash would work ok, but then the 2nd time or more include the previous output in a way that would corrupt it - meaning I’d have to hit ‘skip’ every time and run the command myself.

If it happens again on the more recent extension I’ll grab logs/screenshot but so far so good.

1 Like
8

Unfortunately not fixed with latest extension, shell commands now often fail and it seems to be due to the length of the command wanted to be run? It’ll hang and needs a ‘Skip’ to be pressed. Here’s it having an issue:

image
image1069×840 61.2 KB

You can see the <te corrupted text in the output.

Version: 1.0.0 (user setup)
VSCode Version: 1.96.2
Commit: 53b99ce608cba35127ae3a050c1738a959750860
Date: 2025-06-04T19:44:25.253Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.22631

Using WSL2 Ubuntu 20.

Essentially it is the same as this issue already reported:

Terminal Command Parsing Bug in Cursor – “<rt” Issue - Bug Reports - Cursor - Community Forum