概述
涵蓋 v5.1.8 ～ v5.1.21（2026-10 月上旬，13 個已發布版本；v5.1.20 因發布管線失敗從未問世，變更全併入 v5.1.21）。這條支線的主軸不是新架構，而是把 OmO Native 的三根柱子——Code Mode、權限系統、任務生命週期——各自推到可依賴的程度：
| 版本 | 引擎（senpi） | 一句話 |
|---|---|---|
| v5.1.8 | 2026.10.1-2 | Hotfix：bun 不再啟動幻影 agent；模型路由改版；中日文記憶召回 |
| v5.1.9 | 2026.10.1-3 | Desktop 受限模式不對內部工具請求批准；Windows 冷啟 Python 修復 |
| v5.1.10 | 2026.10.1-3 | Hotfix：omo -p 在任務結束後能退出（不再掛住 CI/cron） |
| v5.1.11 | 2026.10.1-3 | 與 host 失聯的任務重連或限時結束並釋放 lane |
| v5.1.12 | 2026.10.2 | omo.computer.permission_required 事件；平台包「smoke 通過才發布」 |
| v5.1.13 | 2026.10.3 | MCP 共用事故修復：session 各自綁定共用 servers |
| v5.1.14 | 2026.10.5 | 安全修復：權限啟動失敗改為 fail-closed |
| v5.1.15 | 2026.10.6 | auto permission preset；TUI 呈現打磨 |
| v5.1.16 | 2026.10.7 | host handoff；visual-qa skill 加入 Apple HIG 檢查清單 |
| v5.1.17 | 2026.10.8 | 閒置 host 會退出；Windows memory reflection 修復 |
| v5.1.18 | 2026.10.9 | one-shot engine 指令修復；Bun 下限 1.4；%load、%pip install |
| v5.1.19 | 2026.10.10 | Code Mode per-session 套件；沙箱 cell；閒置 worker 回收 |
| v5.1.21 | 2026.10.10-3 | isolation.js: "process"；/mcp 管理器；v5.1.20 併入此版 |
Code Mode：沙箱、獨立 kernel 與 per-session 套件
Per-session 套件安裝（v5.1.19）
Code Mode 的 eval cell 現在能自己裝套件。整格 cell 只寫 %bun add 或 %npm add 時，套件會裝進這個 session 自帶的 managed environment（受控環境）：
%bun add zod下一格 cell 直接 import 使用。三個關鍵保證：
- 不重啟 kernel——裝完接著跑
- 不碰專案——專案的
package.json與node_modules原封不動 - 不執行套件 scripts——安裝階段的 postinstall 等腳本一律不跑，供應鏈攻擊面收窄
v5.1.18 同期補上 %load <path>（載入檔案進 cell）與免重啟 kernel 的 %pip install，Python 側也有 agent(prompt, tools=[...]) 與 workpool 的 cell 定義工具。
隔離的三個層級
| 層級 | 設定 | 隔離什麼 | 適用 |
|---|---|---|---|
| 無（預設） | — | — | 日常 cell，最快 |
| 沙箱 cell | isolate: true（搭配 sandbox.enabled，v5.1.19） |
cell 跑在 senpi 沙箱的 QuickJS runtime，沒有 ambient process 與 fetch |
不信任的探索性程式碼 |
| 獨立 kernel 程序 | isolation.js: "process"（v5.1.21） |
每個 JavaScript kernel 各自一個程序；segfault、OOM、process.exit 只死那個 kernel |
長 session 防崩潰 |
isolation.js: "process" 的行為細節：kernel 崩潰後下一格 cell 自動在新 kernel 上繼續，並出一則指名崩潰原因的 notice——session 不會被拖下水。官方明確定位它是防崩潰，不是防惡意程式碼（那是沙箱 cell 的工作）。
工具面的小補強
- Python cell 的
@tool函式現在能像 JavaScript 的tool(fn)一樣授予任務子程序（v5.1.19） - Code mode 的
wait()與handle()擴及 omo 自己的 task children 與 workpools（v5.1.18） kernelTools.enabled: false、languages.pyInterpreter、prompt.advertiseHelpers: true等「設了卻被忽略」的設定在 v5.1.21 全部生效
權限系統：從靜默降級到 fail-closed
v5.1.14 安全修復
v5.1.13（含）之前，權限系統啟動失敗時——permissionPreset 拼錯、某條規則是 null、approvals 檔不可讀——後果是：所有工具呼叫在完全沒有權限檢查的情況下繼續執行，而且沒有任何提示。
v5.1.14 起，權限系統起不來就關門：每次工具呼叫被拒絕，錯誤訊息是 Permission setup failed: <reason>，直到你把設定修好。這是教科書級的 fail-closed（失敗即關閉）。
auto permission preset（v5.1.15）
新的 auto preset 只在能證明動作停留在專案內時才免問批准——判定依據是每個工具實際將開啟的那個檔案，而不是籠統的路徑前綴。無法釘死的動作一律照問；你自訂的 deny / ask 規則永遠優先於 auto 的判斷。
MCP：一次共用事故與 /mcp 管理器
v5.1.13：MCP server <name> is disabled
v5.1.10 起，一個 memory child 或被委派任務（delegated task）結束時，會把整個 process 共用的 MCP servers 一併關掉——之後所有 MCP 呼叫都失敗。根因是資源釋放以 process 為單位，而使用者是以 session 為單位在用。
修復方向：每個 session 對共用 servers 各自持有 binding，child 結束只釋放自己的。還沒升級時的官方暫時解法是關閉 memory（~/.omo/omo.json 設 "memory": { "enabled": false }，或啟動加 --omo-senpi-memory-disabled=true）。
v5.1.21：/mcp 互動式管理器
/mcp 打開終端機內的 server 管理介面，每列 server 依當前狀態提供動作：啟用/停用、變更暴露等級（exposure）、測試、重連、登入/登出，旁邊還有工具、詳細資訊與日誌檢視。
邊界設計值得注意：只有受信任的 global 與專案 servers 可編輯，且編輯會保留設定檔其餘內容；imported、extension、skill 與未受信任的專案 servers 一律唯讀。非 TUI 客戶端收到的是狀態文字。
團隊在 v5.1.11 上開著 memory 跑了一陣子，發現所有 MCP 呼叫都報「MCP server github is disabled」。在升級到 v5.1.13+ 之前，官方提供的暫時解法是？
💡 想先看個提示？
事故的觸發者是 memory 的 child session——先讓觸發者不出場。
Memory：多語召回與 Windows reflection 修復
中文/日文逐字召回（v5.1.8）
Memory recall 過去對 CJK 文字採整體比對，換個措辭就找不到筆記。v5.1.8 起中文與日文漢字逐字比對——問題的用字與筆記不同仍能命中。同版新增 memory.recall.query_expansion: true：recall 可自動用同義詞、你其他語言的關鍵字與相關詞擴充查詢；擴充詞的權重低於原查詢的實際命中，全查詢命中的筆記仍排最前。
Windows：reflection 停擺與 /facts retry（v5.1.17）
Windows 上 reflection 失敗曾被誤記為「provider 拒絕」，自動 reflection 連續失敗幾次後自我停用（parked）——記憶系統看似正常，實際上不再保存任何事實。
v5.1.17 修復後，帶修復的版本會在下一次成功的 reflection 自動解除 parked。官方建議升級後手動跑：
/reflect # 觸發一次 reflection，立即解除 parked
/facts retry # 把 parked 期間卡住的事實補存任務可靠性與 host 生命週期
這批修復圍繞一個主題：被委派的任務（delegated task）與它賴以執行的 host，何時結束、誰來收尾。
| 問題 | 版本 | 修復 |
|---|---|---|
omo -p 印完答案不退出，CI/cron 掛住 |
v5.1.10 | in-process child 的 teardown 先跑 session_shutdown handlers，釋放 loopback bridge |
| 與 host 失聯的任務永久占用 lane，新任務排不到 | v5.1.11 | 重連，或限時以 transport lost 結束並釋放 lane；host 重啟後回收死任務的 lane |
| 取消任務在 Windows 被記成 crash | v5.1.12 | 以 runner 自身的請求判定 killed，不靠 child stderr 猜 |
| 任務子程序自帶的 fallback chain 被忽略 | v5.1.18 | 共用 task host 上依 child 的 chain 降級；host 不支援時警告一次而非靜默丟失 |
升級後首個 turn 報 No provider available（舊 host 還在） |
v5.1.16 | host handoff 可替換沒有 session 的舊 host；有 session 的仍會被擋並給出退役指令 |
| 閒置 host 永不退出（重試/續跑後 busy 狀態卡死） | v5.1.17 | host 以 run 為單位追蹤忙碌，session 關閉即釋放，閒置窗口後退出 |
| 閒置 gateway store worker 占記憶體 | v5.1.19 | 60 秒無呼叫即退役 worker，下次呼叫重建；每個 terminal control endpoint 省約 2.9 MB |
另外 v5.1.18 修好 launcher 的命令轉發：omo models discover、omo schedule 這類 one-shot engine 指令過去會被吞掉參數、直接打開互動 TUI——現在原封不動交給引擎執行。
模型與搜尋路由
- 模型檔案重整（v5.1.8）：Geeky · Heavy 與
deep-high改跑 GPT-6 Astra（high，原 xhigh）；Geeky · Normal 起跑 GPT-6.1 Sol Fast（medium，無 Fast 層級退回 GPT-6.1 Sol）；Copilot / OpenCode 使用者維持 GPT-5.6 Sol。任務撞用量上限時，結果會說明原因與恢復方式，不再吐 provider 原始錯誤 web_search路由（v5.1.8/v5.1.21）：ChatGPT 訂閱 session 可用訂閱自帶的 web search；Google Search grounding 以websearch.json選項開啟；v5.1.21 再加入keenableprovider（有apiKey走 keyed API，否則共用公共額度）- picker 整潔（v5.1.21）：provider 區塊設
hideFreeModels: true可把免費模型收出選單，付費模型好找
發布工程：管線如何擋下壞版本
v5.1.12 起，平台包只在該平台的 release-binary smoke test 通過後才發布——v5.1.8 曾把 smoke 失敗的兩個 Windows x64 包照推上 npm。v5.1.20 的中止正是這道閘門的成效：Windows smoke 對一個被檔案掃描器短暫占用的 checkout 重新命名失敗（EPERM），發布停止；v5.1.21 讓 smoke 對這種占用重試約 12 秒並指名占用者，問題不再重演。
隨堂總結測驗
開了 <code>isolation.js: "process"</code> 的 session 中，一格 cell 讓 JavaScript kernel OOM 崩潰。接下來會發生什麼？
💡 想先看個提示？
隔離的對象是 kernel 程序，不是 session。
權限系統因為設定檔裡一條 <code>null</code> 規則而起不來。v5.1.14 之後的行為是？
💡 想先看個提示？
「檢查器壞了」的系統裡，你想要哪種預設：放行還是擋下？
動手升級檢查清單
升級 v5.1.21：動手檢查清單
逐項勾選，確認你已完成升級必要的步驟（進度會保存在此瀏覽器）
延伸閱讀
-
前一課：
v517-permissions-and-boundaries——v5.0.1～v5.1.7 的權限引導與邊界修正 -
基礎課：
v500-native-stable——OmO Native stable 的完整教學 -
本主題 Changelog：完整的 v5.1.21 條目