トラブルシューティング

この章は症状別に構成されています。各項目では、考えられる原因とその修正手順を示します。まずは最初の確認先: ログ、ヘルス、アプリの状態から始めてください。以下のほぼすべての診断は、これら 3 つの情報源のいずれかに依存しています。その後、目にしている状況に合ったセクションに進んでください。

以下の内容の大半は、2 つの事実に基づいています。第一に、ワークスペースは永続的なサンドボックスです。そのシステムディスク（disk.img）と Linux のホーム（home.img）は起動をまたいで保持されるため、いずれかに生じた問題は単に再起動するだけでは解消されません。第二に、Bromure Agentic Coding はトラフィックが VM に到達する前に、ホスト上でセキュリティポリシーを適用します。そのため、ゲストの「内部」で発生するように見えるブロックやエラーは、通常はホストプロキシによるものであり、VM ではなくアプリ内で解決します。

最初の確認先: ログ、ヘルス、アプリの状態

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

セキュリティログ

ウィンドウ → セキュリティログ… を開きます。これは、ホストプロキシが発行するすべてのセキュリティイベントのライブテールです: サプライチェーンのルックアップと 451 ブロック、インストールスクリプトの除去、プロンプトインジェクションの検出、認証情報の入れ替えと漏洩警告、Fusion とルーティングの変更、リモートアクセスイベントなど。フィルター… 欄を使ってパッケージ名、ホスト、ワークスペースに絞り込み、自動スクロール のチェックを外すと、読んでいる位置を保持できます。

メモ: セキュリティログは約 5,000 行のメモリ内リングバッファであり、アプリの再起動をまたいで保持され ません。永続的なコピーが必要な場合、またはアプリをクラッシュさせる問題を追っている場合は、ターミナルから bromure-cli を起動してください（次のセクション参照）。すべてのログ行は stderr にもミラーされます。

ターミナルから stderr を取得する

アプリはログを標準エラー出力にミラーします。ターミナルから起動すると、アプリの再起動やクラッシュを乗り越える、永続的でコピー可能な記録が得られます:

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

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

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

自動化のヘルスチェック（GET /health）

アプリは実行中、常に所有者専用の制御ソケットを ~/Library/Application Support/BromureAC/control.sock で稼働させます。ヘルスを問い合わせることでアプリが生存して応答していることを確認でき、小さな JSON オブジェクトが返されます:

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 はバックグラウンドエージェントをオンデマンドで起動するため、もう 1 つの手軽な生存確認になります。debugEnabled フラグは、BROMURE_DEBUG_CLAUDE がデバッグエンドポイントのロックを解除したかどうかを報告します。

セットアップのコンソールログ

ベースイメージのインストール中、セットアップウィンドウには折りたたまれた コンソール出力 の開閉部があり、生のインストーラーログをストリーミングし、コピー ボタンが付いています。展開して進行状況を確認し、バグレポートに添付する必要がある場合はログ全体をコピーしてください。画面に残るのは最後の 100 行だけなので、ウィンドウが閉じる前にコピーしてください。

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

アプリは Linux のベースイメージが存在するまで、どのワークスペースも実行できません。初回起動時には Bromure Agentic Coding へようこそ ウィンドウが表示されます。はじめる をクリックすると、bromure-cli init と同じインストールが実行されます。全体の流れはインストールに記載しています。このセクションでは、失敗した場合の対処を扱います。

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

原因。 推奨される経路では、署名付きの gzip 圧縮イメージ（約3 GB）を https://dl.bromure.io からダウンロードし、その SHA-256 を検証して展開します。ネットワークの中断、CDN の不具合、チェックサムの不一致があると中止されます。ダウンロードは既に最大 3 回まで再試行し、試行の合間にカタログを再取得します（週次の公開により、ダウンロード中に前のビルドが削除されることがあります）。

修正。 セットアップウィンドウのステータスピルと コンソール出力 を確認してください。ダウンロード側の失敗では、GUI に イメージのダウンロードに失敗 というアラートが表示され、ローカルでビルド または キャンセル の選択肢が提示されます:

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

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

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

修正。 ビルドは ベースイメージのビルド中にネットワークの問題 というアラートで停止し、修復して再試行（Network Healer を介して macOS のネットワークデーモンを再起動します。管理者パスワードを求められます）または キャンセル の選択肢が提示されます。VPN 上で失敗し続ける場合は、再試行の前にゲスト NIC の MTU を制限してください（WireGuard 系のトンネルでは 1280 以下が必要になることがよくあります）:

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

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

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

原因。 すべてのイメージインストールは、サポートディレクトリを保持するボリューム上に事前に少なくとも 8 GB の空きを必要とします。また、ビルド中のモニターは空き容量が 1 GB を下回ると中止します（apt/debootstrap が原因不明のタイムアウトに再試行しないようにするため）。

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

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

原因。 インストールの途中でのキャンセルやビルドの失敗は、サポートディレクトリに一時ファイル（base.img.partial、base.img.gz.partial、efivars.partial）を残します。これらが存在することは、インストールが実行中であるか中断されたことを意味します。実際のイメージは常にアトミックにのみ昇格されるため、既存の動作するイメージは終始使用可能なままです。

修正。 インストールを最後まで再実行してください（ベースイメージを再構築… または bromure-cli init）。最初からやり直すには、bromure-cli reset が確認の後、4 つのベースイメージ成果物（base.img、efivars.bin、base.version、image-state.json）を削除します。これはワークスペース、キャッシュされた Alpine ファイル、キャッシュされたカタログには 触れません。何がインストールされているかは、bromure-cli info でいつでも確認できます。これはバージョンスタンプ、論理サイズと物理サイズ、パスを表示します（または「No base image yet.」）。

ワークスペースが起動または再開しない

サイドバーでワークスペースを選択すると、そのダッシュボードが表示されます: 状態ピル（オフ、サスペンド、実行中）、CPU / メモリ / vCPU / ディスク / 稼働時間のカード、構成 の概要、そして 開始 または 再開 ボタン。ワークスペースのライフサイクルはワークスペースで扱っています。以下の症状は、VM が動かなくなるものです。

開始しても何も起こらない、または VM の起動が終わらない

原因。 ブラウザペインとは異なり、ワークスペース VM は事前にウォームアップされません。コピーオンライトディスクからコールドブートする（またはサスペンドスナップショットから復元する）ため、数秒かかります。CLI のアタッチは起動を通じて最大約 60 秒待ちます。本当に起動が止まっている場合は、通常はゲストのファイルシステムの破損か、ゲストが処理できない設定ファイルを意味します。

修正。

1. 時間を与えてから、ダッシュボードの CPU スパークラインを確認してください。1 分経ってもゼロで平坦なままなら、進行していないことを意味します。
2. ダッシュボードのアクションバーからその場で再起動します（再起動 → ハード再起動 は即座に破棄します）。
3. それでも起動しない場合、ディスク自体が損傷している可能性があります。ワークスペースのロールバック UI から最近の正常な状態に復元するか、ディスクをリセット を使ってベースイメージから再クローンします（これはホームディレクトリを保持します。保存された RAM スナップショットとタブの状態は破棄されます）。ベースにリセット… は最終手段です。
4. リセットではなく修復するには、ext4 ブラウザで停止中のディスクを検査してください。不正なファイルで起動できないワークスペースを復旧するを参照してください。

サスペンド中のワークスペースが再開しない

原因。 再開は保存された RAM（vm.state）とタブレイアウト（tabs.json）を復元します。これにはワークスペースの永続的なマシン ID と MAC が必要です。サスペンド中にワークスペースの共有フォルダが変更された場合、再開は安全ではありません。

修正。 共有が変更された場合、アプリは 「…」のサスペンド中の VM を破棄しますか? と尋ねます。破棄して保存 を選んでください。次回の起動はクリーンにコールドブートします。ホームと共有フォルダのファイルは影響を受けません。ディスクがリセットまたは消去されると、保存された RAM スナップショットは常に破棄されることに注意してください。新しいディスクと古い RAM を組み合わせると即座に破損するため、これは仕様です。

ワークスペースが「侵害」とマークされる

原因。 プロキシは、発行対象ではないホストへセッション認証情報を漏洩させようとする送信の試みを検出し、あなたが シャットダウン または 調査のために保存 を選びました。ワークスペースは compromised.flag でフラグ付けされ、ピッカーは「侵害 — 起動するとディスクとホームの消去を確認します」とバッジを付けます。

修正。 次回の起動は、消去を確認するまで起動を拒否します。消去して起動 はディスク、ホーム、RAM スナップショット、タブの状態を削除し、その後すぐに新しい VM を起動します。トークン、SSH キー、ワークスペース設定は保持されます。共有プロジェクトフォルダは Bromure のストレージの外にあり、消去され ません。そのため、汚染されたファイルがないか手作業で確認してください。検出の全体的な流れは認証情報にあります。

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

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

修正。 空き容量を確保し（ディスク容量を参照）、もう一度 開始 を試してください。

不正なファイルで起動できないワークスペースを復旧する

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

修正。 ワークスペース VM を停止した状態 で、組み込みのユーザーランド ext4 ブラウザを使用します:

1. ワークスペース メニュー → ext4 ファイルを開く… を選び、~/Library/Application Support/BromureAC/profiles/ 配下のワークスペースの disk.img または home.img を選択します。
2. 問題のファイルまで移動します。右クリックして プレビュー するか、Mac に 抽出… します。
3. その場で修正するには、編集を有効化… をクリックし（明示的な警告があります。実行中の VM が開いているイメージは決して編集しないでください）、右クリック → 置換… で Mac 上の修正済みコピーに置き換えます。
4. ブラウザがジャーナルの回復が必要だと報告した場合は、まず fsck を実行… を実行してください（e2fsprogs が必要です。見つからない場合、アプリは brew install e2fsprogs を提案します）。

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

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

原因。 これらの破壊的な操作は、ワークスペースのセッションウィンドウが開いている間は拒否されます。

修正。 まずセッションウィンドウを閉じ（ボタンのツールチップには「先にセッションウィンドウを閉じてください。」と表示されます）、その後で再試行してください。

エージェント認証の失敗

この設計では、実際の認証情報を VM から遠ざけます。ゲストはプレースホルダー（「偽の」）トークンで動作し、ホストプロキシがワイヤ上で実際のシークレットに入れ替えます。ほとんどの「認証」症状は、その境界に起因します。完全なモデルについては認証情報を参照してください。

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

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

修正。 何もありません。VM 内でキーを「修正」しようとしないでください。実際のリクエストがプロバイダーで認証エラーによって失敗している場合、問題はホスト上の実際のシークレットです。ワークスペースの 認証情報 ペインを開いて再入力してください。誤ったホストへのリクエストに現れた偽のトークンは、認証されるのではなく侵害検出を作動させます。

サブスクリプションログイン（Claude / ChatGPT / Grok で登録）が動作しなくなった

原因。 サブスクリプション 認証モードでは、OAuth トークンは使い捨ての登録 VM で一度取得され、ホスト上に暗号化して保存されます（claude-subscription.enc、codex-subscription.enc、grok-subscription.enc）。更新はホストが担います。リフレッシュトークンが取り消されたり、期限切れになったり、アカウントのセッションが終了したりすると、ホストは有効なベアラーを発行できなくなり、リクエストが失敗し始めます。

修正。 再登録してください。ワークスペースの エージェント ペインで、保存されたサブスクリプションを忘れ、Claude / ChatGPT / Grok で登録 を再度実行します。これは新しい使い捨て VM を起動し、新しいトークンを取得して、ホスト側に保存します。ワークスペース内の偽のキーは決して変わりません。

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

原因。 これはもう 1 つのサブスクリプションの仕組みです。エージェントが VM 内で実際のトークンでログインすると、プロキシがそれを検出し、実際のシークレットをゲストから移すためにホストへ移動することを提案します。この選択はワークスペースごと、プロバイダーごとに記憶されます。

修正。 ワークスペースの トレース ペインでは、Claude サブスクリプショントークンの入れ替え と Codex サブスクリプショントークンの入れ替え の行に 有効 または 拒否 が表示され、リセットコントロール（入れ替えを忘れる（次のセッションで再確認） または プロンプトを再有効化）が付いています。リセットすると、次のセッションで再度確認されます。同意とセッションごとの許可はメモリ内のみで、アプリの再起動をまたいで保持されません。

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 を伝播させ、コンテナのツールが参照する場所に CA をマウントまたはインストールしてください。
3. 証明書エラーが CA を削除またはローテーションした後にのみ表示される場合（下記参照）、影響を受けたセッションを再起動して、新しい CA を再ステージングしてください。

ルート 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

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

セキュリティログで理由を読む

ウィンドウ → セキュリティログ… を開いて、インストールを再実行してください。行は色分けされています: 送信ルックアップは青、クリーンな判定は緑、ブロックと失敗は赤、除去されたインストールスクリプトはオレンジ、そしてポリシーが作動するたびにアクセント付きの [supply-chain] 行が表示されます。完全にクリーンなインストールでも、成果物ごとに「inspecting pkg@ver」という行が出力されます。これは意図的なもので、ログが静かなことは「プロキシがバイパスされた」のではなく「すべてキャッシュ済み」を意味します。

ブロックを上書きする

修正。 サプライチェーンのレイヤーはワークスペースごとのオン/オフトグルで、ライブで編集できます（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> で 未使用のローカルモデルを削除 します（新しいレイアウトとレガシーな Hugging Face キャッシュの両方から重みを解放します）。
• ディスクをリセット で 肥大化したワークスペースディスクをリセット する（ベースから再クローンし、ホームは保持）か、ロールバック UI から古いチェックポイントを削除します。
• bromure-cli trace clear で トレースをクリア します。メモリ内リングとディスク上の本体の両方を消去します。
• 不要になった ワークスペース全体を削除 するには bromure-cli workspaces rm <workspace> を使います（確認の後、ディスクとホームを削除します）。
• 最初からやり直したい場合は bromure-cli reset で ベースイメージを回収 します（ワークスペースはそのままなので、後で init し直してください）。

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

オプションの SSH リモートアクセスの入り口とリッチクライアントのミラーは、リモートアクセスで扱っています。以下の症状は、接続を妨げるものです。

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

原因。 リモートの入り口は デフォルトで無効 です。また、これは組み込みサーバー（システムの sshd ではない）であるため、macOS のリモートログインを有効にしても効果はなく、ベースイメージのインストールや修正の間は自動的に一時停止されます。

修正。

1. bromure-cli remote status で状態を確認してください。サーバーが ENABLED で実行中かどうか、バインドアドレスとポート、認証方式、ホストキーのフィンガープリント、すぐに使える 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）の不一致

原因。 リッチクライアントは初回接続時に各リモートのホストキーをピン留めし（trust-on-first-use）、~/Library/Application Support/BromureAC/remote-client/known_hosts に保存します。ピン留めはエンドポイント（address:port）ごとなので、保存されたホストのアドレスやポートを編集すると、引き継がれたピンが無効になり、正しく信頼プロンプトが再度トリガーされます。変更していないエンドポイントでの不一致は、リモートのキーが変わったこと、または何かが接続をインターセプトしていることを意味します。

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

リモートのグリッドまたはブラウザペインがミラーされない

原因。 ヘッドレスなリモート（アプリは実行中だが統合ウィンドウが開いていない）は、グリッドレイアウトの編集を受け付けたり提供したりできません。ただし、それ以外はすべてミラーされます。一部のプロンプト駆動の worktree 操作（新規 worktree、マージ、解決）も v1 のリッチクライアントからは利用できず、マルチホストのサブネットエイリアシングは、出荷された動作ではなく、文書化された設計上の制限です。単一のリモートホストがサポートされる構成です。

修正。 リモートでセッションウィンドウを開き、ミラーする統合ウィンドウを用意してください。リモートでの worktree の作成/マージ/解決には、リッチクライアントのツールバーではなく、SSH/TUI のリモートメニューを使用してください。

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

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

修正。 システム設定 → 一般 → ログイン項目と機能拡張 で Bromure Agentic Coding を承認してください（アプリがそのペインを開けます）。トンネル越しでは、リモートゲストへの ICMP ping はローカルで応答され、ゲストの生存ではなくルーティングを確認します。

バグを報告する

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

1. アプリとイメージのバージョン — アプリのバージョン（4.3.0）と bromure-cli info の出力（ベースイメージのバージョンスタンプ、サイズ、パス）。
2. stderr ログ — ターミナルから stderr を取得するで示したようにターミナルから bromure-cli を起動し、問題を再現して、出力を添付してください。メンテナーがさらに詳細を求める場合は BROMURE_AC_DEBUG=1 を追加してください。
3. 該当するウィンドウ — セットアップの失敗にはセットアップウィンドウからコピーした コンソール出力、セキュリティ関連の動作にはフィルターした セキュリティログ。
4. 期待した結果と実際に起きたこと、そしてワークスペースがオフ、サスペンド、実行中のいずれだったか。

実際のシークレットは含めないでください。トレース記録とログ行は既にそれらを短いプレビューに秘匿しており、アプリは実際の認証情報がそもそも VM に入らないように作られています。Mac が bromure.io ワークスペースに登録されている場合は、組織の管理者を通じてレポートを送ってください。登録関連の状態は管理者には見えますが、Bromure に直接は見えません。登録についてはエンタープライズで扱っています。