AIコーディングエージェント(Claude Code, OpenCode, Codex CLI等)を使っていると、しばしばAIエージェントからの権限確認が求められます。「このファイルを操作して良いですか?」という事をユーザーに確認する機能です。これは安全上とても重要な機能で、エージェントが想定していないファイル操作をすることを未然に防止します。一方でユーザーの権限確認待ちで作業が進まないこともあります。例えばエージェントに指示を与えて別の作業をしていたら、全然進んでいなかった、というような事ですね。

そこで、AIエージェントの外側の仕組みで、エージェントが操作できるファイルを厳密にコントロールした上で、許可確認を減らしていくことが解決策になります。

本稿ではLinux環境のFirejailを使うことで、OpenCodeのアクセス範囲を制限する方法を説明します。FirejailはLinux namespaceを利用した隔離機能(Sandbox)を提供するソフトウェアで、コンテナ等と比較して軽量であることが特徴です。以下のサンプルはOpenCode用ですが、Claude Code (CLI)や、Codex CLIでもほぼそのまま適用できると思います。

なお、本稿は私の環境に合わせた設定ですので、他環境ではそのままでは適用できない(設定が不足する、もしくは緩すぎる)部分があるはずです。この文章はあくまで参考とし、ご自身の責任の範囲で環境にあわせて利用方法を検討してください

AIエージェントのファイルアクセス、ネットアクセスを制限する手法

あるプロセスのファイルアクセスやネットワークアクセスを制限する方法は色々考えられます。

どのOSでも利用できる方法としては、権限をしぼった”AI用ユーザー”を作り、そのユーザーでエージェントを起動する方法です。ただ、この方法では各ディレクトリの権限を細かく調整していく必要があるのが大変ですし、通常ユーザーが作ってきた環境をAI用ユーザーに適切に渡すことにも工夫が必要です(例えばホームディレクトリに入れたツールはAI用ユーザーは参照できない)。

コンテナを使う方法もあります。より強い環境分離が可能であり、複数のエージェントを同時起動するような用途等、コンテナが適している場合も多いのですが、アクセス可能なファイルのマウントや環境変数の引き渡し、またコンテナ起動のオーバーヘッド等、準備すべき内容がずっと多くなります。

Firejailは上記とは違い、一般ユーザーIDのまま、アクセス可能なファイルやネットワークを制限します。環境変数や$HOME等もそのままなので、いつも使っているツールをエージェントに簡単に与えることができ、今回のような用途では便利です。Firejail以外だとbubblewrapも同様のことが実現できます。

他OSにおいては、例えばmac OS環境ではApple Seatbeltが近しいものではないかと思います。Windows環境では類似のものが見つけられていないのですが、AI用ユーザーを作るか、もしくはWSL2を一種の隔離環境として使う等が考えられます。

Firejailの導入

Firejailの導入は簡単です。詳細はgithubページにありますが、Ubuntu/DebianであればReleaseビルドにdebファイルが含まれるので、それを導入するだけです。今回はv0.9.80を利用しました。なおaptでも導入できますが、バージョンが古いため、GithubからReleaseバイナリを取得して導入することが推奨されています。

> wget "https://github.com/netblue30/firejail/releases/download/0.9.80/firejail_0.9.80_1_amd64.deb"
> sudo dpkg -i firejail_0.9.80_1_amd64.deb
> firejail --version
firejail version 0.9.80
Compile time support:
- always force nonewprivs support is disabled
- AppArmor support is enabled
- AppImage support is enabled
- chroot support is enabled
- D-BUS proxy support is enabled
- file transfer support is enabled
- Landlock support is enabled
- networking support is enabled
- output logging is enabled
- private-home support is enabled
- private-lib support is disabled
- sandbox check is enabled
- SELinux support is disabled
- user namespace support is enabled
- X11 sandboxing support is enabled

OpenCode用プロファイルの準備

Firejailは、デフォルトだとほぼ何も禁止されていない状態であり、用途別に設定ファイル(プロファイル)を作成します。プロファイルはデフォルトでは ~/.config/firejail/以下が参照されます。

以下が私の環境での~/.config/firejail/opencode.profile です。これは環境によって異なるので、あくまで以下は私の環境用であり、環境にあわせて修正する必要がある点に注意してください。

設定しているのは、以下のような内容です。

  1. private-temp : 隔離された /tmp の用意
  2. private-dev : null、zero、random、urandom、tty、stdin/stdout/stderrといった最小限の/dev/*へのアクセスを許可
  3. nosound, nodvd等 : 不要な機能を禁止
  4. root関連操作の禁止(sudoも)
  5. Networkは許可
  6. ~/projects/以下は読み書きを許可
  7. ホームディレクトリの中で、opencodeが動作するために必要なファイルやディレクトリのみ許可
  8. その他ツール(git, uv, cargo等)が動作するために必要なファイルやディレクトリを許可

という内容になっています。特に6, 7, 8は環境によって大きく異なる部分かと思います。例えば私の場合は ~/.ssh への許可を与えていません。これはエージェントにSSHを使う処理をさせないためです。一方で、~/.aws は一部読み書きを許可しています。このため別途aws cli側の設定で適切な権限(IAMロール)を使うようにする設定が必要です。

# opencode Firejail Profile
# ============================================
# Basic Sandbox
# ============================================
private-tmp
private-dev
# ============================================
# Disable Unnecessary Hardware/Features
# ============================================
nodvd
notv
nosound
nou2f
novideo
no3d
nogroups
nodbus
# ============================================
# Security Hardening
# ============================================
seccomp
nonewprivs
caps.drop all
noroot
# ============================================
# Network
# ============================================
# ALLOWED - required for LLM API calls and git operations.
# To restrict with a custom netfilter, uncomment:
# netfilter /etc/firejail/opencode.net
# ============================================
# Home Directory Whitelist
# ============================================
# --- opencode core ---
whitelist ~/.opencode
whitelist ~/.config/opencode
whitelist ~/dotfiles
whitelist ~/.local/share/opencode
whitelist ~/.local/share/OpenCode
whitelist ~/.local/share/ai.opencode.desktop
whitelist ~/.local/share/opentui
whitelist ~/.local/state/opencode
whitelist ~/.cache/OpenCode
whitelist ~/.cache/ai.opencode.desktop
whitelist ~/.cache/opencode
# --- project directories ---
whitelist ~/project
# --- git ---
whitelist ~/.gitconfig
whitelist ~/.config/gh
whitelist ~/.config/git
whitelist ~/.cache/git
# --- Rust / Cargo ---
whitelist ~/.cargo
whitelist ~/.rustup
# --- Go ---
whitelist ~/go
whitelist ~/.cache/go-build
whitelist ~/.cache/goimports
whitelist ~/.cache/gopls
# --- Node.js / Bun ---
whitelist ~/.nvm
whitelist ~/.bun
whitelist ~/.npm
whitelist ~/.cache/node-gyp
whitelist ~/.cache/typescript
# --- Python / uv ---
whitelist ~/.local/bin
whitelist ~/.cache/uv
whitelist ~/.local/share/uv
whitelist ~/.config/uv
whitelist ~/.ruff_cache
# --- AWS CLI ---
whitelist ~/.aws
read-only ~/.aws/config
# --- Other dev tools ---
whitelist ~/.local/share/zoxide
whitelist ~/.cache/tree-sitter

OpenCode用プロファイルでテスト起動

上記プロファイルを適用した状態でプロセスを実行するには、以下のように実行します。

> firejail --profile=opencode <コマンド>

例えば firejail --profile=opencode bash と実行するとbashが起動します。この時、firejailから起動することによるオーバーヘッドはほとんど感じないと思います(私の格安Linux VPS環境でも30-40ms程度しかかからない)。

制限された状態でbashが起動できるので、どこまでアクセスできるのか確認すると良いでしょう。例えば ls ~/.ssh 等とすると、あるはずのディレクトリが見えなくなっているのが確認できます。

問題なさそうであればいったんbashを終了してから、firejailでopencodeを起動します。プロファイル名と実行コマンドが同じ場合は、--profileを省略できます。

> firejail opencode

上記をalias登録しておくのも良いでしょう。あとはOpenCodeの設定ファイルで、権限を与える範囲を調整して使ってください。

[参考] OpenCodeをYOLOモード(権限確認不要)で利用する

これは、すべての環境にお勧めできる方法ではないのですが、私の個人プロジェクトでは、VPSサーバー(GreenCloudで借りている格安サーバー)の中で、Firejailを有効にしつつ、OpenCodeには許可確認を一切不要にする設定(いわゆるYOLOモード)を試しています。

OpenCodeでは環境変数OPENCODE_CONFIG_CONTENTを使うと、設定ファイルの一部を上書きできるので(この変数の内容が最後に参照される)、以下のように.bashrc等で指定しておき、プロジェクトディレクトリでopencode-yoloで起動することで、firejailから起動する時のみpermission : {"*": "allow"}を与え、YOLOモード的な実行をしています。

alias opencode-yolo='firejail --profile=opencode env OPENCODE_CONFIG_CONTENT='\''{"permission":{"*":"allow"}}'\'' opencode'

コメントを残す