トラブルシューティング

この章は症状ごとに構成されています。各項目には、考えられる原因と解決手順を記載しています。まず最初の確認先: タイムライン、ログ、ヘルスチェックから始めてください — 以下のほぼすべての診断は、これらの情報源のいずれかに依存しています — その後、目の前の症状に合うセクションに進んでください。

以下の内容の大半には、2 つの事実が関わっています。1 つ目に、マシン（設定エディタではワークスペース）は永続的なサンドボックスです。システムディスク（disk.img）と Linux のホーム（home.img）は起動をまたいで残るため、そのどちらかの問題は、単に起動し直すだけでは解決しません。2 つ目に、Bromure Agentic Coding はトラフィックが VM に届く前に、ホストでセキュリティポリシーを適用します。そのため、ゲストの「中」で起きているように見えるブロックやエラーは、たいていホストのプロキシによるもので、VM ではなくアプリで解決します。

最初の確認先: タイムライン、ログ、ヘルスチェック

何かを変更する前に、アプリ自身が何を報告しているかを確認してください。

セキュリティタイムライン

ウインドウ › セキュリティ… を開きます（または ⌘K で検索します）。Bromure のセキュリティエンジンがエージェントのために下したすべての判断を記録します — 認証情報の仲介と使用、ファイアウォールと OpenShell の判定、ゲストサンドボックスの拒否、ガードレール、サプライチェーンのチェック、プロンプトインジェクションのスキャン、個人データの置き換え、エージェント間の委任メッセージ、上流の TLS の問題です。記録は常にオンで、再起動をまたいで残り、各日のイベントは 90 日間保持されます。

• 概要 タブは最近の一定期間（既定では過去 24 時間）— ブロック、許可、資格情報ブローカー、サプライチェーン、個人データ保護 — を要約し、各マシンの保護を表示して、最近のブロック を一覧表示します。「なぜエージェントのリクエストが失敗したのか」への最速の答えは、たいていブロックです。クリックすると、それが起きたすべての回を見つけられます。
• タイムライン タブはすべてのイベントを一覧表示します。イベントをフィルタ… フィールド（パッケージ名、ホスト、マシン）、ワークスペース・期間・エンジンのフィルタ、そしてリモートホストをミラーしている場合はマシンフィルタ（すべてのマシン / この Mac / ホスト）で絞り込めます。
• カーネル・セントリーのあるマシンでは、ネットワーク の行をダブルクリックすると、どのプロンプト、ツール呼び出し、プロセスがその接続を行ったかが分かります（ネットワーク・リネージ）。
• 書き出す… は、適用中のフィルタを反映したイベントを CSV ファイルとして保存します。バグ報告に添付したり、セキュリティチームに渡したりできます。
• クリア はウインドウ内のイベントを非表示にするだけで、ディスク上の日ごとのファイルは保持されます。

このウインドウの詳細はセキュリティ概要とタイムラインで説明しています。

アプリのログ

アプリは、ターミナルから起動したかどうかに関係なく、標準エラー出力に書き込んだすべての内容のコピーを ~/Library/Logs/BromureAC/bromure-ac.log に保存します。各実行はビルドと macOS のバージョンを示す === … launch pid … 行で始まり、exit 行で終わります。クラッシュすると、致命的なシグナル名を示す行が残ります。ファイルが 8 MB を超えると次回起動時にローテーションされ、1 つ前のファイルが bromure-ac.log.1 として保持されます。

次のような場合にここを確認します。

• マシンの保存された状態を復元できなかった（その行に、サスペンド以降に何が変わったかが記録されます — サスペンドしたマシンが中断したところから再開しないを参照）。
• 無人の起動が拒否された、またはファイルシステムの修復が実行された。
• アプリが予期せず終了した。macOS がクラッシュレポートを表示しない場合、ログの最後の数行が何が起きたかを知る最良の記録です。組み込みのターミナルエンジンも、クラッシュの詳細を ~/Library/Caches/com.mitchellh.ghostty/sentry に保存している場合があります。

ログをリアルタイムで見たり、デバッグ出力を追加したりするには、ターミナルからアプリを起動します。

"/Applications/Bromure Agentic Coding.app/Contents/MacOS/bromure-ac"

より詳細な情報が必要な場合は、コマンドの前にデバッグ変数を設定します（付録を参照）:

• BROMURE_AC_DEBUG=1 — 自動化エンジン、インジェクション分類器、トレースパイプラインのタイムスタンプ付きデバッグ。
• BROMURE_CLI_DEBUG=1 — CLI コマンドの制御ソケット接続診断。
• BROMURE_REPAIR_DEBUG=1 — ローカル推論の修復プロキシ診断。/tmp/bromure-repair.log に追記されます。

ヘルスチェック

アプリは実行中、~/Library/Application Support/BromureAC/control.sock で所有者専用のコントロールソケットを提供します。そのヘルスを問い合わせて、アプリが動いていて応答していることを確認します。

curl --unix-socket "$HOME/Library/Application Support/BromureAC/control.sock" http://localhost/health

{ "status": "ok", "service": "bromure-ac-automation", "debugEnabled": false }

ループバックのオートメーションサーバー（環境設定 › オートメーション、デフォルトはオフ）をオンにしている場合は、同じエンドポイントが設定したポート — デフォルトは 9223 — で TCP でも応答します。

curl http://127.0.0.1:9223/health

接続が拒否された場合は、アプリ（またはそのヘッドレスエージェント）が動いていません。bromure-cli vm ls は必要に応じてバックグラウンドエージェントを起動するので、これも手早い生存確認になります。bromure-cli のインストール方法は CLI、API、MCP を参照してください。

インストールコンソール

ベースイメージのインストール中 — オンボーディングウィザードの インストール ステップ、または ベースイメージを再構築… の後 — 進行状況ビューには、インストーラの生のログをストリーミングする、折りたたまれた コンソール出力 セクションと コピー ボタンがあります。画面に残るのは最後の 100 行だけなので、報告に添付する必要がある場合は、ウインドウが閉じる前にログをコピーしてください。

セットアップとベースイメージのインストール

Linux のベースイメージが存在するまで、どのマシンも実行できません。初回起動時、オンボーディングウィザードは Bromure へようこそ で開きます。はじめる をクリックすると インストール ステップに進み、bromure-ac init と同じインストールが実行されます。全体の流れはインストールと初回起動にあります。このセクションでは、失敗したときの対処を扱います。

ビルド済みのダウンロードが失敗または停滞する

原因。 推奨される経路では、署名済みで gzip 圧縮されたイメージを https://dl.bromure.io からダウンロードし、SHA-256 を検証して展開します。ネットワークの中断、CDN の不調、チェックサムの不一致があると中断されます。ダウンロードはすでに再試行するようになっており、試行の間にカタログを取得し直します（週次の公開で、ダウンロード中に前のビルドが置き換わることがあるためです）。

対処。 ステータスと コンソール出力 を確認します。ダウンロード側で失敗すると、アプリは ローカルで構築 または キャンセル を選べる イメージのダウンロードに失敗 アラートを表示します。

1. オンラインで一時的な失敗だった場合は、アプリメニューから再試行します: ベースイメージを再構築… → ビルド済みをダウンロード。
2. ダウンロードが成功しそうにない場合（制限の厳しいネットワーク、ブロックされた CDN）は、ローカルで構築 を選んで Mac 上でイメージを構築します（約 10 分）。できあがるイメージは同じです。
3. コマンドラインでは、bromure-ac init が自動的にローカルビルドにフォールバックします。

「ベースイメージのビルド中にネットワークの問題」

原因。 ローカルビルドは、DHCP リースと外部アクセスを必要とする使い捨ての Alpine インストーラー VM を起動します。一部の VPN やロックダウンされたネットワークでは、リースを取得できなかったり、MTU の不一致によりダウンロードがブラックホール化されたりします。

対処。 ビルドは、修復してやり直す（macOS のネットワークデーモンを再起動します — 管理者パスワードを求めます）または キャンセル を選べる ベースイメージ構築中のネットワークの問題 アラートで止まります。VPN 上で失敗し続ける場合は、再試行する前にゲストの NIC の MTU を下げます。

defaults write io.bromure.agentic-coding vm.mtu -int 1280

MTU は既にデフォルトで 1280 です。企業の PMTU 経路が要求する場合にのみ、さらに下げてください。

インストールがディスク容量不足になる

原因。 イメージのインストールには、サポートディレクトリがあるボリュームに最初から少なくとも 8 GB の空き容量が必要です。さらに、ビルド中の監視機能が空き容量の不足を検知すると中断するため、ビルドが原因不明のタイムアウトまで止まり続けることはありません。

修正。 空き容量を確保して再試行してください。最も消費するものについてはディスク容量を参照してください。

ベースイメージが部分的な状態で残される

原因。 インストール途中でのキャンセルや、失敗したビルドは、一時ファイルを残します: サポートディレクトリ内の base.img.partial、base.img.gz.partial、stock.img.partial、efivars.partial です。これらがあるということは、インストールが実行中か、中断されたことを意味します。本物のイメージは常にアトミックにしか置き換えられないため、既存の動作するイメージはその間もずっと使えます。

対処。 インストールを最後まで実行し直します（ベースイメージを再構築… または bromure-ac init）。最初からやり直すには、bromure-ac reset が確認の後でベースイメージのファイル（base.img、efivars.bin、base.version、image-state.json、および保存されたダウンロード stock.img / stock-state.json）を削除します — マシンには触れません。インストールされている内容は、いつでも bromure-ac info で確認できます。

より新しいベースイメージがあります

2 種類のプロンプトが表示される可能性があります。

• ベースイメージのアップデートがあります（起動時） — アプリに同梱されている、またはカタログで公開されているベースイメージが、ディスク上のものより新しい場合です。今すぐアップデート はそれをダウンロードします（フォールバックとしてローカルでの再構築もあります）。後で は次回起動時にもう一度尋ねます。その間も現在のイメージは動作し続けます。
• より新しいベースイメージがあります。（マシンの起動時） — ディスク上のベースが、このマシンのシステムディスクのクローン元より新しい場合です。はい、アップグレード はマシンのシステムディスクを新しいベースでリセットします。VM 内に apt でインストールしたものはすべて消去されますが、ホームフォルダは保持されます。いいえ は次のベースが出るまで現在のベースを使い続けます。あとで通知 は明日以降の最初の起動時にもう一度尋ねます。回答はマシンごとに記憶されます。

ベースイメージを更新しても、それだけで既存のマシンのディスクが変わることはありません。各マシンは、あなたが はい、アップグレード と答えたときにだけアップグレードされます。

マシンが開始・起動・再開しない

マシンはサイドバーの 仮想マシン の下に一覧表示されます。マシンの行にある ⋯ ボタンには 開始（または 再開、実行中は シャットダウン / サスペンド / 再起動）があります。セッションがステージにあるときは、ツールバーのマシンメニュー — マシン名が付いたカプセル — に マシンの詳細 があります。CPU、メモリ、ディスク、稼働時間のカードを備えたダッシュボード、構成の概要、電源ボタンです。マシンについてはマシンで説明しています。

起動が終わらない（「ダイブ失敗」）

原因。 マシンは事前にウォームアップされていません — コピーオンライトのディスクからコールドブートする（またはサスペンドのスナップショットを復元する）ため、数秒かかります。30 秒たってもターミナルが応答しない場合、起動画面は ダイブ失敗 に変わります: 「VM が停止しているか、システムディスクが破損している可能性があります。」

修正。

1. 待ち続ける を一度クリックします — イメージのアップデート後の初回起動や、低速な Mac では時間がかかることがあります。
2. それでも起動しない場合は、マシンの ⋯ メニューから再起動します（再起動）。
3. システムディスク上の壊れたファイルが原因の場合は、壊れたファイルで起動できないマシンを復旧するを参照するか、システムディスクをリセット… をクリックしてベースイメージからシステムディスクをクローンし直します。ホームフォルダ — プロジェクト、dotfiles、.ssh の鍵、シェルの履歴 — は残ります。apt でインストールしたものと /etc 以下の変更は失われます。

マシンの起動がディスクエラーで止まる

原因。 システムディスクが起動時のファイルシステムチェックに失敗しました — たいていは、書き込みの途中で VM が止まったためです（強制終了、クラッシュ、停電）。ゲストはここから自力では先に進めません。

対処。 マシンのステージに ディスクエラー — 「システムディスクが起動時のファイルシステムチェックに失敗したため、起動を続行できません。」 — と、それを引き起こしたコンソール行が表示されます。

1. ディスクを修復 をクリックします。Bromure は VM を止め、組み込みのチェッカーで Mac 上からディスクのジャーナルを再生して、再び起動します。何も削除されません。
2. 修復後も起動に失敗する場合は、システムディスクをリセット… をクリックして ベースにリセット を確認します。ホームフォルダは残ります。

リッチクライアントでは、同じ選択がプロンプトとして届きます: 「“‹machine›” can't boot — disk error」。最初は ディスクを修復 / 後で、修復を一度試した後は Reset System Disk / 後で です。マシンを停止した状態で、自分で修復を実行することもできます: bromure-cli vm fsck <machine> --repair。高度な操作を参照してください。

サスペンドしたマシンが中断したところから再開しない

原因。 再開では、保存された RAM（vm.state）を、マシンのまったく同じ仮想ハードウェアに復元します。サスペンド以降に構成が変わった場合 — メモリの増減、共有フォルダの変更、アプリやベースイメージの新しいビルド — 保存された状態はもう復元できません。

何が起きるか。 Bromure はマシンを止まったままにはしません。復元に失敗すると、保存された状態を破棄し、同じディスクとホームでマシンを新たに起動します。ファイルはすべて残っています。失われるのは、サスペンドしたセッションで実行中だったプログラムと開いていたターミナルだけです。アプリのログには理由が記録され、何が変わったかが示されます — たとえば configuration changed since the suspend: memoryGB: 8 → 6 — booting fresh。サスペンド中のマシンを起動するオートメーションや委任も同じように動作します。

関連するケース:

• サスペンド中に共有フォルダを変更した。 マシンの設定を保存すると 「‹machine›」の中断中の VM を破棄しますか？ と尋ねられます — 破棄して保存 を選びます。次回の起動はコールドブートになります。ホームと共有フォルダ内のファイルには影響しません。
• ディスクのリセットや消去は、常に保存された状態を破棄します。新しいディスクと古い RAM の組み合わせは、即座に破損してしまうためです。
• 開発版のビルド。 あるビルドのアプリが保存した状態は、別のローカルビルドでは復元できないことがよくあります。ビルドを切り替える前に、マシンをサスペンドではなくシャットダウンしてください。

マシンが「侵害あり」とマークされた

原因。 プロキシが、マシンの代替認証情報が発行先ではないホストへ向かうのを検知しました — 持ち出しの兆候です。リクエストはブロックされ、VM は一時停止し、この環境は侵害されている可能性があります というアラートが漏洩の内容を一覧表示して、4 つの選択肢を示します。

リッチクライアントやヘッドレスの Mac では、プロンプトは シャットダウン / ブロック / 許可 を示し、誰も答えなければ シャットダウン にフォールバックします。マシンの ガードレール ペインで 認証情報の流出時に警告しない をオンにしている場合、アラートは表示されません。漏洩はそれでもブロックされ、タイムラインに記録されます。

対処。 侵害ありとマークされたマシンは「侵害あり — 起動時にディスクとホームの消去を求められます」と表示し、⛔「‹machine›」は侵害ありとしてマークされています で消去を確認するまで起動を拒否します。消去して起動 はディスク、ホーム、保存された状態を削除してから、新しい VM を起動します — 認証情報、SSH 鍵、マシンの設定は保持されます。共有プロジェクトフォルダは Bromure のストレージの外にあるため消去されません。汚染されたファイルがないか手作業で確認してください。オートメーションや委任は消去を確認できません。その起動は「The workspace is marked compromised — start it yourself to confirm the wipe.」で拒否されます。検出モデルは認証情報とワイヤ境界で説明しています。

「The workspace did not boot in time」/「did not start in time」

原因。 セッション、オートメーション、コーディングタスクがマシンの起動を待ち、あきらめました。よくある理由:

• マシンが実際に起動に失敗した — ステージに ダイブ失敗 または ディスクエラー が出ていないか確認します（上記参照）。
• 無人の起動が、あなたの応答を必要としたために拒否された。オートメーションの実行履歴には、タイムアウトの代わりに理由が表示されます: 「The workspace is marked compromised — start it yourself to confirm the wipe.」または「“‹model›” is still downloading — the workspace can't start until it has.」。
• Mac がスリープ中だった、または過負荷だった。

対処。 マシンの ⋯ メニューから自分でマシンを開始してステージを確認し、表示されるプロンプトに答えてから、セッションや実行をやり直します。起動時のプロンプト（イメージのアップデート、新しい推奨パッケージ）はメインウインドウのシートとして表示され、マシンの起動をブロックすることはありません。

新しいセッションが代わりに「エージェントが応答しませんでした…」と表示する場合は、マシンが古い VM 内エージェントを実行している可能性があります。⋯ メニューから 再起動 して、もう一度試してください。

空きディスク容量が足りない

原因。 コピーオンライトクローンやホームイメージの作成は、ボリュームの空きが 1 GB 未満の場合は続行を拒否し、セッションの途中で行き詰まるのではなく、ディスクフルエラーで早期に失敗します。

対処。 空き容量を確保して（ディスク容量を参照）、マシンをもう一度開始します。

壊れたファイルで起動できないマシンを復旧する

原因。 ゲストに書き込まれた設定ミス（壊れた /etc/fstab、破損したドットファイル）は、修正のためにログインする前に VM の起動を止めてしまうことがあります。macOS は ext4 をマウントできないため、Finder でディスクを開くこともできません。

対処。 マシンを停止した状態で、組み込みの ext4 ブラウザを使います。

1. ワークスペース › ext4 ファイルを開く… を選び、~/Library/Application Support/BromureAC/profiles/<uuid>/ 以下にあるマシンの disk.img または home.img を選びます。
2. 問題のファイルまで移動します。右クリックして プレビュー するか、Mac に 抽出… します。
3. その場で修正するには、編集を有効にする… をクリックし（実行中の VM が開いているイメージは絶対に編集しないでください）、右クリック → 置き換える… で Mac 上の修正済みのコピーに差し替えます。
4. ジャーナルの回復が必要だとブラウザが報告した場合は、先に fsck を実行… をクリックします。チェッカーは組み込みで、何もインストールする必要はありません。

損傷がホームにある場合 — エージェントが何かを削除したり壊したりした場合 — マシンの ⋯ メニューにある ホームを巻き戻す… で、ホームを以前の起動時の状態に戻せます。高度な操作を参照してください。

警告: インプレースの置換は、新しい内容がファイルの既に割り当て済みのブロックに収まる場合にのみ機能します。ファイルを拡大しようとすると拒否されます（「That file would need to grow」）。設定の修正やファイルの取り出しには使えますが、データの追加には使えません。

「ディスクをリセット」/「ホームを消去…」がグレーアウトしている

原因。 これらの破壊的な操作は、マシンの実行中は拒否されます。

対処。 まずマシンをシャットダウンしてから（ツールチップには「Close the session window first.」と表示されます）、やり直します。

Kubernetes のノードとレジストリ

クラスタとレジストリは専用のマシンで動き、仮想マシン › Kubernetes と レジストリ の下に一覧表示されます。Kubernetes クラスタとレジストリを参照してください。

終了や停止の後にノードやレジストリが戻らない

Bromure の動作。 アプリを終了するとクラスタのノードとレジストリはサスペンドされ、次回の起動で再開されます。復元できないスナップショットは、ほかのマシンと同様に新規の起動にフォールバックします。明示的な 停止 は、最大 60 秒の猶予付きでそれらをきれいにシャットダウンします。

それでもノードの起動がファイルシステムのチェックで止まる場合、Bromure はコンソールでそれを検知して VM を止め、ノードのシステムディスクとデータディスクに組み込みのチェッカーを実行し、それでも足りなければ、使い捨てのマシンから Linux の e2fsck をそれらに対して実行します。起動を一度だけ再試行し、それも失敗するとクラスタに明確なエラーが表示されます。

対処。 クラスタの ログ タブで何が起きたかを確認します。自動修復があきらめた場合は、クラスタの クラスタの操作 メニューからクラスタを再起動します。最後の手段として、削除して作り直します。

ワークスペースからクラスタやレジストリが見えない

原因。 アクセスはマシンごとです。クラスタやレジストリのアクセスリストにないマシンには、~/.kube/config のコンテキストも $BROMURE_REGISTRY も与えられません。

対処。 クラスタまたはレジストリの アクセス タブ（クラスタの場合は クラスタの操作 › ワークスペースのアクセス… も）を開き、マシンを追加します。クラスタのコンテキストは、アクセスを変更するとすぐに、実行中のマシンの ~/.kube/config へ送られます。

サインインとモデルの問題

この設計では、本物の認証情報を VM に置きません。ゲストは代替（「偽の」）トークンで動作し、ホストのプロキシが通信経路上で本物のシークレットに差し替えます。「認証」の症状のほとんどは、この境界にさかのぼります。認証情報とワイヤ境界とモデルとプロバイダーを参照してください。

エージェント、またはあなたが偽の API キーを目にする

原因。 これは想定どおりです。VM 内の ANTHROPIC_API_KEY、OPENAI_API_KEY、XAI_API_KEY、GH_TOKEN などの環境変数、および AWS の変数は、意図的なおとりです。プロキシは許可された宛先に対してホスト側で実際の値に置き換えるため、漏洩した偽物は無価値です。

対処。 何もしません — VM 内で鍵を「修正」しようとしないでください。本物のリクエストがプロバイダーで認証エラーになる場合、問題はホスト上の本物のシークレットです: 環境設定 › モデル（マシンが独自のモデル設定を持つ場合は、そのマシンの モデル ペイン）で、プロバイダーの API キーを入力し直します。誤ったホストへのリクエストに偽のトークンが現れると、認証されるのではなく侵害検出が作動します。

サブスクリプションが動かなくなった（「サインインの期限切れ」）

原因。 サブスクリプションのサインイン（Claude、ChatGPT、Grok、Kimi）は暗号化されてホストに保存され、ホストがその更新も行います。プロバイダーがリフレッシュトークンを取り消したり、アカウントのセッションが終了したりすると、ホストは有効なトークンを発行できなくなり、そのサインインを使うすべてのセッションが失敗します。

修正。

1. 環境設定… › モデル（⌘,）を開きます。プロバイダーに サインインの期限切れ と「‹プロバイダー› が保存済みのサインイン（‹日付›）を拒否しました。再度サインインするまで、セッションはこれを使用できません。」が表示されます。
2. 再度サインイン をクリックし、ブラウザでサインインを完了します。マシン内の代替キーは決して変わらないため、実行中のエージェントは新しいサインインを引き継ぎます。
3. ほかのマシンは動くのに 1 台だけ失敗し続ける場合、そのマシンは独自のサインインを持っている可能性が高いです。マシン内から始めたサインインは すべてのワークスペースで共有しますか？ と尋ねます — このワークスペースのみ を選ぶと、そのマシンに共有のサインインを覆い隠す専用のログインが与えられます。マシンの モデル ペインを確認し、そこで再度サインインするか、グローバルのプロバイダーを使用 をクリックしてマシンが共有のサインインを継承するようにします。

チャットでは、認証できないエージェントがカードを表示します: ‹エージェント› にサインイン と、サインインページを開く、コードを貼り付け フィールドです。サイドバーの行には「サインインが必要」と表示されます。カードからサインインすると、モデルペインとまったく同じように、ホスト上で認証情報が取得されます。

エージェントにモデルプロバイダーが必要

原因。 選んだエージェントには、このマシンで動く手段がありません — API キーも、サインインも、カスタムサーバーもデバイス上のモデルもありません。チャットには「‹エージェント› にはモデルプロバイダが必要です」と「‹エージェント› にはこのマシンでのモデルプロバイダがまだありません。マシンの設定で API キーまたはローカルモデルを追加してから、セッションをもう一度開始してください。」が表示されます。

対処。 カードの マシンの設定… をクリックするか、環境設定 › モデル でプロバイダーを設定してから、セッションをもう一度開始します。新規セッション画面では、この状態のエージェントに「開始時にサインイン」または「開始時にモデルプロバイダを選択」と表示されます。

エージェントが初回起動、信頼、ログインの画面で止まっている

原因。 コーディングエージェントには独自の初回起動画面 — テーマの選択、フォルダの信頼に関する質問、ログインメニュー — があり、チャットはそれをそのままでは表示できません。Bromure はエージェントの起動前にオンボーディング画面に答え、残りはチャット内のカードに変換します。

• ログインメニューには サインインカード（Claude の「Not logged in」、Codex の ChatGPT の選択、Grok のデバイスコード、Kimi のログイン）。
• エージェントがフォルダの信頼を待っているときは このフォルダを信頼して続ける。
• エージェントが認証できなかった、使用量の上限に達した、またはエラーで止まったときは赤いカード。
• 独自のサインインを持たない Oh My Pi には、マシンの設定を案内するプロバイダーカード。

対処。 カードに答えます。それでもチャットが止まっているように見える場合 — 「考え中…」のまま何も起きない — ツールバーの Linux（⌥⌘U）を押してエージェントの本物のターミナルを表示し、画面に出ているものに対処してから、セッション を押して戻ります。カードの「ターミナルに切り替えて解決してから、もう一度送信してください。」も同じ意味です。

Kimi Code の場合、Bromure は Kimi の国際版サービス（kimi.ai）に対してサインインします。この変更より前に行った Kimi のサインインは動かなくなり、サインインカードが表示されることがあります。もう一度サインインしてください。

「サブスクリプショントークンを入れ替えますか?」が繰り返し表示される、または誤って拒否した

原因。 エージェントが VM 内で本物のトークンを使ってログインすると、プロキシがそれを検出し、本物のシークレットがゲストから出ていくようにホストへ移すことを提案します。この選択はマシンごと、プロバイダーごとに記憶されます。

対処。 マシンの トレース ペインでは、Claude サブスクリプショントークンの差し替え と Codex サブスクリプショントークンの差し替え の行が、現在の状態とリセット用のコントロール — 入れ替えを忘れる（次のセッションで再確認） または プロンプトを再有効化 — を表示します。

VM 内のネットワーク

ゲストで IPv6 が動かない

原因。 仕様です。Bromure のホストのネットワーク経路は IPv4 のみで、IPv6 を広告しながら IPv6 の外向き通信が機能しない LAN では、すべての AAAA 問い合わせが止まってしまいます。最近のベースイメージはゲスト内で IPv6 をオフにしており、apt は起動のたびに IPv4 に強制されます。

対処。 IPv4 アドレスとホスト名を使ってください。ゲスト内の localhost は 127.0.0.1 のみに解決されます。

マシンのサブネットが、使っているネットワークと衝突する

原因。 新規インストールでは、マシンを 172.16.0.0/12 内のランダムなプライベート /24 に置きます（Docker が通常使う 172.17〜172.20 と、Mac がすでに属している範囲は除外します）。古いインストールでは、まだ 192.168.64.0/24 を使っている場合があります。どちらも VPN やオフィスのネットワークと衝突する可能性があります。

対処。 環境設定… › リソース を開きます。ワークスペースのサブネット の下で、プライベートサブネットを使用（リモート間の衝突を回避） はランダムな 172.16/12 サブネットに切り替え、ランダムに選択 は新しいサブネットを選びます。変更は、マシンを次に起動したときに適用されます。

VPN 上でマシンの通信が失敗する

原因。 VPN のトンネルは使えるパケットサイズを小さくします。MTU が大きすぎると、ダウンロードが消えてしまいます。

対処。 ゲストの NIC はすでに 1280 バイトに制限されています。企業ネットワークの経路でさらに小さい値が必要な場合は、ベースイメージのビルド中にネットワークの問題で示したとおりに vm.mtu を下げます。

VM 内の TLS と証明書のエラー

「self-signed certificate」または「unable to get local issuer certificate」

原因。 ゲストのすべての HTTPS はホストの MITM プロキシによってインターセプトされ、インストールごとのルート CA でトラフィックを再署名します。VM 内のツールは、Bromure が node、python、go、rust、curl、deno、および AWS SDK 向けに設定する CA バンドル環境変数と、メタ共有にステージングされた CA ファイル（bromure-ca.pem）を通じて、これを信頼します。これらの変数を無視するツール、または独自のトラストストアを持ち込むコンテナは、プロキシの証明書を拒否します。

修正。

1. ほとんどのツールでは、何もする必要はありません。特定のツールが失敗する場合は、検証を無効にするのではなく、書き出された CA バンドルをそのツールに指定します。CA ファイルはゲスト内で利用でき、*_CA_BUNDLE / SSL_CERT_FILE のような標準的な変数はすでにエクスポートされています。
2. ネットワークにアクセスする必要がある Docker コンテナでは、新しいコンテナを実行 シートの HTTP プロキシ設定を引き継ぐ トグルを使って http_proxy/https_proxy（127.0.0.1:65534 のゲスト内プロキシ）が伝わるようにし、コンテナのツールが CA を探す場所に CA をマウントまたはインストールします。
3. 証明書エラーが CA を削除またはローテーションした後にだけ出る場合（下記参照）は、影響を受けるマシンを再起動して、新しい CA が配置されるようにします。

証明書をピン留めしているホストについては、マシンの ガードレール ペインで 1 回のリクエストに限り傍受を迂回できます（X-bromure-insecure） — ガードレールの設定を参照してください。

ルート CA のローテーション

原因 / 実施するタイミング。 ルート CA の秘密鍵は ~/Library/Application Support/BromureAC/ca/key.pem（モード 0600）にあり、その証明書は cert.pem にあります。鍵が漏洩した疑いがある場合は、ローテーションするとよいでしょう。

対処。 アプリを終了し、ca/ ディレクトリを削除して、再度起動します — 新しい CA が生成され、マシンの次回起動時に配置されます。すでに取得済みのトレースの本文は影響を受けませんが、古い証明書をピン留めしていたゲストは、新しい証明書を信頼し直す必要があります。

サプライチェーンのブロック

エージェントの npm install、pip install などが特徴的なエラーで失敗する場合、ホストのサプライチェーンのパイプラインが介入した可能性が高いです。ポリシーとそのレイヤーはサプライチェーン保護とサプライチェーン設定のリファレンスで説明しています。

インストールが HTTP 451 で失敗した

原因。 451（「Unavailable For Legal Reasons」）は Bromure のサプライチェーンブロックです。ガードレールが使用する 403 と一目で区別できるように選ばれています。パッケージマネージャーは、そのエラー出力に理由をそのまま表示します。例:

Bromure Supply-Chain Security blocked this request: npm package [email protected]
published 4 hours ago — policy requires 2 days minimum

修正。 理由を読んでください。よくあるトリガーとその対処:

タイムラインで理由を見つける

セキュリティタイムラインを開き、サプライチェーン エンジンを選んで、インストールをもう一度実行します。確認された各パッケージが行として表示されます: 通過したものは緑、ブロックまたは除去されたものは赤です。インストール中にタイムラインに何も出ない場合、たいていはすべてがキャッシュから来たということです — 概要タブの 確認したパッケージ タイルで、チェックが行われていることがわかります。

ブロックを上書きする

対処。 サプライチェーンのレイヤーはマシンごとのオン/オフのトグルで、即座に適用されます（VM の再起動は不要）。特定のパッケージを通すには、サプライチェーン ペインで除外または許可リストのエントリを追加するか、そのマシンについて該当するレイヤーを下げるか無効にします。

すべてのインストールが同意を求める（オフライン、または socket.dev + Cargo）

原因。 OSV または socket.dev が有効でも判定を出せない場合（ネットワークがダウンしている、またはエコシステムが未対応）、Bromure は フェイルクローズ し、各パッケージを黙って許可するのではなく、あなたの同意を得るまで保留します。パッケージごとにプロンプトが表示される状況が 2 つあります:

• オフラインでの作業 で OSV または socket.dev が有効: キャッシュされていないすべてのパッケージが保留されます。
• socket.dev と Cargo: socket.dev は Cargo をサポートしていないため、すべての crates.io 成果物は判定が得られません。

修正。 オフラインの期間は、OSV と socket.dev を無効にしてください。経過期間ゲートは接続なしでも、既にキャッシュされたメタデータから機能し続けます。Rust の大量作業では、socket.dev をオフにするか、プロンプトに応答してください（許可は package@version ごとにキー付けされます）。PyPI の公開時刻バックストップは、純粋なネットワークエラーでオープンにフェイルする唯一のチェックです。

プロンプトインジェクションの誤検知

プロンプトインジェクション検出器は、エージェントに返されるコンテンツをスキャンし、ログ記録、確認、ブロックを行えます。その動作と調整については、プロンプトインジェクションの検出とガードレールとプロンプトインジェクション設定のリファレンスで説明しています。

正当なリクエストがフラグ付けまたはブロックされた

原因。 分類器が、受信した一部分に、マシンのしきい値を超えるスコアを付けました — セキュリティのドキュメント、攻撃を引用したページ、エージェントへの指示のように読める断片は、どれもインジェクションのように見えることがあります。

修正。

1. タイムラインの プロンプトインジェクション の行を確認し、本当の攻撃だったかを判断します。
2. 誤検知でブロックが邪魔になる場合は、プロンプトインジェクション ペインで、マシンのプロンプトインジェクションモードを ブロック から 確認する（検出ごとにあなたが決めます）または ログ（記録のみで、ブロックしない）に変更します。
3. 設定はマシンごとなので、ノイズの多い調査用のマシンは ログ モードで動かし、本番用のマシンは ブロック のままにできます。

エージェント間のメッセージもスキャンされます: 警告された委任メッセージには「保留 — プロンプトインジェクション」と表示され、エージェント間の委任 の下に記録されます。

イベントトリガーの自動化がすべてブロックされる

原因。 イベントトリガーの自動化には PromptGuard モデルが必要です。これがないと、すべてのイベント実行は「PromptGuard model not installed — event triggers require it (download in Settings).」でブロックされます。これはバグではなく仕様です。

対処。 プロンプトインジェクション ペインから PromptGuard モデルをインストールします。検出器のトグルがオンなのにモデルのダウンロードに失敗している場合 — たとえばディスクがいっぱいだった場合 — マシンは保護なしで動作し、その失敗がログに記録されます。空き容量ができたら、もう一度ダウンロードしてください。

ディスク容量: 使われ方と回収方法

何が容量を消費するか

ストレージは ~/Library/Application Support/BromureAC/ 以下にあります（全体の構成は付録を参照）。容量を大きく使うもの:

メモ: ダッシュボードのディスクカードは、ホストのクローンの割り当てよりもゲスト自身の df の数値を優先します。コピーオンライトクローンは使用量を過大に報告するためです。ゲスト内で解放されたブロックは、クローン内では実体化されたまま残ります。

容量を回収する

• 使っていないサスペンド中のマシンをシャットダウンします。完全にシャットダウンすると vm.state が消え、次回はコールドブートになります。
• もう使わないデバイス上のモデルを削除します。環境設定 › モデル から、または bromure-cli model rm <id> で行います。
• マシンの ⋯ メニューの ディスクをリセット で、肥大化したシステムディスクをリセットします（ベースからクローンし直し、ホームは保持します）。
• bromure-cli trace clear で トレースをクリア します。メモリ内リングとディスク上の本体の両方を消去します。
• 不要になったセッションを削除し（行のメニューの セッションを削除）、マシンやフォルダがなくなった会話は、サイドバーの整理用の行から削除します。
• 不要になったマシン全体を削除します（⋯ › ワークスペースを削除、または bromure-cli workspaces rm <workspace>）。そのディスクとホームが削除されます。
• 使っていないクラスタとレジストリを削除します。それぞれのダッシュボードから行います。
• 最初からやり直したい場合は、bromure-ac reset でベースイメージを回収します（マシンには触れないので、後で init をやり直します）。

リモートアクセスとリッチクライアント

オプションの SSH リモートアクセスの玄関口と、リッチクライアントのミラーについては、リモートアクセスとクライアントで説明しています。以下は、接続を妨げる症状です。

SSH（ポート 2222）で接続できない

原因。 リモートの玄関口はデフォルトで無効です。また、これは組み込みのサーバー（システムの sshd ではありません）なので、macOS のリモートログインを有効にしても影響はなく、ベースイメージのインストール中は一時停止されます。

修正。

1. bromure-cli remote status で状態を確認します — サーバーが有効で動作しているか、バインドアドレスとポート、認証方式、ホストキーのフィンガープリント、すぐ使える ssh -p <port> <user>@<host> 接続文字列、そして承認済みの鍵の一覧が表示されます。
2. bromure-cli remote enable で有効にします（デフォルト: ポート 2222、バインド 0.0.0.0、両方の認証方式が有効）。両方の認証方式が無効な場合、ポートが 1024 未満の場合、またはベースイメージが存在しないかインストール中の場合はエラーになります。
3. bromure-cli remote key add <path-or-key> で公開鍵を追加します。キーの追加や削除はリスナーを再起動し、ライブ接続を切断します。これは想定どおりの動作です。

ホストキーまたはフィンガープリント（TOFU）の不一致

原因。 リッチクライアントは、初回接続時に各リモートのホストキーをピン留めします（初回利用時の信頼）。これは ~/Library/Application Support/BromureAC/remote-client/known_hosts に保存されます。ピン留めはエンドポイント（address:port）ごとなので、保存済みホストのアドレスやポートを編集すると、当然ながら信頼のプロンプトが再び表示されます。エンドポイントが変わっていないのに不一致になる場合は、リモートの鍵が変わったか — 何かが接続を傍受しています。

修正。 リモートを正当に再構築した場合は、そのピンを削除して再接続し、再び信頼してください。キーが変わることを予期していなかった場合は、受け入れる前に作業を止めて調査してください。

リモートの環境設定が読み込まれない

原因。 ミラーウィンドウが開いているとき、環境設定… はリモートホストの設定を編集できます（設定対象: ピッカー）。取得中は「‹ホスト› から環境設定を読み込み中…」と表示し、接続が切れたりリモートが古いバージョンだったりすると「リモートの環境設定を読み込めませんでした」と表示します。

対処。 ミラーウィンドウが接続されていることを確認してから、再試行 をクリックします。その間に自分の設定を編集するには、設定対象: で この Mac を選びます。

システム全体のトンネルに承認が必要

原因。 リッチクライアントのオプションのシステム全体トンネルは、SMAppService を通じて登録された特権 launchd デーモンを使用します。その最初の登録では、バックグラウンド項目の承認トグルが表示されます。

対処。 システム設定 › 一般 › ログイン項目と機能拡張 で Bromure Agentic Coding を承認します（アプリがそのパネルを開くこともできます）。トンネル経由では、リモートのゲストへの ICMP ping はローカルで応答されるため、確認できるのはルーティングであって、ゲストが生きていることではありません。

バグを報告する

bromure.io でレポートを提出する際は、メンテナーが再現できるだけの情報を含めてください:

1. アプリとイメージのバージョン — アプリのバージョン（About Bromure Agentic Coding から）と、bromure-ac info の出力（ベースイメージのバージョンスタンプ、サイズ、パス）。
2. アプリのログ — ~/Library/Logs/BromureAC/bromure-ac.log（問題が前回の起動より前に始まった場合は bromure-ac.log.1 も）。メンテナから詳しい情報を求められたら、ターミナルから BROMURE_AC_DEBUG=1 を付けて起動し直します。
3. 関連する記録 — セットアップの失敗なら、コピーした コンソール出力。セキュリティ関連の動作なら、セキュリティタイムラインから 書き出す… で出力した、フィルタ済みの CSV。
4. 期待したことと実際に起きたこと、そしてマシンがオフ、サスペンド中、実行中のどれだったか。

本物のシークレットは含めないでください — トレースの記録やログの行では、すでに短いプレビューに切り詰められています。また、アプリはそもそも本物の認証情報が VM に入らないように作られています。Mac が bromure.io のワークスペースに登録されている場合は、組織の管理者を通して報告してください。登録についてはエンタープライズで説明しています。