Repository navigation
Background agent completion retention #2595
Description
Describe the bug
Completed background agents are purged from the CLI agent registry very quickly, so read_agent can
return Agent not found even after a successful completion notification.
Summary
Background agents are retrievable while running, but completed agents appear to have only a very short retention
window. In this session, the original code-review-auditor agent auth-audit showed as running for several minutes,
then later vanished entirely from list_agents, and read_agent returned Agent not found. A separate live repro showed
the same behavior with tiny probe agents, so this does not look specific to the custom reviewer.
Affected version
GitHub Copilot CLI 1.0.21.
Steps to reproduce the behavior
- Start a tiny background agent.
- Confirm it appears in list_agents while running.
- Wait for completion notification.
- Immediately call read_agent / list_agents --include_completed and observe it is briefly available.
- Wait a few more seconds and call them again.
- The completed agent disappears from list_agents, and read_agent returns no agent found.
Expected behavior
Completed background agents should remain readable/listed for a reasonable period, at least long enough for normal
follow-up after the completion notification.
Additional context
Actual
Completed agents are purged very quickly after finishing, sometimes within a few seconds of post-completion access.
Impact
Long-running background reviews can finish successfully but become unrecoverable before the user or orchestrator
reads the result, which makes background mode unreliable for required audit outputs.
Evidence from this session
- auth-audit was started and later observed as still running.
- Later, read_agent(auth-audit) returned Agent not found.
- Live repro agents showed the same short-lived post-completion availability.
Current workaround
- Use mode: "sync" when the result must be preserved before handoff.
- If using background, read and capture the result immediately after completion.
Activity
antonech commentedon Jul 4, 2026
Still reproducing on 1.0.68 (47 releases after the 1.0.21 report), and in my case the agent became unreachable before the foreground session ever received the completion notification — so it's not just a short post-completion retention window; the orchestrator can lose the agent entirely with no notification and no result.
Environment
What I saw
mode="background",name="dff-lights-explore"). Tool returned: "Agent started in background with agent_id: dff-lights-explore. You'll be notified when it completes."list_agents()→<no background agents>.read_agent("dff-lights-explore")→ Agent not found.Log evidence (the tell)
The agent did finish internally — the CLI's own log shows the completion firing — yet the foreground registry had already dropped it:
An earlier session shows the internal callback firing too:
So the completion callback runs, but the user-facing registry entry is already gone — no notification is surfaced and
read_agent/list_agentscan't find it.Hypothesis
The parent CLI keeps the agent registry in-memory and drops the child's entry (fork/detach or premature cleanup) before the completion notification is delivered to the foreground turn. Persisting the registry across the process boundary and deferring cleanup until after the notification is surfaced (and the result read) would fix it.
Impact / workaround
Same as reported — background delegation is unreliable for required outputs;
mode:"sync"(or reading immediately on completion) is the workaround, but here even immediate reads failed because the entry was already gone before any notification.