Linux AppImage: /usr/bin/cursor symlink points to Electron binary instead of CLI wrapper script

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Using the AppImage version, when running cursor in the terminal it ignores some CLI flags and just opens a new window. For example:
cursor --help
cursor --version
cursor --telemetry

> cursor --version
[403431:0117/203926.426527:ERROR:electron/shell/common/node_bindings.cc:427] Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
Gtk-Message: 20:39:27.320: Failed to load module "appmenu-gtk-module"
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0
>

You can ignore the warnings - they’re not a concern, although they don’t show up when invoking as shown below.

The same cli flags work fine when running like this:

> CURSOR_MOUNT_DIR=$(ls -d /tmp/.mount_Cursor* | head -n1)

> $CURSOR_MOUNT_DIR/usr/share/cursor/bin/cursor --version
2.3.40
230922a103262db3487b753c8d1e0a7111c2d780
x64

> $CURSOR_MOUNT_DIR/usr/share/cursor/bin/cursor --help   
Cursor 2.3.40

Usage: cursor [options][paths...]

To read from stdin, append '-' (e.g. 'ps aux | grep code | cursor -')

Options
  -d --diff <file> <file>                    Compare two files with each other.
  -m --merge <path1> <path2> <base> <result> Perform a three-way merge by provi

These still work:
cursor . - works (opens cwd)
cursor /path/to/file - opens the file
cursor --wait file.txt - still blocks
cursor --diff a.txt b.txt - works
cursor --disable-extensions - starts without extensions just fine

Root Cause (suggested by Opus 4.5):

Inside the mounted AppImage, the symlink at usr/bin/cursor points to the Electron binary instead of the CLI wrapper script:
Current: usr/bin/cursor → ../share/cursor/cursor (Electron binary)
Expected: usr/bin/cursor → ../share/cursor/bin/cursor (CLI wrapper script)

The Electron binary handles path arguments natively but doesn’t process CLI flags. The CLI wrapper script at bin/cursor sets ELECTRON_RUN_AS_NODE=1 and invokes cli.js, which properly handles all flags.

Suggested fix:
Update the symlink target in AppImage packaging from ../share/cursor/cursor to ../share/cursor/bin/cursor.

Steps to Reproduce

Just run cursor --help or cursor --version on Linux (AppImage installation)

Expected Behavior

All cli flags should work

Operating System

Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.3.41
VSCode Version: 1.105.1
Commit: 2ca326e0d1ce10956aea33d54c0e2d8c13c58a30
Date: 2026-01-16T19:14:00.150Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Linux x64 5.15.0-164-generic

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report and root cause analysis.

Looks like a regression. This issue was fixed before, but it seems to have come back in recent versions. I’ve passed it to the team along with your analysis about the Electron binary symlink being used instead of the CLI wrapper.

1 Like

Please consider using the .deb or .rpm versions of the installer, depending on your flavor of linux: Download · Cursor

Hey, thanks for the suggestion. I’ve switched to .deb and although I technically have the same version (I was on the latest, and have the latest deb now), it seems that it has broken some functionality - I can’t continue any past chats (I am able to read them).

Version: 2.3.41
VSCode Version: 1.105.1
Commit: 2ca326e0d1ce10956aea33d54c0e2d8c13c58a30
Date: 2026-01-16T19:14:00.150Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Linux x64 5.15.0-164-generic

The error message I’m getting is:

Request ID: 996f16bf-3cc6-428e-95b4-b5f0496bb666
This conversation has corrupted data. You can view and export it, but new messages cannot be sent. Please start a new conversation to continue.

I’ve started cursor with cursor –verbose and I see this:

\[663216:0123/110747.876600:INFO:CONSOLE:566\] “\[composer\] Failed to deserialize conversationState: Error: Invalid hex string length”, source: vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js (566)
\[663216:0123/110747.879552:INFO:CONSOLE:13688\] “\[composer\] Error hydrating conversation checkpoint from hex string Error: Invalid hex string length \[object Object\]”, source: vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js (13688)
\[663216:0123/110747.886458:INFO:CONSOLE:13688\] “\[composer\] Error hydrating conversation checkpoint from hex string Error: Invalid hex string length \[object Object\]”, source: vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js (13688)

The last message repeats a few more times. I do have backups of the home folder from the past few days so I should be able to restore and experiment if need be. I have also just updated to 2.4.21 and the issue didn’t go away.

Currently this is not a major issue or blocker for me - more of minor inconvenience as I expected everything to work smoothly.

Should I expect other stuff to be broken? Is it safe to continue to use it as is?

Thank you.

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.