I’m encountering an issue with the Cursor Agent/CLI on my Raspberry Pi 5 (ARM64).
The installer completes successfully, but running cursor-agent results in the following error:
/home/XXX/.local/bin/cursor-agent: line 11: /home/XXX/.local/share/cursor-agent/versions/2026.01.09-6d4aaf8/node: cannot execute: required file not found
Same with agent.
The file seems to exists: file /home/XXX/.local/share/cursor-agent/versions/2026.01.09-6d4aaf8/node returns:
/home/XXX/.local/share/cursor-agent/versions/2026.01.09-6d4aaf8/node: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=2dea07b258a04d58186d4f0943c77d33f3a79e9b, for GNU/Linux 3.7.0, with debug_info, not stripped, too many notes (256)
I have a very vanilla Raspberry Pi 5 setup: Raspbian 12 bookworm, kernet 6.12.47+rpt-rpi-v8, aarch64. The installer successfully detected the architecture (Detected linux/arm64)
My node version is v18.20.4, but I installed it in order to solve this (spoiler, it didn’t) since I’m using node in containers.
Could you please help resolve this issue, maybe there is a compatibility issue with the architecture? Let me know if you need further details.
Thank you!
Best regards,
Olivier
Steps to Reproduce
SSH connection to a raspberry pi 5 with raspbian.
Installing Cursor: curl https://cursor.com/install -fsS | bash
Trying to run cursor: cursor-agent
Expected Behavior
Cursor agent is returning an error instead of running.
Operating System
Linux
Current Cursor Version (Menu → About Cursor → Copy)
I believe this is a dependency error specific to the dynamic loader, even though the binary file itself is present and correct for ARM64. When an executable throws “cannot execute: required file not found,” it usually indicates that the dynamic linker cannot locate one of the core shared libraries required by the bundled node binary. I suggest running ldd on that specific node path (e.g., ldd /home/XXX/.local/share/cursor-agent/versions/…/node) to identify which library is missing, as you may need to manually install standard runtime packages like libstdc++6 on your Bookworm installation. This often resolves issues where pre-compiled binaries are missing common library references.
Hello @Rao_Athar, thank you very much for your reply!
Indeed, it seems that you are on point.
I’m struggling with some libgcc some libraries are missing and due to some unmet dependencies I’m having issues to install them.
I’ll take some time to try to fix that and I’ll come back if I’m stuck.
Thanks again!
No worries at all, Oruas! Glad to hear the suggestion was helpful.
For those libgcc and unmet dependencies, I suggest trying sudo apt --fix-broken install first—it often clears up those configuration blocks that prevent new installs. Also, it’s worth double-checking that your Raspberry Pi OS is actually the 64-bit version (uname -m should show aarch64), as 32-bit environments can be very finicky with these specific Node binaries.
Let us know how it goes after the ‘fix-broken’ command, we are here to help!
Thanks for your messages. Sorry for the late reply, I got very busy and couldn’t find the time to answer.
Unfortunately I couldn’t make it work:
`ldd …` returns a `not a dynamic executable` message
trying to install the missing depenencies (with sudo apt –fix-broken install) didn’t work either: it seems that there is a conflict between my libgcc-s1 and libgcc-s1:arm64 (I promise uname -m returns aarch64)
Here is a quick summary of what happened during my debugging session: the node binary in the Cursor Agent package required the ARM64 version of certain libraries (libc6:arm64, libgcc-s1:arm64, libidn2-0:arm64), but the system had conflicts with the existing ARMv7/ARMv8 versions of these libraries.
Root Cause (according to Mistral, I’m a bit lost here tbh):
The node binary in the Cursor Agent package is dynamically linked and requires the /lib/ld-linux-aarch64.so.1 interpreter, which was missing.
The Raspberry Pi OS repositories did not provide the ARM64 versions of the required libraries (libgcc-s1:arm64, libidn2-0:arm64).
Attempts to install these libraries manually led to dependency conflicts with the existing ARMv7/ARMv8 libraries on the system.
Attempted Fixes:
Enabling ARM64 architecture and updating repositories.
Adding Debian ARM64 repositories to install the required libraries.
Manually downloading and installing .deb packages for ARM64 libraries.
Using aptitude to resolve dependency conflicts.
Why It Couldn’t Be Fixed:
The Raspberry Pi OS (based on Debian Bookworm) and the Debian ARM64 repositories had conflicting versions of the libraries.
The system’s existing ARMv7/ARMv8 libraries conflicted with the ARM64 versions required by the node binary.
The libgcc-s1:arm64 and libidn2-0:arm64 packages were not available in the configured repositories, and manual installation led to unresolvable dependency conflicts.
Sorry for the IA summary, but it was easier to ask it a summary of all our exchanges during the debugging session.
Then, I tried to run it inside a docker but impossible to install the missing dependencies libc6:arm64 libgcc-s1:arm64 libidn2-0:arm64. I tried several workarounds, I ended up breaking my docker installation. I’ve fixed it, it wasn’t a big deal but that was my signal that maybe I had to accept my fate and wait for the a Raspbian version ^^’
I hope this summary helps, I really appreciated your help. I’ll keep on using cursor on my laptop for now.
Thanks again!
Regarding the cursor-agent issue on your Raspberry Pi 5 (ARM64) with Raspbian 12 Bookworm, the cannot execute: required file not found error for the node binary often points to a dynamic linker problem, even if the file exists.
The most effective next step is to use ldd to identify missing dependencies. Please run the following command:
(Remember to replace /home/XXX/ with your actual path).
Look for any lines in the output that say => not found. These indicate missing shared libraries. A common cause for this on Bookworm (which uses glibc 2.36) is that the node binary might have been compiled against a newer glibc version (e.g., 2.38+). If ldd shows a glibc version mismatch, it confirms this incompatibility.
Sharing the output of the ldd command will help us determine the exact issue and suggest further solutions.
Hello, sorry for the late reply (again). I got a lot of stuff in my non-coding life.
I reinstalled a raspbian from scratch and it worked: my “vanilla” distrib was not so vanilla after all.
I don’t know how I manage to broke it, but a fresh install make it perfectly fine.
Thank you again for your time and answer.
AFAIC, this issue is solved
