Summary

Keeps completed session-mode subagent registry rows visible for 60 minutes (was 5) so subagents list and other registry-backed status surfaces still show the run when an operator asks shortly after the child session finishes.

Background

This came up in an OpenClaw setup where a parent agent was delegating to session-mode sub-agents during a longer project. From the operator's perspective the sub-agents were "silently exiting": the child sessions were still on disk and reachable, but subagents list returned nothing, so the parent flow looked like it had lost its workers.

Root cause: SESSION_RUN_TTL_MS in src/agents/subagent-registry.ts was 5 minutes after cleanupCompletedAt. The sweeper was deleting completed session-mode registry entries before a human could reasonably ask for status on a slower messaging surface (Telegram, Discord, etc.), or when tools.agentToAgent is disabled and the cross-agent history/send/status fallback isn't available.

The fix is the minimal one: extend the post-cleanup TTL on session-mode runs from 5 minutes to 60 minutes. Behavior for run-mode entries (which use archiveAtMs) is unchanged. Sweeping still happens, just at a window long enough to be useful for "what just happened?" questions.

Changes

• src/agents/subagent-registry.ts: bump SESSION_RUN_TTL_MS from 5 * 60_000 to 60 * 60_000, with an inline comment explaining the user-visible reasoning.
• src/agents/subagent-registry.test.ts: update the swept-context-engine fixture from 6 minutes past cleanupCompletedAt to 61 minutes so the existing sweep proof still exercises the deletion path under the new TTL.
• CHANGELOG.md: add an Unreleased Fixes entry under the active version.

Why this matters

When tools.agentToAgent is disabled, operators can't fall back to cross-agent history/send/status tools, so the subagent registry is the primary source of truth for subagents list. Retaining completed runs for an hour makes the subagent flow inspectable after the fact and matches operator expectations on slower channels.

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. 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 TTL) and then against this branch (60-minute TTL) using the same setup.

• 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.

• Evidence after fix: Terminal output captured below.

  Before fix, against main, ~6 minutes after both sub-agents finished:

  $ 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 new TTL):

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

• Observed result after fix: Completed session-mode runs stayed visible in subagents list for the full 60-minute window after cleanupCompletedAt, then were swept exactly as before. No change to run-mode entries (still driven by archiveAtMs), no leftover state in subagent-runs.json after sweep. Matches the unit-test sweep fixture, which was bumped from now - 6 * 60_000 to now - 61 * 60_000 and continues to assert deletion.

• What was not tested: Cross-host behavior with multiple operators sharing a gateway; very large registries (hundreds of completed runs simultaneously held for the longer TTL — the sweep cost is unchanged per entry 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

• The branch was previously based on a stale main and carried already-merged changes from fix(openai-codex): honor providerConfig.baseUrl in dynamic-model synthesis fallback #76428 (codex baseUrl synthesis fallback). Rebased onto current main; those commits dropped automatically as patch contents already upstream. The branch is now a single commit touching only the subagent files plus one Changelog entry.