OpenCode 分析：セキュリティ脆弱性とアーキテクチャ上の欠陥

OpenCode は、GitHub で 161k 以上のスターを持つ人気のオープンソース AI コーディングエージェントですが、重大なセキュリティ脆弱性とアーキテクチャ上の非効率性を抱えており、ローカルマシンでの使用は危険です。ツールのセキュリティアプローチは、堅牢なシステムレベルのサンドボックス化ではなく、bash コマンドの表面的なテキストフィルタリングに基づいているため、簡単にリモートコード実行（RCE）や不正なファイルシステムアクセスが可能な姿勢になっています。

重大なセキュリティ脆弱性

OpenCode のセキュリティモデルは根本的に欠陥があり、実際の実行ファイルやシステム権限を制限するのではなく、コマンドライン文字列に対する正規表現ベースのフィルタリングに依存しています。

無効な Bash コマンドフィルタリング

OpenCode は、tree-sitter を使用して bash コマンドを AST にパースし、ノードを正規表現と照合することで特定のコマンド（例：git）の実行を防ごうとします。このアプローチは、標準的なシェルテクニックを用いることで簡単に回避できます。

• エイリアスや環境変数による回避: env git status や GIT=git && $GIT status のようなコマンドはフィルタをすり抜けます。
• エンコード回避: base64 エンコードされた文字列を bash にパイプすると（例：echo Z2l0... | base64 -d | bash）禁止コマンドが実行できます。
• 間接実行: python3 -c で subprocess.run を呼び出して git 操作を行うと、フィルタを完全に回避できます。
• パス回避: コマンド名の代わりに絶対パス /usr/bin/git を呼び出すと検出されません。

壊れたファイル権限

OpenCode は、ファイルにアクセスすると想定されるコマンド（rm、cp、mv、cat など）を列挙した "ホワイトリスト"（FILES リスト）を実装しています。このリストに含まれないコマンドは、ファイルシステムへの副作用がないとみなされます。そのため、python3 が FILES リストに無い状態で、python3 -c 'import shutil; shutil.rmtree("/")' を実行しても権限プロンプトが出ません。

さらに、シェルリダイレクション（例：echo foo > bar.txt）は AST ではコマンドの兄弟ノードとして扱われるため、パス検証ロジックがリダイレクト先に適用されず、無許可のファイル書き込みが可能になります。

リモートコード実行（RCE）リスク

このツールは過去に深刻な RCE 脆弱性を抱えていました。CVE-2026-22812 では、デフォルトで許容的な CORS ヘッダーと任意のシェルコマンド・ファイル読み取り API を持つ HTTP サーバが公開されました。現在はサーバはデフォルトで無効化されていますが、開発者は自ドメイン向けに CORS 例外を残すことを推奨しており、ユーザーのマシン上でリモート実行が可能になる恐れがあります。

パフォーマンスとアーキテクチャ上の欠陥

セキュリティ以外にも、OpenCode のコンテキスト管理実装は特にローカル LLM ユーザーに対して深刻なパフォーマンス低下を招きます。

プロンプトキャッシュミス

ローカル LLM サーバは「prefill」計算コストを回避するためにプロンプトキャッシュに依存していますが、OpenCode は非効率なプロンプト構築によりこれらのキャッシュを頻繁に無効化します。

• 動的システムプロンプト: turn‑0 のシステムプロンプトに現在の日付を含めると、日付が変わるたび（例：真夜中）にキャッシュが完全に失われます。
• 頻繁な再読込: ツールは SSE の各ターンで AGENTS.md を再読込し、ファイルが変更されると再評価が走ります。
• 過剰なプルーニング: 40k トークンを超えるツール呼び出し結果を削除すると、エージェントからユーザーへの遷移時に重要な初期コンテキスト（仕様など）が失われ、モデルが必須情報なしで動作せざるを得なくなります。

リソース非効率性

TUI（テキストユーザーインターフェース）は極端なリソース浪費で知られ、テキスト描画だけで最大 1 GB の RAM を消費すると報告されています。また、メッセージボックスの改行処理が壊れている、長文メッセージの描画が二次的に O(n²) のパフォーマンスになるといった基本的な UX の失敗もあります。

エージェントの相互作用とツール化

OpenCode のエージェント機能はしばしば不安定で直感に反します。

• サブエージェント管理: ユーザーはサブエージェントと直接通信できません。サブエージェントが "ラビットホール" に陥った場合、唯一の手段はプロセスを強制終了し、蓄積されたコンテキストをすべて失うことです。
• 権限疲労: プロジェクトディレクトリ外へのファイルアクセスごとにシステムが許可を求めますが、選択肢は "Yes"、"No"、"Always" のみで "Never" がありません。そのためユーザーは "Always" をクリックしがちで、コマンドプレフィックス（例：echo）に対して永続的な権限が付与され、恒久的なセキュリティホールが生まれます。

コミュニティの見解と反論

技術的批判は厳しいものの、Hacker News のコミュニティフィードバックはセキュリティ志向の開発者と生産性志向のユーザーの間で分かれています。

• 生産性 vs. セキュリティ: 一部のユーザーは OpenCode が最も生産的なハーネスだと主張し、コマンドフィルタリングはモデルを "誘導" するためのもので、ハードなセキュリティ境界を提供するものではないと述べています。
• 問題の一般化: 複数のコメント投稿者は、プロンプトキャッシュミスや基本的なエージェント失敗は多くの AI ハーネス（Codex や Claude CLI など）で共通していると指摘し、これらは OpenCode 固有のバグというよりも現在の AI ツール全体の体系的な課題であると示唆しています。
• 開発者の回答: OpenCode チームの代表は、ツール呼び出しプルーニングを含む最も顕著な問題の多くは次期 v2 リリースで対処されると述べ、新しいシステムプロンプトアプローチでキャッシュバスティングを回避する計画だと語っています。

"私は自分の仕事で (特定のバージョンの) OpenCode を使っています。とても優れているからです。この投稿を読むと悲しくなります。なぜなら、ここで指摘されたことがすべて私が見てきた奇妙な挙動と一致し、納得できたからです。"

代替案と緩和策

著者は、コーディングエージェントの主要なセキュリティ層として Docker を使用することに反対し、ルートサービスリスクやファイアウォールの穴を指摘しています。その代わりに、Landlock、Seatbelt、Restricted Tokens といった OS ネイティブの構成要素を推奨しています。他のコミュニティメンバーは、エージェント環境のディレクトリ権限を制限するために Flatpak/Bubblewrap/Flatseal の使用を提案しています。