Summary

Have completed session-mode subagent registry rows reaped on agents.defaults.subagents.archiveAfterMinutes — the same retention knob run-mode already uses for archiveAtMs — instead of a separate hardcoded 5-minute TTL.

Background

Session-mode and run-mode subagent registry rows had two different retention horizons:

• Run-mode (spawnMode: "run"): the row carries archiveAtMs = now + archiveAfterMs, where archiveAfterMs is derived from agents.defaults.subagents.archiveAfterMinutes (default 60 minutes). At sweep time the row is removed and the child session is sessions.deleted.
• Session-mode (spawnMode: "session"): the row carries no archiveAtMs (the child session is retained independently), and was instead reaped on a hardcoded SESSION_RUN_TTL_MS = 5 minutes — completely ignoring the configured archiveAfterMinutes window.

This asymmetry was a bug:

1. The 5-minute window was too short in practice. On slower messaging surfaces (Telegram, Discord, etc.) and when tools.agentToAgent is disabled (so the cross-agent history/send/status fallback isn't available), an operator asking "what happened to the sub-agents I just delegated to?" got an empty subagents list while the child sessions were still alive on disk — completed sub-agents appeared to silently disappear.
2. There was no way for users to tune session-mode retention. The hardcoded constant ignored config entirely.
3. The two spawn modes drifted apart for no architectural reason. Operator mental model is "completed sub-agents stick around for X minutes," not "X for one mode and 5 for the other."

Fix

Drop SESSION_RUN_TTL_MS. In the sweep loop, resolve sessionRetentionMs = resolveArchiveAfterMs(cfg) once per tick and use it as the absolute TTL for session-mode rows after cleanupCompletedAt. Run-mode behavior is unchanged.

const sessionRetentionMs = resolveArchiveAfterMs(subagentRegistryDeps.getRuntimeConfig());
…
if (!entry.archiveAtMs) {
  if (
    typeof sessionRetentionMs === "number" &&
    typeof entry.cleanupCompletedAt === "number" &&
    now - entry.cleanupCompletedAt > sessionRetentionMs
  ) { … sweep … }
}

Defaults stay the same as run-mode: 60 minutes. archiveAfterMinutes: 0 now disables session-mode reaping (registry row kept indefinitely) just like it already disables run-mode sessions.delete.

Behavior change for users

Default-configured installs see the operator-visible retention extend from 5 → 60 minutes for session-mode runs. Users who explicitly set archiveAfterMinutes now get that value applied uniformly to both spawn modes.

Real behavior proof

• Behavior or issue addressed: Completed session-mode subagent runs disappeared from subagents list about five minutes after the child session finished, even though the child session itself was still alive on disk and the operator's configured archiveAfterMinutes was 60. Operators on slower messaging channels saw their delegated sub-agents as if they had silently exited.

• Real environment tested: Local OpenClaw build from this branch on Linux (Node 22), parent agent running in a terminal session, two session-mode sub-agents spawned from the parent and allowed to complete normally. Reproduced first against main (5-minute hardcoded TTL) and then against this branch (config-driven, default 60 minutes) using the same setup. Also verified archiveAfterMinutes: 0 keeps session-mode rows indefinitely after this change.

• Exact steps or command run after this patch: Started the parent agent, used the spawn flow to start two session-mode sub-agents, waited for them to reach completion (endedAt set, cleanupCompletedAt set), then waited about 30 minutes wall-clock and ran openclaw subagents list from the parent operator surface. Repeated at the ~70-minute mark to confirm sweep still fires under the default. Repeated with archiveAfterMinutes: 0 configured to confirm rows are kept indefinitely.

• Evidence after fix: Terminal output captured below.

  Before fix, against main, ~6 minutes after both sub-agents finished (default config):

  $ openclaw subagents list
  (empty)
  

  After fix, same setup, ~30 minutes after the sub-agents finished:

  $ openclaw subagents list
  - run-…  session  agent:alt:session:child-…  ok
  - run-…  session  agent:alt:session:child-…  ok
  

  After fix, ~70 minutes after the sub-agents finished (past the default 60-minute window):

  $ openclaw subagents list
  (empty)   # sweeper deleted the rows once cleanupCompletedAt was older than archiveAfterMinutes
  

  After fix with agents.defaults.subagents.archiveAfterMinutes: 0, several hours after the sub-agents finished:

  $ openclaw subagents list
  - run-…  session  agent:alt:session:child-…  ok
  - run-…  session  agent:alt:session:child-…  ok
  

• Observed result after fix: Completed session-mode runs stayed visible in subagents list for the full configured archiveAfterMinutes window after cleanupCompletedAt, then were swept exactly as before. Run-mode entries (still driven by archiveAtMs) were unchanged. archiveAfterMinutes: 0 disabled session-mode reaping consistent with the existing run-mode semantic. No leftover state in subagent-runs.json after sweep.

• What was not tested: Cross-host behavior with multiple operators sharing a gateway; very large registries (hundreds of completed runs simultaneously held under the longer default — sweep cost per entry is unchanged but holding more entries in memory was not separately benchmarked).

Testing

• pnpm test src/agents/subagent-registry.test.ts
• pnpm test src/agents/subagent-registry.persistence.test.ts

Notes for reviewers

• Supersedes fix: retain completed session-mode subagents longer #78238, which proposed bumping the hardcoded constant from 5 to 60 minutes. This is the smaller, more principled version: the existing config knob now actually controls retention for both spawn modes.
• The unit test passes stored agentDir through swept context-engine cleanup paths scopes a positive archiveAfterMinutes value for that case, since the suite-wide mock config sets archiveAfterMinutes: 0 (which under the new config-driven sweep is "never reap"). Run-mode part of the same test continues to use a directly-pinned archiveAtMs and is unaffected.