疑難排解

本章依症狀分類整理。每個項目都會說明可能的原因與修復步驟。請先從 第一步：記錄、健康狀態與應用程式狀態 開始——以下幾乎每項診斷都仰賴這三種來源之一——接著跳至符合您所見情況的章節。

以下大部分內容都以兩項事實為基礎。第一，工作區是一個持久的沙箱：其系統磁碟（disk.img）與 Linux 家目錄（home.img）會在每次啟動之間持續保留，因此單純重新啟動並無法解決其中的問題。第二，Bromure Agentic Coding 會在流量抵達 VM 之前，於主機上強制執行安全性原則——因此看似出現在客體「內部」的封鎖與錯誤，通常其實是主機代理伺服器所致，應在應用程式中處理，而非在 VM 中。

第一步：記錄、健康狀態與應用程式狀態

在變更任何設定之前，先了解應用程式本身回報了什麼。

安全記錄

開啟 視窗 → 安全記錄…。這是主機代理伺服器所發出的每一項安全事件的即時串流：供應鏈查詢與 451 封鎖、安裝指令碼移除、提示注入偵測、憑證替換與外洩警告、Fusion 與路由變更，以及遠端存取事件。使用 篩選… 欄位可縮小至特定套件名稱、主機或工作區，取消勾選 自動捲動 則可在閱讀時固定目前位置。

附註： 安全記錄是一個約 5,000 行的記憶體環形緩衝區，並不會在應用程式重新啟動後保留。若您需要一份持久的副本——或正在追查會導致應用程式當機的問題——請從終端機啟動 bromure-cli（見下一節）；每一行記錄也會同時鏡像輸出至 stderr。

從終端機擷取 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 }

若您已開啟迴路自動化伺服器（偏好設定 → 自動化，預設為關閉），同一個端點也可透過 TCP 在所設定的連接埠上存取——預設為 9223：

curl http://127.0.0.1:9223/health

連線遭拒表示應用程式（或其無介面代理程式）並未執行；bromure-cli vm ls 會視需要啟動背景代理程式，也是另一種快速的存活檢查。debugEnabled 旗標會回報 BROMURE_DEBUG_CLAUDE 是否已解鎖除錯端點。

設定主控台記錄

在安裝基底映像檔期間，設定視窗中有一個收合的 主控台輸出 展開項，會串流原始安裝程式記錄，並附有 複製 按鈕。展開它可觀看進度；若需附加至錯誤報告，可複製整份記錄。畫面上僅保留最後 100 行，因此請在視窗關閉前先複製。

設定與基底映像檔安裝

在 Linux 基底映像檔存在之前，應用程式無法執行任何工作區。首次啟動會顯示 歡迎使用 Bromure Agentic Coding 視窗；按一下 開始使用 會執行與 bromure-cli init 相同的安裝程序。完整流程記載於 安裝；本節說明安裝失敗時該如何處理。

預建映像檔下載失敗或停滯

原因。 首選路徑會從 https://dl.bromure.io 下載一個已簽署的 gzip 壓縮映像檔（約 3 GB），驗證其 SHA-256，然後將其展開。網路中斷、CDN 暫時故障或總和檢查碼不符都會使其中止。下載本身已會重試最多三次，並在每次嘗試之間重新擷取目錄（每週發佈可能會在下載途中刪除前一個組建）。

修復。 觀察設定視窗中的狀態標記與 主控台輸出。發生下載端失敗時，GUI 會顯示 映像檔下載失敗 警示，提供 在本機建置 或 取消 選項：

1. 若您已連線且只是暫時性失敗，請關閉警示並從應用程式選單重試：重建基底映像檔… → 下載預建映像檔。
2. 若下載無法成功（網路受限、CDN 遭封鎖），請選擇 在本機建置，改為在您的 Mac 上建置映像檔（約 10 分鐘）。這會產生相同的映像檔。
3. 在命令列中，bromure-cli init 會自動改用本機建置，不會另行提示。

「基底映像檔建置期間發生網路問題」

原因。 本機建置會啟動一個用完即棄的 Alpine 安裝程式 VM，它需要 DHCP 租約與對外存取權。在某些 VPN 與受嚴格限制的網路上，它取得不到租約，或其下載因 MTU 不符而被無聲丟棄。

修復。 建置會停止並顯示 基底映像檔建置期間發生網路問題 警示，提供 修復並重試（透過 Network Healer 重新啟動 macOS 網路服務精靈——會要求輸入您的管理員密碼）或 取消 選項。若在 VPN 上持續失敗，請在重試前將客體網路卡的 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 會在確認後刪除四個基底映像檔產物（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 迷你圖——若一分鐘後仍平貼在零，表示它沒有任何進展。
2. 從儀表板動作列就地重新開機（重新開機 → 強制重新開機 會立即將其終止）。
3. 若仍無法開機，磁碟本身可能已損毀。可從工作區的回復介面還原至最近的良好狀態，或使用 重設磁碟 從基底映像檔重新複製（這會保留家目錄；但會捨棄任何已儲存的 RAM 快照與分頁狀態）。重設為基底… 則是最徹底的手段。
4. 若想修復而非重設，可用 ext4 瀏覽器檢查已停止的磁碟——請參閱 復原因損毀檔案而無法開機的工作區。

已暫停的工作區無法繼續

原因。 繼續會還原已儲存的 RAM（vm.state）與分頁配置（tabs.json），這需要工作區持久的機器身分與 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」）。請用它來修正設定與取出檔案，而非新增資料。

「重設磁碟」／「清除家目錄…」呈現灰色無法使用

原因。 當工作區的工作階段視窗開啟時，這些破壞性動作會被拒絕。

修復。 請先關閉工作階段視窗（按鈕的工具提示會顯示「Close the session window first.」），然後重試。

代理程式身分驗證失敗

此設計讓真正的憑證不進入 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，擷取新的權杖，並儲存於主機端。工作區內的假金鑰始終不會改變。

「是否替換訂閱權杖？」持續出現，或誤按了拒絕

原因。 這是另一種訂閱機制：當代理程式在 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），來信任該 CA。若某個工具忽略了這些變數——或某個容器自備信任存放區——就會拒絕代理伺服器的憑證。

修復。

1. 對大多數工具而言，無需任何動作。若某個特定工具失敗，請將它指向系統／匯出的 CA 套件組，而非停用驗證；CA 檔案在客體內可取得，而標準的 *_CA_BUNDLE／SSL_CERT_FILE 樣式變數也已匯出。
2. 對於需要連上網路的 Docker 容器，請使用 執行新容器 面板中的 繼承 HTTP 代理伺服器設定 切換開關，讓 http_proxy／https_proxy 得以傳遞，並在容器工具尋找 CA 的位置掛載或安裝該 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 會失敗時封閉（fail closed），為每個套件保留待您同意，而非默默放行。有兩種情況會導致每個套件都出現提示：

• 離線作業 且啟用了 OSV 或 socket.dev：每個未快取的套件都會被保留。
• socket.dev 搭配 Cargo： socket.dev 不支援 Cargo，因此每個 crates.io 產物都無法產生結果。

修復。 若會離線一段時間，請停用 OSV 與 socket.dev——時效閘門在無網路連線的情況下仍可依已快取的中繼資料運作。若有大量 Rust 工作，可關閉 socket.dev，或直接回應提示（授權以 package@version 為索引鍵）。PyPI 發佈時間的後備檢查是唯一一項在純網路錯誤時會*失敗時開放（fail open）*的檢查。

提示注入誤判

提示注入偵測器會掃描傳回給代理程式的工具結果區段，並可記錄、詢問或封鎖。其行為與調校記載於 提示注入 與 提示注入設定 參考文件中。

正當的請求被標記或封鎖

原因。 分類器將某個傳入區段評分為高於工作區的門檻——安全性文件、引用了某次攻擊的頁面，或讀起來像是在對代理程式下指令的片段，都可能看起來具有注入的特徵。

修復。

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 快取中釋放權重）。
• 以 重設磁碟 重設膨脹的工作區磁碟（從基底重新複製，保留家目錄），或從回復介面刪除舊的檢查點。
• 以 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）不符

原因。 完整用戶端會在首次連線時釘選每個遠端的主機金鑰（首次使用即信任，TOFU），儲存於 ~/Library/Application Support/BromureAC/remote-client/known_hosts。釘選是以端點（address:port）為單位，因此編輯已儲存主機的位址或連接埠會使原本的釘選失效，並正確地重新觸發信任提示。在未變動的端點上出現不符，代表遠端的金鑰已改變——或有東西正在攔截該連線。

修復。 若您確實重建了遠端，請移除其釘選並重新連線以重新信任。若您並未預期金鑰會改變，請先停下並調查，再決定是否接受它。

遠端格狀配置或瀏覽器窗格無法鏡像

原因。 無介面 的遠端——應用程式在執行中但未開啟任何統一視窗——無法接受或提供格狀配置編輯，不過其他一切都會鏡像。某些由提示驅動的工作樹操作（新增工作樹、合併、解決衝突）在 v1 中也無法從完整用戶端使用，而多主機子網路別名是一項有記載的設計限制，並非已推出的行為：單一遠端主機才是受支援的組態。

修復。 在遠端開啟一個工作階段視窗，讓它有一個統一視窗可供鏡像。若要在遠端進行工作樹的建立／合併／解決衝突，請改用 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 可見。註冊記載於 企業。