CommandCodeAI / CommandCodeAI/command-code

feat: Allow mods to spawn and await background agents / background work

Abierto
#691 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
4k
Forks
350
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

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.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Comienza rastreando la superficie existente de ModApi cmd.exec y las interfaces entre agent, background-agent y background-shell descritas en el issue. Compara su comportamiento con el TUI Background panel (Ctrl+B) y el modo headless (-p). Se considera terminado cuando un mod puede iniciar trabajo sin bloquearse, recibir su resultado final al completarse, exponerlo en el background panel y degradarse de forma determinista en modo headless.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Área
api, backend, cli
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Tranquilo
Claridad
Bastante claro
Aptitud para principiantes
35/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.