PicoClawでSlack連携時に codex cli error: No such file or directory が出たときのメモ

Posted: 2026-03-15

PicoClawでSlack連携時に `codex cli error: No such file or directory` が出たときのメモ

Slack 上で PicoClaw を起動し、チャンネルへアプリを追加したあとにメンションを送ると、スレッドで次のようなエラーが返るケースがあった。

Error processing message: LLM call failed after retries: codex cli error: Error: No such file or directory (os error 2)

今回は Slack 側の設定ミスに見えたが、実際には codex-cli の workspace 指定が原因だった。

症状

起きていた現象は次のとおり。

Slack App 自体は正常に接続できる
#random などのチャンネルにアプリ追加は成功する
@picoclaw でメンションするとエラー応答になる
PicoClaw のログには codex cli error: Error: No such file or directory (os error 2) が出る

この時点で、Slack API の認証や Socket Mode 接続は通っているが、LLM 呼び出しの直前または実行時に失敗していると分かる。

最初に確認したこと

まずは Slack 接続自体が生きているかを確認した。

picoclaw gateway --debug で起動して、ログに次が出ていれば Slack 連携そのものは通っている。

Starting Slack channel (Socket Mode)
Slack bot connected
Slack channel started (Socket Mode)

今回もここは成功していたので、Slack App 側のトークンや Socket Mode 設定は主因ではなかった。

Slack 固有の問題かどうかを切り分ける

次に、Slack を経由しないで同じ失敗が出るかを確認した。

picoclaw agent -m "こんにちは"

ここでも同じ codex cli error: Error: No such file or directory (os error 2) が出たため、Slack 連携固有の問題ではなく、PicoClaw から codex を呼ぶ経路全体の問題と切り分けられた。

さらに確認したこと

codex コマンド自体が壊れていないかも別で確認した。

command -v codex
codex --version
printf 'hello\n' | codex exec --json --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check --color never -m gpt-5.3-codex -C /path/to/workspace -

この直接実行は成功したので、codex 自体が存在しないわけではなかった。

つまり、問題は次のどちらかに絞られた。

PicoClaw が codex に渡す workspace
PicoClaw が codex に渡す実行条件

原因

原因は ~/.picoclaw/config.json の model_list[].workspace に ~/.picoclaw/workspace と書いていたことだった。

設定としては自然に見えるが、この時点の PicoClaw 実装では model_list[].workspace の ~ が展開されず、そのまま codex に渡されていた。

結果として、内部的には次のような失敗が起きていたと考えられる。

想定: 実在するホーム配下の workspace へ移動する
実際: ~/.picoclaw/workspace という文字列をそのまま path として使おうとして失敗する

Slack から見ると LLM 呼び出し失敗にしか見えないが、根本は path 解決だった。

今回の復旧方法

今回は復旧を優先し、設定ファイルの workspace を絶対パスへ戻した。

{
  "model_list": [
    {
      "model_name": "codex-cli",
      "model": "codex-cli/gpt-5.3-codex",
      "workspace": "/absolute/path/to/.picoclaw/workspace"
    }
  ]
}

これで picoclaw agent -m "こんにちは" が正常応答に戻り、その後 Slack 上のメンションでも期待どおり返答するようになった。

確認手順

復旧後は次の順で確認した。

picoclaw agent -m "こんにちは" で CLI 経由の応答を確認する
picoclaw gateway --debug を起動する
Slack の DM またはメンションで短い文を送る
ログに LLM 応答が出るか確認する
Slack 側で通常応答が返るか確認する

この順で見れば、Slack 側の問題か、PicoClaw 本体の問題かを切り分けやすい。

恒久対策

設定だけで回避するなら、当面は model_list[].workspace に絶対パスを書くのが安全だと思う。

似た症状が出たときの見方

もし Slack 連携中に No such file or directory が出たら、まずは次を疑うとよい。

codex コマンド自体が PATH 上にあるか
model_list[].workspace が実在するか
model_list[].workspace に ~ を書いていないか
Slack ではなく picoclaw agent -m でも再現するか

Slack の画面で出るエラー文だけでは原因にたどり着きにくいので、PicoClaw の gateway ログと CLI 実行の両方を見るのが重要だった。

まとめ

今回のポイントは次の 3 つだった。

Slack 接続成功と LLM 呼び出し成功は別問題
Slack 経由だけでなく picoclaw agent -m でも再現確認すると切り分けが早い
codex-cli の workspace には、少なくとも現時点では絶対パスを使う方が安全

一見 Slack のトラブルに見えても、実際には PicoClaw と codex-cli の path 解決が原因だった、という記録として残しておく。