Window wsl2 Cursor CLI Auto Mode has slow

Support Help
, , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Hello.

I am using Cursor CLI on Windows through WSL2, Ubuntu, and tmux.

Recently, I have been experiencing very slow I/O performance when using Auto Mode. File reading, searching, and command execution feel noticeably slower than expected, especially compared with normal terminal usage.

My environment is:

Windows + WSL2
Ubuntu inside WSL
tmux session
Cursor CLI
Auto Mode

I would like to understand whether this is a known performance issue with Cursor CLI Auto Mode, or whether it may be related to the connection/process chain:

Windows → WSL2 → Ubuntu → tmux → Cursor CLI

My questions are:

  • Is slow I/O a known issue when using Cursor CLI in WSL/tmux?
  • Could Auto Mode be causing heavier file scanning, grep, indexing, or command execution overhead?
  • Would using Cursor Desktop be more stable or performant than Cursor CLI in this environment?
  • Is there any recommended setup for reducing CPU, memory usage, and I/O latency when using Cursor CLI on WSL?
  • Are there logs or debug commands I should provide to help confirm whether this is a Cursor CLI bug?

This issue does not completely block usage, but it significantly slows down agent work in Auto Mode.

I am mainly using the CLI because I want to reduce CPU and memory usage compared with a full desktop environment, but Auto Mode currently feels slower due to I/O bottlenecks.

Thank you.

Steps to Reproduce

.

Operating System

Windows 10/11

Version Information

Environment:

  • CLI Version: 2026.05.20-2b5dd59
  • Model: Auto
  • OS: linux (x64)
  • Terminal: windows-terminal
  • Shell: bash
  • Running inside WSL2 Ubuntu + tmux

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. On the server side everything looks clean. There’s no latency or timeouts, so the slowness is definitely on the client side. Auto Mode doesn’t “slow things down” by itself, but it does a lot of sequential tool calls like grep, reading files, and running commands. If the I/O under it is slow, the delays add up and you really feel it.

The main suspect in your setup is where the project lives. WSL2 is fast with files on the Linux side like ~/projects/..., but if the project is on a Windows drive via /mnt/c/..., every read or grep goes through a cross-filesystem bridge and can be much slower. Auto Mode makes this very noticeable.

A couple questions to narrow it down:

  1. Where is the project physically located, on the Linux FS like ~/something or on a Windows mount like /mnt/c/... or /mnt/d/...?
  2. If you run the CLI directly in WSL bash without tmux, do you see any speed difference?

Things to try right now:

  • If the project is on /mnt/c/..., move it to the Linux side like ~/projects/<name> and run the CLI from there. This is usually the biggest win on WSL2.
  • Try running outside tmux. It’s known that inside tmux the CLI can redraw history when panes resize, which can feel like “lag”.

If it’s still slow after moving the project, send a fresh Request ID from a run where it was clearly slow, in the CLI chat: session menu top right corner > Copy Request ID. We’ll dig in more.