Yolobox – ホームディレクトリを保護しながらAIコーディングエージェントをフル権限で実行する

 (github.com/finbarr)
12 ポイント 投稿者 GN⁺ 2026-01-14 | 1件のコメント | WhatsAppで共有
  • AIコーディングエージェントを完全なシステム権限で実行しつつ、ユーザーのホームディレクトリ破損リスクを遮断するツール
  • Claude Code、Codex、Gemini CLI、OpenCode など主要なAI CLIが事前設定され、**「YOLOモード」**で実行可能
  • DockerまたはPodmanコンテナ内でプロジェクトディレクトリだけをマウントし、ホームディレクトリはデフォルトで除外
  • コンテナ内ではsudo権限と永続ボリュームを提供し、ツールと設定をセッション間で維持
  • 開発者がAI自動化機能を安全に試せる隔離されたサンドボックス環境を提供

概要

  • YoloboxはAIコーディングエージェントをコンテナ内で実行し、システムを保護しながら完全な実行権限を与えるツール
    • AIがコマンド実行中に誤って rm -rf ~ のような破壊的コマンドを実行しても、ホームディレクトリには影響しない
    • プロジェクトディレクトリは /workspace にマウントされ、ホームディレクトリはデフォルトではマウントされない
    • 永続ボリュームによりツールと設定がセッション間で保持される

主な構成と機能

  • コンテナ内でAIエージェントはsudo権限を持ち、自由にコマンドを実行できる
  • デフォルトイメージには次が含まれる
    • AI CLI: Claude Code、Gemini CLI、OpenAI Codex、OpenCode（すべて自動実行モードに設定）
    • 開発環境: Node.js 22、Python 3、make、cmake、gcc、Git、GitHub CLI
    • ユーティリティ: ripgrep、fd、fzf、jq、vim
  • 必要に応じてユーザーが直接 sudo で追加パッケージをインストール可能

実行とコマンド

  • yolobox コマンドでサンドボックスシェルに入る
  • yolobox run で単一コマンドを実行可能
  • yolobox upgrade、yolobox config、yolobox reset --force、yolobox version などの管理コマンドを提供
  • 主なフラグ
    • --runtime: docker または podman を選択
    • --no-network: ネットワークを無効化
    • --readonly-project: プロジェクトを読み取り専用でマウント
    • --claude-config: ホストのClaude設定をコンテナにコピー

セキュリティモデル

  • コンテナ分離をセキュリティ境界として使用
    • コンテナはLinux名前空間を通じてファイルシステム、プロセス、ネットワークを分離
    • AIはコンテナ内ではroot権限を持つが、外部システムにはアクセスできない
  • 保護対象
    • ホームディレクトリ、SSHキー、認証情報、dotfiles、他のプロジェクト、ホストシステムファイル
  • 保護しない項目
    • プロジェクトディレクトリ（デフォルトで読み書き可能）
    • ネットワークアクセス（オプションで遮断可能）
    • カーネル脆弱性やコンテナエスケープ攻撃

セキュリティ強化の段階

  • 基本モード: 標準的なコンテナ分離
  • 第2段階: --no-network --readonly-project オプションで攻撃面を縮小
  • 第3段階: Rootless Podman を使ってホストのroot権限を排除
    • コンテナのrootがホストの一般ユーザーにマッピングされ、脱出時の被害を最小化
  • 第4段階: VM内で実行してカーネル共有を排除
    • macOSではUTM、Parallels、Lima、LinuxではPodman machineまたは専用VMを使用

ネットワーク分離

  • Rootless Podmanはデフォルトでslirp4netnsネットワークを使用し、ホストネットワークから分離
  • allow_host_loopback=false 設定でローカルネットワークへのアクセスを遮断可能

ライセンスとその他

  • MITライセンスで公開
  • リポジトリの言語構成: Go 75.9%、Dockerfile 13.6%、Shell 8.7%、Makefile 1.8%
  • 「Yolobox」という名前は「YOLO（You Only Live Once）」の精神に由来し、AIを自由に実行しつつ安全に隔離された環境を意味する

関連記事

1件のコメント

 
GN⁺ 2026-01-14
Hacker Newsのコメント

  • 最近、Litterboxという似たプロジェクトを作った（デモサイト）
    Linux専用だが、Podman に依存しているため。代わりに、自分の用途に合った利点がある

    • Waylandソケット を公開して、エディタのような開発環境全体をコンテナ内で実行できる。これにより、エディタ拡張の脆弱性から保護される
    • 署名のたびにユーザーへ確認を求める 特殊なSSHエージェント を提供している。そのため、悪意あるコードがGitHubへのアクセス権をこっそり使うことがない
    • 特定の状況でのみ必要な権限（TUN/TAPデバイスの作成など）を簡単に有効化できる機能もある
    • 現在はないが、SELinux統合 を準備中

  • 自分も似たようなものを実験していた。
    READMEに動作原理と 信頼境界（Dockerコンテナベース）を明確に説明するとよいと思う。カーネル脆弱性が悪用されうるので、コンテナ脱出のリスクは依然として存在する
    Rootless Podman と slirp4netns を使ってネットワークアクセスを最小化している。
    次の段階として Podman machine を使ってカーネルを完全に分離しようとしているが、ボリュームマウントがうまく動かない

  • agents.md や claude.md に アシモフの三原則 を入れるべきだと提案する

    1. プログラムを壊したり放置したりしないこと
    2. 第一原則に反しない限り命令に従うこと
    3. 第一・第二原則に反しない限りセキュリティを守ること
    • 原作では、これらの法則はすぐに破綻し、人間社会の複雑さを示そうという意図があった
    • “I, Robot”を見ていないようだ。こうしたルールを claude.md に入れると、モデルがその概念を 「頭に刷り込まれる」 効果がある。昔のモデルは「象という単語を使うな」と言うと、むしろその単語を避けようとして妙な結果を出していた
    • 各原則の 曖昧な解釈 のせいで抜け道が多い。たとえば「性能低下」も破壊に当たるのか？ 「セキュリティ問題」の基準は？ 結局「テストは通ったから大丈夫」のように逃げられてしまう
    • タイポの指摘: Tenet

  • Shaiを確認してみるとよいと勧める。ローカルで動作し、ディレクトリアクセス権とネットワークトラフィックを制御できる

    • Shaiの作者です。エージェントのアクセス制御 はますます重要になっている。エージェントはユーザーを満足させようとして境界を簡単に越えてしまう。たとえばローカル環境の 認証情報 を不適切に扱う可能性がある
      shai -rw . で現在のディレクトリの読み書きを許可し、shai -u root で別ユーザーとして実行できる
      Shaiは デフォルト拒否、明示的許可（opt-in） の哲学に従う。.shai/config.yaml をリポジトリで共有し、チーム全体で同じ設定を使うことを勧めている
    • 自分も似たツール ctenv を作った。特定のエージェント向けではないが、設定の柔軟性が高い。任意イメージの使用 と カスタムentrypointスクリプト のサポートは、devcontainerより便利だ
    • 素晴らしいプロジェクトだが、自分のアプローチとは異なる。Yoloboxは基本的に sudo権限と全面的なネットワークアクセス を許可する。必要なら --no-network で遮断できる

  • yolo-cageを開発中。Yoloboxがローカルマシン保護に焦点を当てるのに対し、yolo-cageは 秘密情報の流出防止と複数エージェントの協調 に焦点を当てている
    Kubernetesで実行され、すべてのegressトラフィックをスキャン してAPIキーやトークンの漏えいを防ぐ。
    Gitブランチの分離を強制して、エージェントが自分のPRをマージできないようにする — 「エージェントは提案し、人間が承認する」
    さらに 脱出テストフレームワーク を内蔵し、Claudeが自ら脱出を試みるよう誘導する。そのプロンプトはリポジトリ内にあり、エージェントが本物かどうかを検証する

    • 脱出テストには Gemini を勧める。Claudeは表面的な試みにとどまったが、Geminiははるかに創造的だった。これを防ぐべきかどうかすら悩んでいる

  • コミットに「claude」表記を付ける必要がなぜあるのか不思議だった。OSやvimのバージョンのようには書かないのに。LLMは結局 英語をコードにコンパイルするツール にすぎない

    • OSやコンパイラはユーザーが指示したとおり正確に実行するが、LLMは見た目は正しいコードのようでも微妙に誤った結果 を出すことがある。しかも悪意を持つ可能性すらある。だからLLMが書いたコミットであることを明示し、レビューを強化 する必要がある
    • 自分は Claude Code に直接コミットを任せている。エージェントがコマンドを実行してコードを修正し、自分がレビューとテストを行う
    • 各反復ごとに自動コミットする hook を使って、「Claudeが今しがた何をしたか」を簡単にレビューしている

  • 自分も似た試みをした。もう少し 利便機能 を追加した Toadbox を作った

  • AI向けサンドボックスの話は多いが、実は Claude Code、Codex、Gemini CLI にはすでに 内蔵サンドボックス がある

    • macOSではseatbelt、Linuxではbubblewrap（Claude）、seccomp+landlock（Codex）、WindowsではAppContainerを実験中
    • 興味深いが、このサンドボックスが 特定ファイルへのアクセスだけを制限するのか、そして システムコマンド実行時にも適用されるのか は不明だ。単にエージェントプロセスだけを隔離しているのなら、実効性は低いかもしれない

  • 自分は Apple Container Framework を使って似たものを実装中。確認したことがあるか気になる

    • Apple ContainerはDockerやColimaの代替に近く、Kata Containersのように各コンテナが個別のVM として動作する。macOSでコンテナ改善を試みている点は歓迎したい
      ただし Docker API互換性 と 構成可能性 が不足している。関連する議論を ここ にまとめた
      もともとShaiをApple Container上に載せようとしたが、パッケージングの問題 で断念した
    • まだ使ってはいないが興味深い。Yoloboxには主要な コーディングエージェントCLIがプリインストールされたイメージ がある。「究極のvibeコーディング用イメージ」を作りたい。イメージに何か特別な設定をしているのか気になる

  • 自分も似たものを作っている → sandbox-codex
    まだ進行中で、tmuxログの可読性 が低い。Dockerは完全なサンドボックスではないので、VirtualBoxで動かしている

    • 自分もNode.js専用に simple-npm-sandbox を作ってみた。シンプルだが 良い学習経験 だった