CommandCodeAI / CommandCodeAI/command-code
feat: Allow mods to spawn and await background agents / background work
還沒有人認領這個 Issue。
- 主要語言
- 沒有語言資料
- 星號
- 4k
- 分支
- 350
- PR 合併指標
- 30 天內沒有已合併 PR
描述
Feature Description
Summary
Mods currently have no way to run work in the background. The agent tool (with run_in_background: true), background agents (background: true), and background shell tasks are all seams the main agent drives — none are reachable from a mod. Mods only have cmd.exec (foreground shell) and the synchronous onStop + prepareNextTurn force-continue seam for post-run model turns.
Motivation
Post-run maintenance work — summarization, extraction, knowledge discovery, compaction — is exactly the kind of task that should run detached from the main loop, on a cheap model, without blocking or polluting the session. Today a mod that wants a model to do post-run work must inject a continuation turn (onStop with {continue: true}) that runs in-line: it occupies the same run, renders in the feed, and competes with sibling mods over the single continuation slot (harness short-circuits "any mod returning continue wins").
Alternatives considered
- Keep the onStop continuation seam and just make the injected turn quieter. Doesn't solve the collision problem (one continuation slot shared by all
mods) or the "detached from the run" goal. - Background shell + cmd.events polling. Mods could shell out to cmd -p via a background process, but there's no background cmd.exec, and reacting to
completion would require polling from a hook — no clean completion signal.
Acceptance criteria
- A mod can launch a background agent and continue the session without blocking.
- The spawning mod is notified (hook or event) when the agent completes, with the agent's final result.
- The behavior is observable in the TUI Background panel (Ctrl+B) like other background work.
- Works headless (-p), degrading deterministically.
Use Case
Mods am building or trying out that could use background running
-
Memory/journal mods that extract compressed episodes or discover durable facts from a finished run (e.g. the project-brain / task-journal pattern).
-
Any mod wanting to fan out parallel investigation or run a long background process and react when it completes.
Current gap -
No cmd.agent(...) / cmd.spawnAgent(...) equivalent on ModApi — a mod cannot launch the built-in agent tool or a custom agent.
-
No background variant of cmd.exec (no way to get a task id + log + wake-up like shell_command run_in_background / monitor_command).
-
No hook or event a mod can register to be notified when a background agent it spawned finishes (the result of agent_output never reaches a mod).
Proposed API (suggestion — open to design)
Something like:
- cmd.agent({prompt, agent?, model?, runInBackground: true}) → Promise<{agentId}> — spawn a background agent from a mod.
- A completion hook or event, e.g. cmd.hooks({onAgentResult}) or cmd.events.on('agent_completed', ...), delivering the agent's final result to the
spawning mod. - Optionally: a background cmd.exec variant returning a task id + on-disk log, mirroring shell_command run_in_background.
Additional Context
- Sort of how taste learning works to be honest
How important is this to you?
Medium. Nice mod improvements for UX, but right now these are experiments and sync running is ok.
貢獻指南
這個儲存庫沒有索引到貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
首先追蹤現有的 ModApi cmd.exec 介面,以及 issue 中描述的 agent、background-agent 與 background-shell 之間的銜接點。將它們的行為與 TUI Background panel (Ctrl+B) 和 headless 模式 (-p) 進行比較。完成的標準是:mod 可以在不阻塞的情況下啟動工作,在完成時接收其最終結果,在 background panel 中呈現該結果,並在 headless 模式下以確定性的方式降級。
由索引模型根據 Issue 內容生成。
評估
- 領域
- api, backend, cli
- Issue 類型
- 功能
- 難度
- 5/5
- 預估耗時
- 一週以上
- 活躍度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 35/100