OpenClaw 5.28: アップグレード後にCodexプラグインが破損 – シンボリックリンクシムで修正

OpenClawを5.12から5.28にアップグレードすると、Codexプラグインが静かに動作しなくなることがあります。アップグレード後、すべてのエージェント呼び出しがWaiting for agent replyでハングし、cronジョブは正確に121秒でmodel-call-startedでタイムアウトし、フォールバックチェーンは十分に迅速に作動しません。ゲートウェイは正常に起動し、OAuthは有効で、Codexはインストール済みで有効と表示されますが、すべてのバイナリ生成試行は静かにENOENTで失敗します。
根本原因: パスの不一致
5.28のCodexプラグインハーネスは、次の場所にバイナリがあることを期待しています:
vendor/x86_64-unknown-linux-musl/codex/codexしかし、パッケージはバイナリを次の場所に配置します:
vendor/x86_64-unknown-linux-musl/bin/codexプラグインはバイナリを見つけられず、すべての生成試行がハングします。
修正: シンボリックリンクの作成
Codex拡張ディレクトリを設定し、バイナリへのシンボリックリンクを作成します:
CODEX_DIR="/home/clawbot/.openclaw/extensions/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl"
sudo mkdir -p "$CODEX_DIR/codex"
sudo ln -sf "$CODEX_DIR/bin/codex" "$CODEX_DIR/codex/codex"
sudo chown -h clawbot:clawbot "$CODEX_DIR/codex/codex"
sudo systemctl restart openclaw再起動後、エージェント呼び出しは正常に再開されるはずです。
重要な注意点
- Codexプラグインの再インストールや強制アップデートを行うと、拡張ディレクトリが消去されるため、再インストール後はシンボリックリンクを再度作成する必要があります。
- systemdサービスでCodexバイナリに対して
ExecStartPostのchmodを使用している場合、そのパスもbin/codexに更新してください。
この問題はUbuntu 24.04、npmインストール、systemdサービスで再現されました。これで数時間のデバッグが不要になれば幸いです。
📖 完全なソースを読む: r/openclaw
👀 See Also

OpenClawとOllamaを使った完全ローカル型マルチエージェントアシスタントの構築
開発者が、OpenClawとOllamaを使った完全ローカルのパーソナルAIアシスタントのスタックを公開。モデルはqwen3.5:35b-a3b、gemma3:4b、mistral:7b、MCPサーバーはHome AssistantとGmail、Telegram Botインターフェースを採用。

すべてのOpenClawプロファイルが公開される前の5つの整合性チェック
完璧なスプーフィングを追い求めるのはやめよう。内部シグナルの一貫性の方が重要だ。r/openclawからのTLS、ロケール、WebGL、Canvas、動作チェック。

Opus 4.7 でプロンプトの40%が破損、修正方法は CLAUDE.md とスキルの構造化
Opus 4.7が6つの環境でプロンプトの約40%を劣化させた後、AIのフラクショナルヘッドがアドホックなプロンプトを構造化されたSkillファイル、階層的なCLAUDE.md、個別のメモリファイルに置き換えることで修正し、トークン使用量を22%削減し、反復ターンを3-4から1-2に減らしました。

Oracle CloudでローカルLLMを使用した無料のOpenClawゲートウェイ
開発者が、Oracle Cloudの無料枠を利用して、VM.Standard.A2.Flexインスタンス(4 OCPU、24GB RAM、200GB SSD)上でQwen3.5 27B A3B 4-bit LLMをローカルで実行し、QCAIアプリでリモート管理する方法を共有しました。