bug: Idle-agent GC (2 min, hardcoded) kills agent runtimes that still have in-flight background work

[slazarov]

What's broken

Idle-agent GC (2 min, hardcoded) kills agent runtimes that still have in-flight background work

Summary

Since 0.2.0, the daemon garbage-collects idle agent runtimes after a hardcoded
2-minute TTL. The collectability test only considers paseo's notion of activity
(foreground turn, paseo runs, pending permissions) and has no visibility into work the
underlying agent CLI is running on its own — Claude Code background Bash commands,
Monitor watches, background subagents.

The result: a live agent process is killed while it still has pending work, the work is
lost, and nothing surfaces the loss. From the agent's perspective the absence of
further events is indistinguishable from "still running", so it waits indefinitely on
something that no longer exists.

The TTL and sweep interval are module constants with no config key and no environment
override, so this cannot be tuned or disabled.

To be clear about what is not broken: session continuity is fine. The runtime is
respawned with --resume=<same session id>, the transcript file is appended (not
duplicated), and no conversation state is lost. The problems are (a) silently killed
background work and (b) the prompt-cache cost of each respawn.

Environment

@getpaseo/cli	0.2.2
@getpaseo/server	0.2.2
Previously working on	0.1.110 (no 0.2.0 betas)
Agent provider	Claude Code 2.1.220, claude-opus-5[1m]
@anthropic-ai/claude-agent-sdk	^0.3.220
Node	v24.16.0
OS	Ubuntu 26.04 LTS, kernel 7.0.0-27-generic

Root cause

dist/server/server/bootstrap.js:149-150

const IDLE_AGENT_RUNTIME_TTL_MS            = 2 * 60 * 1000;  // 2 minutes
const IDLE_AGENT_RUNTIME_SWEEP_INTERVAL_MS =     15 * 1000;  // sweep every 15s

bootstrap.js:850-879 schedules an unconditional sweep (setInterval, no feature flag)
which calls agentManager.collectIdleAgents({ cutoff, protectedAgentIds }) with
cutoff = Date.now() - IDLE_AGENT_RUNTIME_TTL_MS. The constant is consumed inline at the
use site, so there is no indirection a config value could hook into.

dist/server/server/agent/agent-manager.js:845 — the collectability gate:

isIdleAgentCollectable(agent, options) {
    return (agent.lifecycle === "idle" &&
        agent.updatedAt.getTime() <= options.cutoff.getTime() &&
        !agent.internal &&
        !options.protectedAgentIds.has(agent.id) &&
        agent.activeForegroundTurnId === null &&
        !this.runs.hasRun(agent.id) &&
        !agent.pendingReplacement &&
        agent.pendingPermissions.size === 0 &&
        agent.inFlightPermissionResponses.size === 0);
}

Every clause is about paseo-side state. An agent that has finished its foreground turn but
left a background process running inside the agent CLI satisfies all of them and is
collected. collectIdleAgents then calls closeAgent → closeAgentRuntime →
agent.session.close(), terminating the child process.

The only exemptions are agent.internal agents and active schedule targets
(scheduleService.listActiveAgentTargetIds()).

Neither constant nor any equivalent idle-reaping logic exists in 0.1.110 (verified by
searching that version for collectIdle|idleAgent|reapIdle|closeIdle|evictIdle|idleTtl|IDLE_.*TTL|staleAgent
— the sole hit was an unrelated comment about HTTP closeIdleConnections()).

0.2.1 is not implicated: relative to 0.2.0 it changed only
agent/providers/claude/model-manifest.js and the web UI bundle. The @getpaseo/cli
package is byte-identical across 0.2.0/0.2.1/0.2.2.

Evidence

Daemon log (~/.paseo/daemon.log), one session collected 4 times in ~25 minutes:

07-26 06:25:10  provider=claude  session=cc8a43f8-…  "Collected idle agent runtime"
07-26 06:39:23  provider=claude  session=cc8a43f8-…
07-26 06:46:53  provider=claude  session=cc8a43f8-…
07-26 06:50:53  provider=claude  session=cc8a43f8-…

23 collections total in a single log file.

The 06:25:10 entry lands exactly 2 minutes after that agent's last activity (06:22:57), at
which point it was watching a CI run via Monitor. The watch never reported again and the
agent sat waiting on a dead process until the user intervened.

Kill-and-respawn confirmed at the OS level — two different PIDs serving one session id:

PID 736048  started 06:39:58  claude … --resume=cc8a43f8-…   → gone
PID 748012  started 06:59:10  claude … --resume=cc8a43f8-…   → current

Secondary impact: prompt-cache cost

Each respawn re-establishes the prompt prefix. Measured from the session transcript's
usage fields, one restart moved ~73k tokens from cache-read to cache-write:

06:22:57   cache_creation=  1,119   cache_read= 91,105
06:39:58   ← runtime respawned
06:40:12   cache_creation= 72,858   cache_read= 19,897

Cache writes bill at 2× base input on a 1-hour TTL versus 0.1× for reads, so that single
restart cost roughly 138k additional input-token equivalents (~$0.69 at Claude Opus 5
input pricing) against a session total of about $3.40 — near 20% overhead from one
collection. With a 2-minute TTL and normal think-time between messages, this repeats
throughout a working session.

cache_read dropping to 19,897 rather than 0 indicates the prefix diverges partway in
rather than being wholly invalidated. Cache TTL expiry is ruled out independently: the gap
was 17 minutes against a 1-hour cache TTL.

Suggested fixes

Roughly in order of value:

1. Make the collectability test aware of agent-CLI background work. The provider layer
   knows whether background tasks/monitors are outstanding; surface that as a
   hasBackgroundWork() signal and add it to isIdleAgentCollectable. This is the actual
   fix — the rest are mitigations.
2. Make the TTL configurable, with an opt-out. A daemon.idleAgentRuntimeTtlMs config
   key (0/null to disable) would let users on long-running agentic workloads turn this
   off. 2 minutes is aggressive for agents that routinely wait on CI, builds, or deploys.
3. Tell the agent on resume. If a runtime is collected with background work
   outstanding, inject a notice on the next turn — something explicit enough that the agent
   re-checks external state instead of waiting on a dead watch. The current failure is
   silent, which is what makes it costly.
4. Consider the cache cost in the TTL default. Collection trades a process for a
   prompt-cache rebuild on the next message. At a 2-minute TTL that trade is frequently
   unfavourable; a longer default (or an idle-cost heuristic) would help.

Notes

• I could not determine the issue tracker from package metadata — @getpaseo/cli has no
  repository, homepage, or bugs field. Happy to move this wherever appropriate.
• Line numbers are from the published @getpaseo/server@0.2.2 build artifacts.

Steps to reproduce

Reproduction

1. Start a Claude Code agent in a paseo workspace.
2. Have it launch background work that outlives the turn — e.g. a Monitor, or a
   Bash call with run_in_background: true that polls an external service.
3. Let the agent finish its foreground turn and go idle.
4. Wait ~2 minutes.

Observed: the daemon logs Collected idle agent runtime, the OS process is killed, and
the background work dies. The agent is not notified in any actionable way; on the next
message it resumes with no knowledge that its background task was terminated. In the UI the
context indicator disappears.

Expected: an agent with in-flight background work is not collected — or, if collection
is unavoidable, the agent is told unambiguously on resume that its background tasks were
terminated.

Where did this happen

Daemon

Paseo version

0.2.2

OS version

ubuntu 2604

Agent provider

Claude Code

Provider configuration

No response

Logs

Screenshots or video

No response

[fennb]

Independent corroboration on 0.2.2 (Generated/diagnosed by Opus 5, Claude Code) — different OS, kernel and Node than the report above — plus a mechanism detail that I think sharpens the diagnosis: a queued inbound notification does not refresh the idle clock, so an agent can be collected with undelivered work already sitting in its queue.

Two collections, traced end to end

Same session, ~20 minutes apart. Times are UTC, correlated between ~/.paseo/daemon.log and the Claude Code session transcript.

Monitor A — a Monitor watching CI, 900 s timeout:

time	source	event
08:42:47.982	transcript	Monitor started (task brsong7wa, timeout 900000ms)
08:43:14.620	transcript	last assistant activity — turn ends, agent goes idle
08:45:18.688	transcript	monitor fires an event → enqueued (no live turn to deliver into)
08:45:19.217	daemon.log	Collected idle agent runtime — 529 ms after the enqueue
09:03:00.864	transcript	next user prompt; orphan scan reports the task stopped

Monitor B — started immediately after, 1500 s timeout:

time	source	event
09:03:50.149	transcript	Monitor started (task brknk6a9a, timeout 1500000ms)
09:03:52.809	transcript	one event delivered fine (turn still live)
09:04:19.783	transcript	last assistant activity — idle
09:06:33.690	transcript	second event → enqueued
09:06:34.334	daemon.log	Collected idle agent runtime — 644 ms after the enqueue
09:13:05.284	transcript	reported stopped on the next prompt

Idle→collect was 2m04.6s and 2m14.6s, consistent with IDLE_AGENT_RUNTIME_TTL_MS of 120 s plus up-to-15 s sweep granularity.

The queue doesn't count as activity

Both reaps land under a second after the monitor pushed an event into the session queue. That isn't coincidence, it's the proof:

isIdleAgentCollectable requires agent.updatedAt.getTime() <= cutoff. At collection A, cutoff = 08:45:19.217 − 120 s = 08:43:19.217. Had the 08:45:18.688 enqueue bumped updatedAt, the agent would have been ineligible by roughly two minutes. It was collected, so updatedAt was still the 08:43:14.620 turn end. Collection B has the same shape (cutoff 09:04:34.334 vs enqueue 09:06:33.690).

So an inbound event arriving for an idle agent neither delivers nor defers collection — the runtime is reaped with unread work in its queue. Worth noting for the fix: lengthening the TTL alone leaves this race intact. Pending queue depth would need to be part of the gate, or the enqueue would need to un-idle the agent.

The loss is reported — but late, and misattributed

Slightly refining "the agent is not notified in any actionable way": there is a notification, generated by Claude Code, but it only fires when the next prompt respawns the runtime — 17m 42s later for A, 6m 31s for B. It reads:

No completion record was found for this background shell command from the previous session. It may have been stopped (via the UI, Monitor timeout, or agent teardown — these leave no transcript marker), or it may have been running when the previous Claude Code process exited.

Every listed cause is plausible and none of them is "the daemon collected the runtime," so the natural reading is that the monitor timed out on its own. It also arrives attached to the resume, which makes the death look like it happened at resume-time rather than ~18 minutes earlier. Diagnosing this from the agent side alone isn't really feasible — it took correlating daemon.log against transcript timestamps to see it.

Environment

@getpaseo/cli / @getpaseo/server	0.2.2
Claude Code	2.1.220
Node	v22.22.3
OS	Ubuntu 24.04.4 LTS, kernel 6.8.0-117-generic

15 Collected idle agent runtime entries in the current daemon.log; 4 of them for this one session (acc8e5c7-…) within about 2.5 hours.

Also confirming the non-OOM angle, since memory pressure is the first place one looks: no kernel OOM-killer invocations, oom_kill zero in every cgroup's memory.events, 2.4 GiB available at the time of the reaps.

Source state

As of e859d2df1 the gate is unchanged from the published 0.2.2 build, clause for clause, and neither constant has an env or config override anywhere in packages/server/src. git log -S traces both constants and isIdleAgentCollectable to a single commit — 99dc8dd (#2203, 2026-07-18), first tagged in v0.2.0-beta.2 — which lines up with the "0.1.110 was fine" datapoint. #2245 addresses the same class of bug (parent idle while background children live) but is scoped to OMP internal subagents, so it wouldn't cover Claude Code background shells or Monitor.

[Mtuchel]

Third data point, and the first on a different provider and OS: omp (Oh My Pi) 17.1.3 on macOS 26.4, Paseo 0.2.1. Same constants, same outcome — so this isn't Claude-Code-specific. omp runs its task subagents as background jobs inside the omp process, so a collected runtime takes every subagent with it.

Adding three things not already in the thread: a minimal repro, the misleading symptom trail this produces for omp users, and a workaround that follows from the code.

Minimal reproduction (~4 minutes, any repo)

mkdir -p /tmp/reaper-probe && cd /tmp/reaper-probe && git init

paseo run --background --provider omp --model deepseek/deepseek-v4-flash --mode full \
  --cwd /tmp/reaper-probe --title "reaper repro" \
  "Use the task tool ONCE to spawn a single BACKGROUND subagent named Sleeper whose task is: run the bash command 'sleep 420' and then reply DONE. Do NOT wait for it. As soon as the task tool returns, reply with exactly: DISPATCHED — then end your turn immediately."

# wait 4 minutes, then:
paseo send <agent-id> "Run the hub tool with op:'jobs' and paste its raw output verbatim, nothing else."

Dispatched 19:13:07Z, collected 19:16:51Z, sleep 420 would not have completed until ~19:20Z. The follow-up prompt returns No background jobs.

Raw daemon line for that run (time 1785093411201 = 2026-07-26T19:16:51Z):

{"level":30,"time":1785093411201,"pid":71436,"hostname":"MacBook-Pro-von-Mirko.local","daemonVersion":"0.2.1","module":"bootstrap","agentId":"f98b6606-ca19-4f90-95b9-dc22f95c7566","provider":"omp","sessionId":"019f9fd8-676b-7000-8e8d-a2dfc9ec9de6","msg":"Collected idle agent runtime"}

The symptom trail sends users the wrong way

Worth knowing for triage, because it cost me several hours. On the omp side a collection leaves this in the provider's own session file:

14:{"type":"custom","customType":"session_exit","data":{"reason":"dispose","kind":"normal","recordedAt":"2026-07-26T19:16:51.096Z"}...
15:{"type":"custom_message","customType":"xdev-mount-notice","content":"<system-notice>\nThe xd:// device inventory changed...

The respawned process re-mounts its tools, which surfaces to the user as a "tool inventory changed" notice arriving at the exact moment the work disappears. In a real session of mine that pattern repeated 11 times, and the obvious-but-wrong conclusion is that the inventory change is what kills the jobs. It's the restart announcing itself. Anyone reporting "tool/MCP inventory changes wipe my background jobs" is most likely hitting this issue.

Workaround that works today

touchUpdatedAt(agent) is called for provider events of type: "timeline" (also appendTimelineItem / emitLiveTimelineItem), so anything that reaches the timeline resets the cutoff. Two practical consequences:

• Keeping the agent inside a tool call while a fan-out runs avoids collection entirely — it's running, not idle, so the sweep skips it.
• A provider that emits a short line periodically while it has background work in flight is never collected mid-wave, and is still collectable once the work drains. I've implemented that on the omp side as a stopgap and it holds.

That second point may also be the cheapest shape for the real fix: rather than plumbing a full background-work count through the provider contract, a provider that is genuinely busy already has a way to say so — it just has to say it, and today nothing tells providers that silence is fatal.

Separately, and only if it's useful to link: #2232 looks like the observability half of the same thing — the parent shows idle/stopped while its subagents are still active. When the runtime is then collected, those subagent rows keep rendering as running, since the terminal event never arrives from a process that no longer exists.

(Logs and repro gathered with an agent; I re-ran the reproduction and reviewed the raw output before posting. Everything above is pasted raw rather than summarised.)

[SilverKnightKMA]

Corroborating on omp 17.x via a scheduled agent (cron, --mode full) — same Collected idle agent runtime kill, but it surfaces here as a scheduled run that aborts immediately on startup rather than mid-work.

Setup

• @getpaseo/cli / server 0.2.1, omp 17.1.x, Linux x86_64
• A cron schedule (0 */12 * * *) targeting --provider omp --model deepseek/deepseek-v4-flash --mode full, prompt is a long-ish runbook (~4 KB) that tells the agent to read a runbook then run two scripts (~13 min of work).
• One schedule target agent, reused per run.

Observed: scheduled runs abort in <2 s

Seven consecutive schedule runs, only 1 succeeded (the second ever run); the rest are killed before doing any work:

Run (UTC)	Messages	Duration	stopReason	Outcome
07-24 12:00 (#1)	4	50 min	toolUse	killed mid-tool (daemon restart, unrelated)
07-25 00:00 (#2)	10	15 min	stop / toolUse	✅ only successful run
07-25 12:00 (#3)	2	<1 s	aborted	❌ Request was aborted, 0 tokens
07-26 00:00 (#4)	2	<1 s	aborted	❌ Request was aborted, 0 tokens
07-26 12:00 (#5)	2	<1 s	aborted	❌ Request was aborted, 0 tokens
07-27 00:00 (#6)	0	<1 s	—	❌ never reached a model call
07-27 07:58 (#7)	0	<1 s	—	❌ never reached a model call

The aborted runs leave exactly this in the omp session transcript (run #5, 2026-07-26T12-00-39-944Z):

{"type":"message","message":{"role":"assistant","model":"cli-openai/fci/deepseek-v4-flash",
  "stopReason":"aborted","errorMessage":"Request was aborted",
  "usage":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"totalTokens":0}}}

createdAt → updatedAt for the failed runs is ~20 ms. The in-flight HTTP request to the model provider is aborted before the assistant produces a single token — the session file just records the abort and closes.

This is the idle-GC, not the provider

Cross-referencing ~/.paseo/daemon.log against the omp session ids, every failed scheduled run lines up with a Collected idle agent runtime entry for the same session id within the run window. The clearest one, run #7 (019fa295-28b3-7000-9ec2-dbaae912003d, a schedule target):

{"level":30,"time":…,"module":"bootstrap",
 "agentId":"f27cac4d-4e26-4cea-9c0c-f2201fcc2d85","provider":"omp",
 "sessionId":"019fa295-28b3-7000-9ec2-dbaae912003d",
 "msg":"Collected idle agent runtime"}

provider":"omp" in 29 of the current log's collection lines. The kill lines up with the abort in the transcript.

The schedule-target exemption isn't protecting these runs

This is the part I think is worth adding to the thread, because it's a shape the existing reports don't quite cover:

isIdleAgentCollectable exempts scheduleService.listActiveAgentTargetIds(), so a schedule target should be uncollectable. But my schedule-target agent is being collected anyway, within seconds of the schedule firing it. Two of the seven runs (#6, #7) produced zero messages — the omp process never logged a model call at all before the GC reaped it.

That points at a race in the exemption wiring rather than the 2-minute TTL itself: either the runtime is spawned and becomes collectable before its agent id lands in listActiveAgentTargetIds(), or the "resumed from persistence" path (which I see 30× in the same log) creates a window where the agent is idle-but-not-yet-protected. The success of run #2 and the total failure of every run since is consistent with the exemption being racy rather than absent.

Misleading symptom trail (same as @Mtuchel)

The first thing I chased was the xd:// device inventory changed notice that arrives at abort time — I spent a while convinced the tool re-mount was what killed the run, exactly the trap described in the omp comment. It's the respawn announcing itself, not the cause. Worth flagging again because for scheduled runs there's no human watching, so the only signal is "No activity to display" and a 0-token aborted assistant turn — which reads like a no-op run, not a GC kill.

Workaround status

The touchUpdatedAt workaround from the omp comment (provider emits a timeline line to reset the cutoff) doesn't help scheduled runs, because the abort happens before the provider gets to emit anything — runs #6/#7 never reached a model call. So for the schedule case there's no user-side workaround short of pinning the agent id into the protected set manually, which the schedule API doesn't expose.

Happy to paste raw daemon.log excerpts or the schedule config if useful. Confirming this is real on 0.2.1 + omp, scheduled targets, not just Claude Code background work.

[padenj]

Fourth data point: same class of bug, but on the Copilot CLI provider, and the collected background work is a dev server process the agent launched itself (not a Monitor, background Bash task, or omp subagent). So the reaper takes down arbitrary long-lived child processes an agent starts, not just paseo/provider-native async primitives.

Environment

@getpaseo/cli / @getpaseo/server	0.2.2
Agent provider	GitHub Copilot CLI (--acp --autopilot --yolo)
Node	v24.13.0
OS	Ubuntu 24.04.4 LTS, kernel 6.14.11-4-pve (LXC/Proxmox), daemon in a linuxserver/code-server Docker container

Symptom

Asked the Copilot agent to start a project's dev server (a plain long-running Node process, no Monitor, no explicit background-task API, just started as a normal child process and left running). It started fine, ran for a few minutes, then died to SIGTERM. The agent itself had no visibility into why. From its side: "the background-job wrapper... [is] cleaning up the detached job... the exact trigger is outside the repo and isn't exposed to me," which matches this issue's description of the loss being unattributable from the provider side.

Confirming this is the same GC, not the provider

daemon.log shows the same "msg":"Collected idle agent runtime" pattern for provider":"copilot" sessions, repeating on the ~2-minute-post-idle cadence already documented above, e.g.:

{"time":1785117098774,"daemonVersion":"0.2.2","module":"bootstrap","agentId":"a85c235f-...","provider":"copilot","sessionId":"3eb5d94f-...","msg":"Collected idle agent runtime"}
{"time":1785120128786,"daemonVersion":"0.2.2","module":"bootstrap","agentId":"a85c235f-...","provider":"copilot","sessionId":"3eb5d94f-...","msg":"Collected idle agent runtime"}

Note on scope

This now spans Claude Code, omp, and Copilot CLI, and the collected work spans Monitors, background Bash, omp subagents, and plain unmanaged child processes (dev servers). The hasBackgroundWork() signal proposed in the original report probably needs to be provider-agnostic at the OS-process level (does this agent have live descendant processes besides its own shell) rather than something each provider integration has to opt into individually. Otherwise every provider will need its own fix as this keeps getting rediscovered per-provider.

Workaround in place

Pinned @getpaseo/cli to 0.1.110 (last version before the idle-GC was introduced in 99dc8ddd / #2203) until this is resolved.

[boudra]

Resolved by #2590. Time-based idle runtime collection is being removed entirely, so idle agents remain resident until an explicit lifecycle action terminates them.

[boudra]

We have removed idle agent runtime garbage collection in #2590. Getting time-based collection right without interrupting background work, losing session state, or introducing lifecycle races proved disproportionately complex. Idle agents will now remain resident until an explicit lifecycle action closes, archives, replaces, reloads, or otherwise terminates them. This removes the source of the failure reported here.