Today wrap and the tail_* family (vercel/aws/kubectl/etc.) collect logs in a one-shot window: spawn child → buffer up to 20k
lines / 90s → kill child → POST → return a single summary string. The providers themselves often support live follow (kubectl
logs -f, docker compose logs -f, flyctl logs, pm2 logs, journalctl -f, etc.) but codag terminates the child after 90s, so the
follow mode is not used. That works for "run this command and tell me what happened," but doesn't fit longer-lived
debugging where logs flow continuously and an agent may want a fresh snapshot every few minutes without re-running anything. The
underlying streaming primitive already exists (internal/exec/stream.go:62). Collect is just a wrapper around it.
Proposal: add a streaming mode where the CLI owns a long-lived child (or tails an existing source), pushes lines into a session
keyed by a run-id, and the MCP surface gains a snapshot tool that reads the current templates for that session.
What would be new
- CLI: a codag tail (or wrap --stream) that doesn't terminate on first POST.
- API: session endpoints (ingest, templates) on the hosted side.
- MCP: a snapshot(session_id) tool returning the current compacted view, alongside the existing one-shot compact.
- A session store: eviction policy, max retained sessions, auth scoping.
Open questions
- Sessions opt-in (--session foo) or auto-generated per child?
- State across CLI restarts - local sqlite, or round-trip the server?
- In scope for the free tier (deterministic drain only) or paid only?
@michaelzixizhou
Today wrap and the tail_* family (vercel/aws/kubectl/etc.) collect logs in a one-shot window: spawn child → buffer up to 20k
lines / 90s → kill child → POST → return a single summary string. The providers themselves often support live follow (kubectl
logs -f, docker compose logs -f, flyctl logs, pm2 logs, journalctl -f, etc.) but codag terminates the child after 90s, so the
follow mode is not used. That works for "run this command and tell me what happened," but doesn't fit longer-lived
debugging where logs flow continuously and an agent may want a fresh snapshot every few minutes without re-running anything. The
underlying streaming primitive already exists (internal/exec/stream.go:62). Collect is just a wrapper around it.
Proposal: add a streaming mode where the CLI owns a long-lived child (or tails an existing source), pushes lines into a session
keyed by a run-id, and the MCP surface gains a snapshot tool that reads the current templates for that session.
What would be new
Open questions
@michaelzixizhou