IBM Project Bob(このエントリでは以降 Bob IDEとします)は、IBMが開発したAIエージェント搭載のIDE(VS Codeのフォーク)です。AIエージェントにコマンドを実行させ、プログラムの生成や実行を自動化できる、いわゆるAIコーディングエージェント系のツールとなっています。
私は、普段の開発環境としてWSL(Windows Subsystem for Linux)を使っているため、Bob IDEもWSLから起動して使おうとしたところ、AIエージェントのコマンド実行で問題が発生しました。この現象がちょっと複雑なので、このエントリでは、この問題の原因を特定し、解決するまでの過程を記録します。かなり苦労しました🥲
ネット上にあまり情報がないので、同じ問題で困っている人の参考になれば幸いです。
動作環境
| 項目 | 値 |
|---|---|
| Bob IDE | Windows版のインストール |
| WSLディストリビューション名 | ibm(Ubuntu 22.04にこの名前を付けました) |
| WSLユーザー | user2404 |
| プロジェクトパス | /home/user2404/bob-test |
| 起動方法 | WSLターミナルから bobide . |
👉️VSCodeでも、WSLで起動する場合には`code .`という形で実行することで、Windows側のVSCodeが起動しますが、Bob IDEも同様にWSLから bobide . でWindows側のBob IDEが起動します。
問題の発生
WSLターミナルから bobide . でBob IDEを起動し、AIエージェントに「Pythonスクリプトを実行して」と依頼したところ、コマンドの実行が何度も失敗しました。今回のプロジェクトでは仮想のログファイルを生成するためのPythonスクリプト generate_logs.py を用意していましたが、エージェントはこのスクリプトを実行できませんでした。
エージェントの実行ログを見てみると、以下のような流れで5回も試行錯誤していました😫😫😫
【試行1】素直にcd + python
cd //wsl.localhost/ibm/home/user2404/bob-test && python generate_logs.py --out sample.log --lines 300 --seed 42
結果
'\\wsl.localhost\ibm\home\user2404\bob-test' CMD.EXE ではサポートされていません。 UNC パスはサポートされません。Windows ディレクトリを既定で使用します。
実際は文字化けしているので、このようにはみえません。これはShift-JISのCMD.EXEエラーメッセージです。
UNCというキーワードが出ていると思いますが、UNCとはネットワークドライブなどで使われる \\server\share\path のような形式のパスのことです。CMD.EXEはこの形式のパスを cd コマンドで受け付けないため、エラーになります。
ここでは、Bob IDEのエージェントはCMD.EXEを使ってコマンドを実行していることがわかります。すこし不穏です。
【試行2】cdなしで直接実行
先程のErrorを受けて、Bob IDEのエージェントは、cd を使わずに直接コマンドを実行することを試みました。
python generate_logs.py --out sample.log --lines 300 --seed 42
結果
python: can't open file 'C:\\Windows\\generate_logs.py': [Errno 2] No such file or directory
なんと、カレントディレクトリが C:\Windows になっている!つまりWindows側のパスを基準にしてコマンドを実行しようとしていることがわかります。これもCMD.EXE経由で実行していることが原因です。
【試行3】wslコマンドでフルパス指定
更に、Errorを受けて、Bob IDEのエージェントは、wsl コマンドを使ってWSL上でコマンドを実行することを試みました。
wsl python3 /home/user2404/bob-test/generate_logs.py --out /home/user2404/bob-test/sample.log --lines 300 --seed 42
結果
python3: can't open file '/home/user2404/bob-test/generate_logs.py': [Errno 2] No such file or directory
wsl コマンドだけではデフォルトのディストリビューションが使われるため、ファイルが見つかりません。
デフォルトのディストリビューション名のwsl環境を使用しているのであれば、ここで解決する可能性はあります(未確認)
【試行4】ファイルの存在確認とbash -c
そして、Bob IDEのエージェントは、wsl コマンドでディストリビューションを指定せずに、bash -c でコマンドを実行することを試みました。
wsl bash -c "cd ~/bob-test && python3 generate_logs.py --out sample.log --lines 300 --seed 42"
結果
bash: line 1: cd: /home/user2404/bob-test: No such file or directory
まだディストリビューションが合っていないため、ファイルが見つかりません。
【試行5】ディストリビューション名を明示(成功)
最終的に、Bob IDEのエージェントは、wsl コマンドでディストリビューションを指定して、bash -c でコマンドを実行することを試みました。
wsl -d ibm bash -c "cd /home/user2404/bob-test && python3 generate_logs.py --out sample.log --lines 300 --seed 42"
結果
✓ 300行のログを sample.log に生成しました
やっと成功しました。 しかし、たった1つのコマンドを実行するために5回の試行錯誤が必要でした。 うまくいったとはいえ流石に効率が悪すぎるので、解決策を模索することにしました。
原因の分析
試行のログなどから原因は明確です。
Bob IDEのAIエージェントは、WSLから起動しても、コマンド実行をWindows CMD.EXE経由で行っている。
Bob IDEはVS Codeの完全フォークのWindows上で動作するElectronアプリケーションです。そして、WSLの bobide コマンドは、実はWSL interop機能を使ってWindows側の Bob-IDE.exe を呼び出しているだけです。つまり内部的にはWindows上のプロセスとして動作しており、エージェントがコマンドを実行する際もWindowsの標準シェルであるCMD.EXEが使われます。
CMD.EXEにはUNCパス(\\wsl.localhost\...)への cd ができないという制限があるため、WSL上のプロジェクトパスに移動できず、コマンドが失敗しています。
試行錯誤した対処法
この問題を解決するために、まず以下のアプローチを試しましたが、いずれもエージェントのコマンド実行には効果がありませんでした。
settings.json のターミナルプロファイル変更
統合ターミナルやオートメーション用のシェルをWSL bashに変更する設定(terminal.integrated.defaultProfile.windows、automationProfile.windows 等)を試みました。
この設定により統合ターミナルを開いたときのデフォルトシェルはWSL bashになりましたが、AIエージェントのコマンド実行には反映されませんでした。
エージェントは terminal.integrated の設定とは別の経路(おそらく child_process.exec() 相当のNode.js API?)でコマンドを実行しているように考えれます。
なお、この設定自体はエージェントの実行結果を手動で確認する際に便利なため、後述の手順3で推奨設定として紹介しています。
最終的な解決策 AGENTS.md によるエージェント指示
なぜこの方法が有効なのか
Bob IDEのAIエージェントは、コマンドの実行自体はCMD.EXEに渡しますが、どのようなコマンド文字列を組み立てるかはLLM(AI)が判断しているようです つまり、LLMに対して「最初からこの形式でコマンドを実行しろ」と指示すれば、CMD.EXE経由であっても正しいコマンドが実行されるということです。
その設定を行うのが、Bob IDEのプロジェクトルートにある .bob/ ディレクトリ内の AGENTS.md ファイルとなります。ここにコマンド実行のルールを書いておくことで、エージェントの挙動を制御が可能になります。
そのため、Bob IDEの使用開始時に /init コマンドを実行すると、プロジェクトルートに .bob/ フォルダが生成され、モードごとの AGENTS.md ファイルが作成されます。このファイルにコマンド実行のルールを書くことで、エージェントの挙動を制御できます。
.bobディレクトリの構造は以下のようになります。rules-に続く名前がBob IDEのモード名となります。planモードのみ、architectになっているようなので注意してください。
.bob/ ├── rules-advance/AGENTS.md ├── rules-architect/AGENTS.md ├── rules-ask/AGENTS.md └── rules-code/AGENTS.md
設定手順
【手順1】WSL interopの有効化
まずWSLからWindows側のアプリケーションを起動できるように、interopを有効化します。(デフォルトは有効かされていますが、念の為に行うほうがいいでしょう)
WSLのディストリビューションで/etc/wsl.conf を編集する。
[interop] enabled=true appendWindowsPath=true
設定後、PowerShellから再起動します:
PS> wsl --shutdown
確認方法
$ cat /proc/sys/fs/binfmt_misc/WSLInterop # 「enabled」と表示されればOK

【手順2】AGENTS.md にコマンド実行ルールを追記
プロジェクトディレクトリでBob IDEを起動し、チャットで /init を実行して .bob/ フォルダを生成する。
補足
/initはプロジェクトの内容や用途について対話的に質問してきます。モードごとのルールを適切に生成するためのものですが、やや手間がかかります。「デフォルトでシンプルに作成して」のように返すと、深掘りせずに生成してくれることがあります。
その後、.bob/rules-*/AGENTS.md の全ファイルにコマンド実行ルールを追記します
.bob/rules-ask/AGENTS.md(Askモード用).bob/rules-architect/AGENTS.md(Planモード用).bob/rules-code/AGENTS.md(Codeモード用).bob/rules-advance/AGENTS.md(Advancedモード用)
WSLのコマンド実行ルールは環境に依存しますが、どのモードでもコマンド実行が発生する可能性があるため、全モードに追記しておくのが確実かなと思います。モードごとにルールを分けるのは、権限や振る舞いの制限(例:「Askモードではファイル変更禁止」など)をかけたい場合に有効です。もし特に分ける必要がなければ、全モードに同じルールを追記しておくのが簡単です。
各ファイルのタイトル直後に以下を追加(ディストリビューション名ibm、プロジェクト名/home/user2404/bob-testの場合)
## ⚠️ Command Execution Rules (CRITICAL) This project runs on WSL distribution "ibm" at /home/user2404/bob-test. The IDE terminal uses Windows CMD.EXE, which CANNOT handle Linux commands directly. **ALL terminal commands MUST use this format:** wsl -d ibm bash -c "cd /home/user2404/bob-test && <your command here>" **Examples:** - Run Python: `wsl -d ibm bash -c "cd /home/user2404/bob-test && python3 main.py"` - Check files: `wsl -d ibm bash -c "cd /home/user2404/bob-test && ls -la"` - Run pip: `wsl -d ibm bash -c "cd /home/user2404/bob-test && pip install -r requirements.txt"` **NEVER do any of the following:** - Use `cd \\wsl.localhost\...` (CMD.EXE does not support UNC paths) - Run `python`, `bash`, `ls` etc. directly without `wsl -d ibm bash -c` - Try multiple approaches - use the format above on the FIRST attempt
見てわかると思いますが、これはAIエージェントに対する強力な指示プロンプトですよね。必ず守るように強調しています。
【手順3】settings.json で統合ターミナルを設定(推奨)
エージェントのコマンド実行には直接効きませんが、手動でターミナルを使う際にWSL bashがデフォルトで起動するようになるため、設定を推奨します。
【Ctrl+Shift+P】でコマンドパレットを開き、Preferences: Open User Settings (JSON)を実行して、以下の設定を追加しました。設定後、Bob IDEを再起動します。

{ "terminal.integrated.defaultProfile.windows": "WSL (ibm)", "terminal.integrated.profiles.windows": { "WSL (ibm)": { "path": "wsl.exe", "args": ["-d", "ibm", "--cd", "~"] } }, "terminal.integrated.automationProfile.windows": { "path": "wsl.exe", "args": ["-d", "ibm"] } }
検証結果
設定後にエージェントにコマンドを実行させたところ、1回目の試行で成功しました。5回から1回への改善です。
テストコマンド pwd && echo $SHELL の結果:
/home/user2404/bob-test /bin/bash
なお、CMD.EXE経由で wsl コマンドを呼んでいるため、毎回以下の表示ノイズ(文字化け)が出ます。

'\\wsl.localhost\ibm\home\user2404\bob-test' UNC パスはサポートされません。Windows ディレクトリを既定で使用します。
⚠️これはCMD.EXEがUNCパスへの cd に失敗したメッセージですが、その後のWSLコマンド自体は正常に実行されるため実害はありません。
注意点:プロジェクト単位の設定
AGENTS.md は .bob/ フォルダ内にあるため、プロジェクトごとの設定です。新しいWSLプロジェクトを開くたびに同じ手順が必要になります(settings.json と wsl.conf はグローバル設定なので一度だけでOK)。
テンプレートで手間を減らす
毎回手動で追記するのは面倒なので、テンプレート化しておくと便利です。
まず、ホームディレクトリにテンプレートファイルを作成します。
cat > ~/bob-wsl-rules-template.md << 'TEMPLATE' ## ⚠️ Command Execution Rules (CRITICAL) This project runs on WSL distribution "ibm" at __PROJECT_PATH__. The IDE terminal uses Windows CMD.EXE, which CANNOT handle Linux commands directly. **ALL terminal commands MUST use this format:** wsl -d ibm bash -c "cd __PROJECT_PATH__ && <your command here>" **Examples:** - Run Python: `wsl -d ibm bash -c "cd __PROJECT_PATH__ && python3 main.py"` - Check files: `wsl -d ibm bash -c "cd __PROJECT_PATH__ && ls -la"` - Run pip: `wsl -d ibm bash -c "cd __PROJECT_PATH__ && pip install -r requirements.txt"` **NEVER do any of the following:** - Use `cd \\wsl.localhost\...` (CMD.EXE does not support UNC paths) - Run `python`, `bash`, `ls` etc. directly without `wsl -d ibm bash -c` - Try multiple approaches - use the format above on the FIRST attempt TEMPLATE
次に .bashrc にヘルパー関数を追加
# Bob IDE WSL初期化関数
bob-wsl-init() {
local project_path=$(pwd)
local template="$HOME/bob-wsl-rules-template.md"
if [ ! -f "$template" ]; then
echo "テンプレートが見つかりません: $template"
return 1
fi
for f in .bob/rules-*/AGENTS.md; do
if [ -f "$f" ]; then
local rules=$(sed "s|__PROJECT_PATH__|${project_path}|g" "$template")
if grep -q "Command Execution Rules" "$f"; then
echo "スキップ(追記済み): $f"
else
sed -i "1a\\
\\
${rules}" "$f"
echo "追記完了: $f"
fi
fi
done
}
新規プロジェクトでBob IDEを起動した後、WSLターミナルに戻って以下を実行するだけで、*-AGENTS.md にWSLコマンド実行ルールが追記されます。
$ cd ~/new-project $ bobide . # Bob IDEのチャットで /init を実行し、WSLターミナルに戻って $ bob-wsl-init
補足(再掲):
/initはプロジェクトの内容や用途について対話的に質問してきます。モードごとのルールを適切に生成するためのものですが、やや手間がかかります。「デフォルトでシンプルに作成して」のように返すと、深掘りせずに生成してくれることがあります。

技術的な推測
なぜファイルは見えるのにコマンドだけ失敗するのか
Bob IDEではWSL上のファイルの閲覧・編集は問題なく動作します。サブディレクトリ内のファイル名を一覧したり、ファイルの中身を確認することもできます。コマンド実行だけが失敗するのは、両者の実行に関する方法が異なるためのようです。
| 操作 | 経路 | UNCパス対応 |
|---|---|---|
| ファイルの読み書き | Windows ファイルI/O API | 対応 |
| ディレクトリ一覧 | Windows ファイルI/O API | 対応 |
| コマンド実行 | CMD.EXE の cd |
非対応 |
エディタのファイル操作はWindowsのファイルI/O APIを使って行っているため、問題なく成功します。つまりBob IDEからすると、WSL上のファイルもWindows上のファイルと同じように読み書きできます。
一方、コマンド実行は child_process.exec() 等のNode.js APIでシェルプロセスを起動し、WindowsではデフォルトでCMD.EXEが使われます。そのため、CMD.EXEの cd コマンドにはUNCパスを受け付けないという制限が発生し、ここだけが失敗しているように考えます。
今回の問題はWindows OS全体ではなく、CMD.EXEだけが持つ制限と言えそうです。ファイル操作は正常に動くのにコマンド実行だけ壊れるという、一見不思議な現象が起きるのはこのためです。
エージェントのツールレベルでの影響
実際の検証で、Bob IDEのエージェントは mkdir コマンド(execute_command ツール)でディレクトリ作成に失敗した後、write_to_file ツールに切り替えることでファイルの作成するという現象にも遭遇しました。先程の実行の内部経路が異なるために起こったと考えられます。
| エージェントのツール | 内部経路 | UNCパス | 結果 |
|---|---|---|---|
execute_command |
CMD.EXE でシェル起動 | 非対応 | 失敗 |
write_to_file |
Node.js fs.writeFile 等 |
対応 | 成功 |
read_file |
Node.js fs.readFile 等 |
対応 | 成功 |
list_files |
Node.js fs.readdir 等 |
対応 | 成功 |
write_to_file が成功するのは、Node.jsのファイルシステムAPIがWindows APIを通じてUNCパスを処理でき、ディレクトリの自動作成(fs.mkdirSync with { recursive: true } 等)もAPIレベルで完結するためです。
つまりAGENTS.mdのコマンド実行ルールが影響するのは execute_command ツールのみであり、ファイル操作系のツールはAGENTS.mdの設定なしでも正常に動作します。
AGENTS.mdなしの場合に何ができて何ができないか
この問題はWSLとCMD.EXEの境界で発生するため、AGENTS.mdの設定なしでもできることとできないことが明確に分かれます。
できること(Windows ファイルI/O API経由 → 正常動作)
できないこと(CMD.EXE経由 → 失敗)
- プログラムの実行・デバッグ(
python main.py、node index.js等) - パッケージ管理(
npm install、pip install等) - テスト実行(
pytest、npm test等) - ビルド・コンパイル(
make、gcc等) - Gitなどの外部コマンド操作(
git commit等)
👉️つまり「コードを書く」ところまでは問題なく動きますが、「書いたコードを動かして確認する」ことができません。
AIコーディングエージェントの強みは「書く→動かす→エラーを見て直す」のサイクルを自律的に回すことにありますが、execute_command が壊れている状態ではこのサイクルが断絶し、エージェントの能力を大幅に活かせなくなります。
AGENTS.mdによるコマンド実行ルールの設定は、このサイクルを復旧させるために不可欠です。
VS Codeフォーク系IDEとWSLの構造的問題
この問題はBob IDE固有ではなく、VS Codeフォーク系IDE(Cursor等)でも同様に発生する可能性があるのかもしれません。
VS Code本家では、Remote-WSL拡張によりWSL内にVS Code Serverプロセスが起動し、ファイルアクセスやターミナル、拡張機能の実行がすべてWSL内で完結します。しかしフォーク版ではMicrosoft純正のRemote-WSL拡張が使えないため、このギャップが生じます。
コマンドの実行経路を図示すると以下のようになります。
【VS Code本家 + Remote-WSL】 エージェント → VS Code Server(WSL内) → bash → コマンド実行 ※ すべてWSL内で完結 【Bob IDE(WSLから起動しても)】 エージェント → Bob IDE(Windows) → CMD.EXE → コマンド実行 ※ Windows側で実行されるためUNCパス問題が発生
まとめ
今回の件、一見するとかなり特殊な問題に見えますが、整理すると以下のようになるかなと思います。
| 項目 | 内容 |
|---|---|
| 問題 | Bob IDEのAIエージェントがWSLプロジェクトでコマンドを実行すると、CMD.EXE経由になりUNCパスエラーで失敗する |
| 根本原因 | Bob IDEはWindows上のElectronアプリであり、エージェントのコマンド実行はCMD.EXEを使用する |
| 解決策 | AGENTS.md にコマンド実行ルールを記述し、エージェントに wsl -d <distro> bash -c "..." 形式を強制する |
| 効果 | コマンド実行の試行回数が6回→1回に改善 |
| 制限 | プロジェクトごとの設定が必要(テンプレートで軽減可能) |
Bob IDEはまだプレビュー段階のため、今後のアップデートでWSL対応が改善される可能性はあります。Remote-WSL相当の拡張機能の提供や、WSLプロジェクトを検出した場合に自動的にWSL bashを使う機能が実装されれば、この回避策は不要になるでしょう。
現時点では、AGENTS.md を使ったLLM指示レイヤーでの制御が解決策かなと思います。同じ問題で困っている方の参考になれば幸いです。
ネットでもあまり情報がなかったのですが、みなさんMac環境やLinux環境を使用しているですかね。あるいはWindowsネイティブな環境なのか?🤔 WSL環境を愛用している自分は異端なのか…🙄