[0.46.0] Python environment issues on Linux AppImage

Bug Reports
1

As posted on: Python evnironment issue in Linux AppImage · Issue #2734 · getcursor/cursor · GitHub

ACK: I will post this on the forums as well, its pretty critical in the Linux Build.

Version: 0.46.0
VSCode Version: 1.96.2
Commit: aff57e1d9a74ed627fb5bd393e347079514436a0
Date: 2025-02-21T04:49:24.841Z
Electron: 32.2.6
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Linux x64 6.8.0-1020-oem

Python path configuration:
  PYTHONHOME = '/tmp/user/1000/.mount_cursorBLFrdY/usr/'
  PYTHONPATH = '/tmp/user/1000/.mount_cursorBLFrdY/usr/share/pyshared/:'
  program name = '/usr/bin/python3'
  isolated = 0
  environment = 1
  user site = 1
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = '/tmp/user/1000/.mount_cursorBLFrdY/usr/lib/python3.12'
  sys._base_executable = '/usr/bin/python3'
  sys.base_prefix = '/tmp/user/1000/.mount_cursorBLFrdY/usr/'
  sys.base_exec_prefix = '/tmp/user/1000/.mount_cursorBLFrdY/usr/'
  sys.platlibdir = 'lib'
  sys.executable = '/usr/bin/python3'
  sys.prefix = '/tmp/user/1000/.mount_cursorBLFrdY/usr/'
  sys.exec_prefix = '/tmp/user/1000/.mount_cursorBLFrdY/usr/'
  sys.path = [
    '/tmp/user/1000/.mount_cursorBLFrdY/usr/share/pyshared',
    '/home/saber7ooth/Documents/repos/comfyg',
    '/tmp/user/1000/.mount_cursorBLFrdY/usr/lib/python312.zip',
    '/tmp/user/1000/.mount_cursorBLFrdY/usr/lib/python3.12',
    '/tmp/user/1000/.mount_cursorBLFrdY/usr/lib/python3.12/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x000078a6d9b58740 (most recent call first):
  <no Python frame>

Happens when doing anything related to npm. Running cursor . also ends me up in the AppImage’s virtual directory after putting cursor into /opt/cursor and adding that to PATH with my usual ~/.bashrc alias. This did not occour prior to updating to 0.46.0:

Here’s that portion of ~/.bashrc:

cursor() {
  # Run the cursor command and suppress background process output completely
  (nohup /opt/cursor/cursor.AppImage --no-sandbox "$@" >/dev/null 2>&1 &)
}

I use the usual nohup trick to avoid the AppImage forking itself into the foreground/taking over the terminal process. Again, nothings changed, and this worked before the update.

RELATED ISSUE Cursor 0.46: Conda Environment Activation Error and Package Recognition Issues bumping this for this other user as it has not been addressed, and also have the problem

4 Likes
2

I have I believe problems that may be of similar origin. I reported them here

3

I managed to fix this issue on Linux. See for details Cursor 0.46.0 adds $PYTHONHOME to env with wrong value - #9 by serghei

4

I was stuck on this problem for a while, and found a robust solution. From Cursor’s built-in terminal, Python crashed with this message:

Python path configuration:
  PYTHONHOME = '/tmp/.mount_CursorGcM8M1/usr/'
  PYTHONPATH = '/tmp/.mount_CursorGcM8M1/usr/share/pyshared/:'
  program name = './Cursor-0.46.8-be4f0962469499f009005e66867c8402202ff0b7.deb.glibc2.25-x86_64.AppImage'
  isolated = 0
  environment = 1
  user site = 1
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = '/tmp/.mount_CursorGcM8M1/usr/lib64/python3.12'
  sys._base_executable = '/home/fadein/Cursor-0.46.8-be4f0962469499f009005e66867c8402202ff0b7.deb.glibc2.25-x86_64.AppImage'
  sys.base_prefix = '/tmp/.mount_CursorGcM8M1/usr/'
  sys.base_exec_prefix = '/tmp/.mount_CursorGcM8M1/usr/'
  sys.platlibdir = 'lib64'
  sys.executable = '/home/fadein/Cursor-0.46.8-be4f0962469499f009005e66867c8402202ff0b7.deb.glibc2.25-x86_64.AppImage'
  sys.prefix = '/tmp/.mount_CursorGcM8M1/usr/'
  sys.exec_prefix = '/tmp/.mount_CursorGcM8M1/usr/'
  sys.path = [
    '/tmp/.mount_CursorGcM8M1/usr/share/pyshared',
    '/home/fadein',
    '/tmp/.mount_CursorGcM8M1/usr/lib64/python312.zip',
    '/tmp/.mount_CursorGcM8M1/usr/lib64/python3.12',
    '/tmp/.mount_CursorGcM8M1/usr/lib64/python3.12/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00007fb7807830c0 (most recent call first):
  <no Python frame>

There are two things wrong with this picture.

1. Incorrect sys.path

First, the sys.path is all wrong. It contains a bunch of non-existent paths within the AppImage’s mountpoint. You can override this from outside the AppImage by setting the environment variable PYTHONPATH before launching. Not sure what your PYTHONPATH should look like? Run this command in your shell:

python -c 'import sys; print("export PYTHONPATH=" + ":".join(filter(lambda s: s, sys.path)))'

This creates an export command for your shell that will be seen by Cursor (the filter() removes empty strings from sys.path)

2. Wrong sys.executable

The second problem is seen on the line showing the value of ‘sys.executable’. That variable should point to your Python executable, not to the AppImage itself. I don’t think this is a problem of Cursor. This happens in other AppImages, too. Another way to experience this is to run cat /proc/self/cmdline; this should show the path to the cat program itself. For some reason, child processes that fork from the AppImage inherit this. On Linux, Python appears to populate sys.executable from cmdline. This creates problems for the venv module because it copies this value into the virtual environment’s pyvenv.cfg.

Interestingly, cat /proc/self/comm always shows the correct program name. It’s too bad Python doesn’t use this value instead!

My workaround is to mount the AppImage’s temp directory instead of launching Cursor directly:

  1. First terminal: Run ./Cursor*.AppImage --appimage-mount. This prevents the AppImage from starting Cursor and instead prints the path to its temporary mountpoint, which stays mounted until you press Ctrl-C.
  2. Second terminal: Export PYTHONHOME as described above, then run AppRun from the root of the mountpoint. Child processes spawned from this instance of Cursor will no longer inherit the wrong cmdline.

This is clunky because it takes two terminals. In this instance of Cursor I (and the AI) can create virtual environments and otherwise use Python normally. I hope this helps you, too.