[bug] Subagent catalog cold reads replay full session logs and cause sustained high CPU

[aphelioussss-gif]

Summary

With a large number of persisted sessions and durable subagents, opening the DSH Web UI can keep the dsh web Node process near one full CPU core for an extended period. On my machine this caused visible thermal load even while the browser UI itself was relatively quiet.

The hot path appears when dsh-subagent resolves cold child identities. If the fast cachedSnapshot() check is not usable, resolveColdIdentity() falls directly back to sessionPersistence.inspect(), which reads/decompresses the full JSONL/Zstd log and rebuilds every registered projection.

A local canary that tries sessionProjectionCache.coldSnapshot() before persistence.inspect() removed the sustained thermal/CPU problem in my environment.

Environment

• DSH: 0.1.0-rc.6
• macOS: 15.7.3, Apple Silicon
• Node.js: 22.23.1
• UI: dsh web on 127.0.0.1:3080
• Persisted projection cache: about 145 session records, including about 97 real subagent records

Symptoms

• node .../dsh web sustained roughly 74% to 136% CPU
• Physical footprint around 1.5 GB during diagnosis
• Laptop became noticeably warm soon after opening/using the Web UI
• Disabling skill-filesystem watching did not resolve the high CPU
• The symptom predated installation of a custom sidebar plugin

Profiling evidence

An 8-second Node Inspector CPU profile attributed inclusive sample cost approximately as follows:

• session persistence / log decoding: 49.8%
• session core reconstruction: 27.2%
• subagent catalog resolution: 15.1%
• token meter: 6.3%
• local memory plugin: 2.9%

Representative call path:

subagents.list
  -> resolveCandidateRows
  -> resolveColdIdentity
  -> sessionPersistence.inspect
  -> prepareCore
  -> session-persistence-jsonl.loadStored/readZstdPrefix
  -> sessionProjection.restore

A breakpoint on session-persistence-jsonl.loadStored() confirmed calls through prepareCore() from inspect() while resolving cold subagent identities.

Relevant code

Current behavior in dsh-subagent:

const cached = cache.cachedSnapshot(header)?.values.subagent
if (cached && cached.seq >= (header.seedLength ?? 0)) {
  return childRow(childId, cached, "inactive", hasChildren)
}

// Falls directly to a full stored-session inspection.
const inspected = await persistence.inspect(childId, signal)
const identity = projections.restore({}, inspected.events, 0).snapshot.values.subagent

There is already a projection-cache API designed for this case: sessionProjectionCache.coldSnapshot(id, signal). It can reuse a durable checkpoint, replay only the missing suffix, and write the refreshed checkpoint back.

Local canary

I inserted the following path before the full persistence.inspect() fallback:

if (cache !== undefined) {
  try {
    const refreshed = await cache.coldSnapshot(childId, signal)
    const identity = refreshed.values.subagent
    if (identity !== undefined && identity !== null) {
      return childRow(childId, identity, "inactive", hasChildren)
    }
  } catch {
    assertListingNotCancelled(signal)
  }
}

After restarting dsh web, the previously sustained heating/high-CPU behavior disappeared in normal use.

Expected behavior

Cold subagent listing should use the durable projection cache and tail replay path. Full log inspection and full projection reconstruction should be the final fallback for an unavailable or corrupt projection cache.

The default prepared-session cache size is only 5, so increasing that value may reduce churn temporarily but will not scale well to 100+ durable subagents. A projection-first listing path should keep catalog work proportional to lightweight metadata and missing event tails rather than total historical log size.

Suggested change

In resolveColdIdentity():

1. Keep the existing cachedSnapshot(header) fast path.
2. On a stale or absent usable snapshot, try cache.coldSnapshot(childId, signal).
3. Use persistence.inspect() plus a full projection restore only when the projection cache is unavailable, fails, or cannot produce a subagent identity.
4. Preserve cancellation and lifecycle validation semantics.

I can provide a focused patch or additional CPU profiles if helpful.