Best possible solution:

Land a request-scoped registry read context if CI remains green and maintainers are comfortable with the snapshot boundary; keep it scoped to one sessions.list/read operation and avoid hoisting it into global cache state.

Do we have a high-confidence way to reproduce the issue?

Yes. The current-main reproduction path is code-level: sessions.list spawnedBy filtering and row enrichment call registry snapshot-backed helpers repeatedly, and the PR adds a focused fs.statSync-based regression test for the repeated disk snapshot case.

Is this the best way to solve the issue?

Yes, likely. A per-request context is the narrowest maintainable optimization because it avoids global caching or persistence changes while preserving the existing direct row fallback behavior.

What I checked:

• Current main still uses per-call helpers in sessions.list: On current main, listSessionsFromStore and buildGatewaySessionRow call getSessionDisplaySubagentRunByChildSessionKey, countActiveDescendantRuns, and listSubagentRunsForController directly rather than sharing a request-scoped context. (src/gateway/session-utils.ts:1660, 099037cca6f5)
• Current registry read helpers snapshot on each call: The current read facade wraps getSubagentRunsSnapshotForRead inside each exported query helper, which matches the repeated snapshot/stat work the PR is trying to reduce. (src/agents/subagent-registry-read.ts:23, 9d68c6768ae2)
• PR introduces request-scoped context: The patch adds SubagentRegistryReadContext plus createSubagentRegistryReadContextFromRuns/createSubagentRegistryReadContext and uses the context for controller listing, display lookup, and active descendant counts. (src/agents/subagent-registry-read.ts:21, 2bf9f982fb8d)
• PR threads context through Gateway row construction: The patch passes one lazy getSubagentRegistry() result through spawnedBy filtering and buildGatewaySessionRow, while preserving direct one-row loads by creating a context only when no context is supplied. (src/gateway/session-utils.ts:1628, 2bf9f982fb8d)
• Regression coverage added: The PR adds parity tests for the new read context and Gateway tests that assert one registry stat for a spawnedBy listing and no registry read when raw filters drop all rows. (src/agents/subagent-registry-read-context.test.ts:1, 2bf9f982fb8d)
• CI status snapshot: GitHub check-runs for the PR head showed 63 successes, 12 skipped, 1 neutral CodeQL result, 6 in progress, and only auto-response cancelled at review time. (2bf9f982fb8d)

Likely related people:

• @steipete: Recent commits touched both Gateway session list behavior and shared subagent registry query helpers, including the slice-1 session-list enrichment optimization and registry query helper refactor. (role: recent maintainer and central feature owner; confidence: high; commits: 9402bca614d0, 3b2db583cdb1, 757aee4cdd5d; files: src/gateway/session-utils.ts, src/agents/subagent-registry-read.ts, src/agents/subagent-registry-queries.ts)
• @Takhoffman: History for the subagent registry query path includes fixes for restarted descendant counts and moved child sessions, which are semantics this PR explicitly preserves in the indexed context tests. (role: adjacent subagent traversal owner; confidence: medium; commits: c541cde0f66e, e48a0b80a81b; files: src/agents/subagent-registry-queries.ts, src/gateway/session-utils.subagent.test.ts)
• @ZiPengWei: Recent merged work touched subagent recovery and session state reconciliation around the registry read files affected by this PR. (role: recent subagent registry maintainer; confidence: medium; commits: 845040214e13; files: src/agents/subagent-registry-read.ts, src/agents/subagent-registry-state.ts)

Remaining risk / open question:

• Some PR check runs were still in progress at review time, so final merge readiness depends on the completed CI set.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 099037cca6f5.