Cursor CLI command incorrectly handles paths with spaces (v1.7)

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

After updating to Cursor 1.7, the cursor CLI command no longer properly handles file paths containing spaces. This worked correctly in v1.6.

Steps to Reproduce

$ cursor ~/my\ project/

Expected Behavior (v1.6)

Cursor should open with a single folder: my project

Actual Behavior (v1.7)

Cursor opens with two files:

  • An empty file named my
  • An empty file named project

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.38
VSCode Version: 1.99.3
Commit: fe5d1728063e86edeeda5bebd2c8e14bf4d0f960
Date: 2025-10-06T18:18:58.523Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

Additional Information

Paths without spaces work correctly in v1.7. The issue only occurs with paths containing spaces.

Does this stop you from using Cursor

Yes - Cursor is unusable

2 Likes

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

If I have a folder named ad hoc stuff, using the Cursor shell (cursor "ad hoc stuff") to try to open it does not work properly. It simply creates new files named ad, hoc, and stuff, respectively, in the currently active editor.

VSCode’s code command handles this case properly.

Steps to Reproduce

  • Create a folder with spaces in the name
  • Try to open it with the cursor shell command

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.44 (Universal)
VSCode Version: 1.99.3
Commit: 9d178a4■■■89981b62546448bb32920a8219a5d0
Date: 2025-10-10T15:43:37.500Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 25.0.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the report. This is a known issue with the Cursor CLI’s argument handling - it affects paths/folders with spaces.

Our team is aware, and it has been passed to the developers. The root of the problem is how the CLI script handles argument escaping with eval.

We’ll update the information once this is fixed. Thanks for the detailed report.

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

If you try to open a file with Cursor CLI that has a space in the name, and it’s properly quoted or escaped, Cursor cannot open it.

# This opens "my" and "file.txt" as two separate files, since you're passing two filenames.
cursor my file.txt

# This should open one file called `my file.txt`, because the filename is quoted. But, it incorrectly opens two!
cursor "my file.txt" 

# The space is escaped here, so it should still open a file called `my file.txt`.
cursor my\ file.txt

Steps to Reproduce

cursor “my file.txt”
or
cursor my\ file.txt

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

1.7.46
b9e5948c1ad20443a5cecba6b84a3c9b99d62580
arm64

For AI issues: which model did you use?

.

For AI issues: add Request ID with privacy disabled

.

Additional Information

.

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like

Any news on fixing this?
This is kind of a major thing that is blocking some critical things.
Both the ““ and direct escaping on path is really base level stuff as we have people working on modern OSs that allow not just spaces but special characters in the paths.
If git supports these then having and IDE that does not is a big deal.

The fact that this works on Windows makes this even worse, as we have teams that need to work on both.

Does this stop you from using Cursor

Yes - Cursor is definitely unusable with this

1 Like