omp 的審批解析器 resolveApproval 按「工具宣告 → 使用者覆寫 → 模式門檻」三層決策。未宣告 approval、或格式錯誤的工具，預設降級為 exec（fail-closed）。三層分工：工具自己宣告 tier + 可選 policy/override/reason；使用者用 tools.approval.<tool> 覆寫；模式（always-ask/write/yolo）決定自動通過哪些 tier。關鍵鐵律：tool-side deny 與 user-side deny 永遠不可被模式跨越；yolo 中 override: true 不會強迫 prompt，但 policy: deny 仍生效。
omp bash 工具的審批引擎把命令用共享 shell tokenizer 切成段（依 `;` `&&` `||` `|` `&` newline、subshell），deny/prompt 規則對**每段**分別匹配 glob，任一段命中即觸發；allow 規則要求**整行匹配**且**無 shell control syntax**，防止 `cd x && rm -rf /` 此類惡意段溜過去。CRITICAL_BASH_PATTERNS 硬編碼 45 個危險命令正則（`rm -rf /`、`chmod -R 777 /`、`curl | bash`、`kill -9 1` 等），優先於使用者 pattern 生效。設計權衡：allow 嚴格是為了安全，deny/prompt 寬鬆是為了可用性。
Looplane 的 effect 已有 read/modify/modify_execute/execute 四級，未分類工具 fail closed；native MCP tool 預設 execute，只有可信 read-only annotation 才降級。審批仍先進 events.jsonl，grant 可精確到同一組變更或 backend；一般化 command 規則與全 runtime sandbox coupling 仍未完成。
五家對自由 shell 的風險處理都包含放行／詢問／拒絕、複合指令檢查與 fail-closed。looplane 已補上 deny-first command classifier、critical floor、複合 shell 分段、timeout-deny、設定式 allow/deny rule 與可見的 policy reason；仍需擴大語法涵蓋與真實互動流程驗證。
agent 進 CI 後最大的問題是審批：沒有終端機、沒有人可以按 approve。五家的解法收斂成兩條路——把權限決策外包給呼叫端（claude-code 的 control protocol），或直接換掉審批語意（codex 預設 Never 配沙箱、opencode 預設自動拒絕）。looplane 用同一個 AgentRunner loop 注入不同的 ApprovalPolicy：headless 下用 HeadlessApprovalPolicy，不讀 stdin 所以不可能卡住 pipeline，EXECUTE 預設 fail closed。