The log says the bundled ripgrep can't be found. Yet ls shows it sitting in ~/.cache/antigravity/bin/, executable bit and all. A file that exists but is reported as missing is the kind of thing that stops my hands on the keyboard for a minute.
A report on the official repository describes exactly this on Linux: the agent's code search fails, and the only clue is a "no such file or directory" error. I'll use that report as a starting point and write down how I read this class of error, as an indie developer who hops between machines more often than I'd like.
What the report says
The reporter runs Ubuntu 26.04 LTS (x86_64, glibc 2.43). agy extracts ripgrep into ~/.cache/antigravity/bin/ and tries to run it. The log shows:
ripgrep resolved to /home/<user>/.cache/antigravity/bin/rg_embedded-... (embedded copy)
ripgrep at /home/<user>/.cache/antigravity/bin/rg_embedded-... could not be executed (fork/exec ...: no such file or directory)Running file on the binary shows its interpreter is /usr/grte/v5/lib64/ld-linux-x86-64.so.2. That path doesn't exist on a typical Linux system. The report's reading is that the bundled binary was built against a loader location specific to its build environment.
The reporter saw the same behavior on 1.1.27, 1.2.1, 1.2.2 and 1.2.3. When I checked on October 24, the issue was still open with no comments. I can't tell you whether later versions fix it, so please verify on your own install.
The message isn't about the file you ran
A dynamically linked executable doesn't start by itself. Its header embeds the absolute path of an "interpreter" — the dynamic loader — and the kernel starts that loader first. If the path doesn't exist, the kernel returns ENOENT, "No such file or directory".
So the error is about the loader named inside the file, not the file you tried to run. Bash words it as "cannot execute: required file not found". A Go program shows fork/exec: no such file or directory; Python raises FileNotFoundError. Same root cause.
Reproducing it by hand
I wanted to see it with my own eyes. To be clear, this does not reproduce agy itself; it only demonstrates the general mechanism with a tiny C program whose interpreter doesn't exist.
printf '#include <stdio.h>\nint main(){puts("hello");return 0;}\n' > d.c
gcc -o demo_rg d.c -Wl,--dynamic-linker=/usr/grte/v5/lib64/ld-linux-x86-64.so.2$ ls -l demo_rg
-rwxr-xr-x 1 root root 15960 ... demo_rg # exists, executable
$ ./demo_rg
bash: ./demo_rg: cannot execute: required file not found
$ readelf -l demo_rg | grep -i interpreter
[Requesting program interpreter: /usr/grte/v5/lib64/ld-linux-x86-64.so.2]
$ /lib64/ld-linux-x86-64.so.2 ./demo_rg
hello # works via the system loaderThis matches what the reporter describes: handing the binary to the system loader makes it run.
One thing surprised me: ldd ./demo_rg exits with 0 and prints its dependencies without complaint. A clean ldd is not proof that the binary can start. file or readelf is the more reliable check.
A short diagnostic routine
Before suspecting the path spelling, check the interpreter:
- Note the binary path from the log.
- Read the interpreter line from
fileorreadelf. - See whether that path exists on your machine.
- Pass the binary to the system loader and see whether it runs.
BIN=~/.cache/antigravity/bin/rg_embedded-* # replace the wildcard with the real file name
file $BIN | grep -o 'interpreter [^,]*'
readelf -l $BIN | grep -i 'program interpreter'
ls -l /usr/grte/v5/lib64/ld-linux-x86-64.so.2
# your system's own loader, for comparison
readelf -l /bin/ls | grep -i 'program interpreter'
/lib64/ld-linux-x86-64.so.2 $BIN --versionIf step 3 says "missing" and step 4 says "runs", the binary is fine and only the loader location is wrong.
Same message, different causes
"No such file" shows up for other reasons too. This is the order I usually check them in:
| Suspect | How to check | What you'd see |
|---|---|---|
| Interpreter path doesn't exist | Read it with readelf -l, then ls it | Runs when passed to the loader |
| Wrong CPU architecture | Compare file output (x86-64 vs aarch64) with uname -m | Fails even via the loader |
| Mounted noexec | Check mount options of the cache directory with mount | Usually "Permission denied" |
| Missing execute bit | Check the x bit with ls -l | "Permission denied" |
This is my own checking order, and there may be exceptions depending on your environment.
A workaround, and where I draw the line
The reporter worked around it with a symlink from the missing path to the system loader. I confirmed the same trick works on my demo binary.
# check your loader's actual location first (x86_64 example)
sudo mkdir -p /usr/grte/v5/lib64
sudo ln -s /lib64/ld-linux-x86-64.so.2 /usr/grte/v5/lib64/ld-linux-x86-64.so.2
# to undo
sudo rm -r /usr/grteThis is a workaround, not a fix. You're adding a link under a system directory that nobody planned for. I wouldn't do it on a shared machine or anywhere you need approval to change system files.
Also, the reporter notes that installing a system ripgrep (/usr/bin/rg) didn't help, because agy picks the embedded copy first. Tweaking PATH won't save you here, which is worth knowing before you spend an evening on it.
On my own machines, I try to write down when a temporary workaround should come out. One line is enough: the date I made it and the condition for removing it.
Every workaround gets an exit condition the moment it's created. I try to keep that rule even on rushed nights.
What to try next
Run file once and read the interpreter line. If that path doesn't exist on your system, you're looking at this exact problem. If it does exist and the binary still won't start, look at other causes: architecture mismatch, permissions, or a filesystem mounted noexec.
How you wait for a fix is up to you: add the link, wait for an official fix, or live without search in that environment for now. Whichever you choose, I'd keep an eye on the issue page.