ログを開くと、同梱の ripgrep が見つからないと言っています。ところが ls で確かめると、そのファイルは ~/.cache/antigravity/bin/ の下にちゃんとあり、実行権限も付いています。存在するのに、存在しないと言われるのです。この食い違いの前で、私は何度か手が止まった経験があります。
Antigravity の CLI（agy）を Linux で使っていると、エージェントのコード検索だけが失敗する——そんな報告が、公式リポジトリの Issue に上がっています。この記事は、その報告を手がかりにして、「ファイルはあるのに no such file」と言われたときの見方を整理したものです。
何が起きているのか
Issue の報告者の環境は Ubuntu 26.04 LTS（x86_64、glibc 2.43）です。agy は ripgrep を ~/.cache/antigravity/bin/ に展開して使うのですが、その実行に失敗し、ログには次のような行が残ります。
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)報告者が file コマンドで調べたところ、この実行ファイルのインタープリタが /usr/grte/v5/lib64/ld-linux-x86-64.so.2 を指していました。一般的な Linux には、このパスは存在しません。同梱バイナリが、配布元の環境に固有のローダーの場所を前提にビルドされている、というのが報告の見立てです。
報告者によると、1.1.27、1.2.1、1.2.2、1.2.3 のいずれでも同じ症状だったそうです。私が確認した 10月24日時点では、この Issue は open のままで、コメントも付いていませんでした。以降の版で直っているかどうかは、手元で確かめていただくのが確実です。
「no such file」が指しているのは、ファイルではありません
ここがいちばん紛らわしいところです。いま思えば、私はこのメッセージを文字どおりに読みすぎていたのかもしれません。
動的リンクされた実行ファイルは、起動のときにまず「インタープリタ」と呼ばれる小さなプログラム（ローダー）を呼び出します。このローダーが共有ライブラリを読み込んでから、本体に処理を渡します。実行ファイルのヘッダーには、そのローダーの絶対パスが埋め込まれています。
カーネルが実行を始めるとき、そのパスが存在しないと、エラーは ENOENT（No such file or directory）になります。つまり、メッセージが指しているのは、実行しようとしたファイルではなく、ファイルの中に書かれたローダーのほうです。
シェルによって文言は少し変わります。bash なら「cannot execute: required file not found」、Go や Python のようにプログラムから起動すれば fork/exec: no such file or directory や FileNotFoundError です。どれも根は同じだと考えて大丈夫です。
手元で同じ状況を作ってみました
Issue の内容を、自分の手で確かめておきたいと思いました。ただし、agy 本体の挙動を再現したわけではありません。「インタープリタのパスが存在しないと、こう見える」という一般的な仕組みだけを、小さな C プログラムで確認しています。
# 何もしない小さなプログラムを、存在しないローダーを指す形でビルドする
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 # ファイルはある・実行権限もある
$ ./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 # システムのローダー経由なら動くIssue の報告者が書いている「システムのローダーに直接渡せば動く」という現象と、同じ見え方になりました。
意外だったのは ldd です。ldd ./demo_rg は、エラーにならず終了コード 0 で、依存関係をそのまま表示しました。「ldd が通るから大丈夫」とは言えないのです。切り分けには file か readelf のほうが確実でした。
切り分けの手順
同じ症状に出会ったときは、次の順に確かめます。パスの綴りを疑う前に、まずインタープリタです。
- ログに出ているバイナリのパスを控えます（agy なら
~/.cache/antigravity/bin/rg_embedded-...） fileで、interpreter の行を読みます- その interpreter のパスが自分のマシンに存在するか、
lsで確かめます - システムのローダーに直接渡して、本体が動くか確かめます
BIN=~/.cache/antigravity/bin/rg_embedded-* # ワイルドカードは実際のファイル名に置き換えてください
file $BIN | grep -o 'interpreter [^,]*'
readelf -l $BIN | grep -i 'program interpreter'
# そのパスが実在するか
ls -l /usr/grte/v5/lib64/ld-linux-x86-64.so.2
# 自分のマシンの標準ローダー（比較用）
readelf -l /bin/ls | grep -i 'program interpreter'
# ローダーに直接渡す（x86_64 の一般的なパス）
/lib64/ld-linux-x86-64.so.2 $BIN --version3 番で「存在しない」、4 番で「動く」なら、原因はほぼ決まりです。バイナリは壊れておらず、ローダーの場所だけが合っていません。
同じ文言でも、原因は一つとは限りません
「no such file」は、インタープリタ以外でも出ます。見分けるときは、次の表の順に確かめていくと、遠回りが少なくなります。
| 疑う原因 | 確かめ方 | 見え方の目安 |
|---|---|---|
| インタープリタのパスが存在しない | readelf -l で interpreter を読み、ls で実在を確認 | ローダー経由なら動く |
| CPU アーキテクチャが違う | file の出力（x86-64 か ARM aarch64 か）と uname -m を比較 | ローダー経由でも動かない |
| noexec でマウントされている | mount でキャッシュ先のオプションを確認 | 多くは「Permission denied」になる |
| 実行権限がない | ls -l で x ビットを確認 | 「Permission denied」になる |
この表は、あくまで私が普段使っている確認順です。環境によって例外はあるかもしれません。
一時的な回避策と、そのときの線引き
報告者は、存在しないパスにシステムのローダーへのシンボリックリンクを置くことで、回避したと書いています。私の手元でも、デモ用のバイナリで同じ操作が効くことを確かめました。
# 標準のローダーの場所を確認してから作る（x86_64 の例）
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
# 元に戻すとき
sudo rm -r /usr/grteただし、これは回避策であって、直し方ではありません。システム領域に、公式が想定していない場所のリンクを足す操作です。共有の開発マシンや、管理者の許可が必要な環境では、無断で行わないようにしたい手段だと感じます。
もう一つ、手元にシステムの ripgrep（/usr/bin/rg）を入れても、それは効かなかったと報告されています。agy は、同梱のコピーを先に見つけてしまうからです。PATH を整えれば済む問題ではない、という点は覚えておくと無駄足を減らせます。
私自身は、個人開発でいくつかの環境を行き来するたびに、こうした一時回避を「いつ外すか」まで書き残すようにしています。リンクを作った日付と、外す条件を一行だけメモしておくのです。
回避策は、作った瞬間に外す条件も一緒に書く。 この一文だけは、急いでいる夜でも守るようにしています。
次にやること
まず file で、interpreter の行を一度だけ読んでみてください。それがシステムに存在しなければ、この記事の症状と同じです。存在するのに動かないなら、別の原因（アーキテクチャの違い、実行権限、ファイルシステムが noexec でマウントされているなど）を疑う順番になります。
直るまでの待ち方は、人それぞれだと思います。リンクを作るか、公式の修正を待つか、その環境では検索まわりの機能を諦めるか。どれを選んでも、Issue のページを時々見に行く習慣だけは残しておきたいと、いまも感じています。