任務執行
最後更新
同一 session 的任務如何並行、如何取消，以及中斷的工作如何續行。
Per-session 併發
MAX_SESSION_TASKS（v1.3.0 起為 CPU 數的一半、至少 3；v1.1.2 起固定為 3，先前為 NumCPU × 4）限制單一 session 可同時執行的 Execute() 呼叫數。任務會先發布 ToriiDB online marker 並登記取消函式，才去競爭並行空位，因此排隊中的任務仍可見、可取消，而不是隱形地卡住。marker 的 TTL 為 60 秒、每 55 秒續期，被砍掉或崩潰的行程靠過期自行下線，不需檢查 PID。此值於啟動時計算一次，不從 config.json 讀取。背景工作（v1.3.0）不占用這些空位，另有同值的 per-session 上限 MAX_BACKGROUND_TASKS。取消執行
取消是逐任務而非逐 session：
POST /v1/session/:id/cancel/:task_hash 停止單一執行中的任務（{"cancelled": true}）；該 task hash 不在本行程執行中時，會記錄一筆取消事件並回傳 {"cancelled": false, "stale": true}。原本的 once_id 識別碼已改為 task hash。工具確認另以 POST /v1/session/:id/confirm/:confirm_hash 回覆，confirm_hash 取自確認事件。刻意不提供「全部取消」的變體，因此可在不影響同 session 其他任務的前提下丟棄某個長跑任務。在 TUI 中，執行期間按 Esc（先關閉開啟中的 / 指令面板與提示框）會對當前任務開啟取消確認 popup，尚未顯示任何內容時則直接取消；v1.2.0 起 TUI 以 socket 上的 cancel frame 將取消送往 daemon。v1.3.0 起不論經由哪條路徑取消任務，都會一併停止其背景工作。續行中斷的工作
停在
ask_user 或確認上的執行會留下待決任務。GET /v1/session/:id/task 只列出真正可續行者：執行中的 run 每 55 秒刷新 ToriiDB 的 action:<session_id>:<task_hash>（TTL 60 秒），因此被關閉視窗或被砍行程遺留的任務會在一分鐘內出現在清單中，而仍在處理中的任務不會。以 POST .../resume 回答，或以 DELETE .../:task_hash 丟棄。TUI 中對應 /pending，v1.2.0 起以 pending frame 經 daemon 續行，已存的問題以 inline 方式詢問。v1.3.0 起 TUI 任務曾因其啟動的背景工作仍在執行而維持 pending、每份報告到達時自動接回，並在 /pending 標示 [Active]；此行為移除於 v1.3.8：任務現在照常結束，背景報告的送達方式見待決任務與取消。已完成的執行同樣可查：
GET /v1/session/:id/task/history 以 task_hash、end_at、objective、model、reasoning 列出（可選 keyword 過濾），GET .../:task_hash/history 以 content 回傳單次執行的完整 action 記錄。