Summary

FileBrowser's kind: 'folder' sections (Memory, Config on AgentOutputTab) are drawn by filtering useFileTree's rows for a path prefix (sectionRows.get(sec.path) in FileBrowser.tsx). Nothing ever populated rows with a section's children:

• autoExpandDepth explicitly excludes sections , AgentOutputTab's own comment: "The sections are untouched by this: Memory and Config stay shut."
• A section's onToggle handler (toggleSection(sec.path)) only flips a local visibility boolean; it never calls expand(), the only mechanism that adds a folder id to useFileTree's expandedIds.

So a real, non-empty, fully accessible Config or Memory folder rendered as permanently empty , with zero network requests fired when a user clicked to expand it, since nothing was ever wired to fetch it in the first place.

How this was found

Verified end-to-end against live production data for a real customer's coaching agent before writing any code:

• getAgentOutputs (server), called directly with the real org/user/agent ids, returned 5 real documents under byNamespace.config.
• listChildren (server), called directly with the real Config folder's document id as parentId, returned the same children correctly.
• The browser network tab confirmed the X-Admin-View-User header was correct on every request, and that expanding the Config folder fired no new network request at all , directly confirming nothing was wired to fetch it, rather than an access or data problem.

Fix

Added sectionPaths to useFileTree's options:

1. Resolve each section root's document id from the tree's own root listing (already fetched for every tree , no extra query needed for this step).
2. Recursively include every folder found beneath a section root in an eager fetch+walk set (eagerFolderIds), grown one level per settled query , the same incremental shape rootChain already uses for resolving rootPath's ancestry, but as a set rather than a chain, since a section can branch (e.g. config/templates sits beside config/playbook).
3. walk() treats an id in eagerFolderIds as expanded unconditionally, so a section's full subtree , however deep , surfaces in rows without anyone clicking it open.
4. isLoading now also accounts for a section's fetch still being in flight, so a section doesn't flash empty before its query resolves.

Ordinary (non-section) folders are untouched: still lazy, one files.listChildren query per manual expand, exactly as before. FileBrowser.tsx's existing prefix-based grouping into sectionRows is unchanged , it just now has real data to filter.

Test plan

• New test file (useFileTree.sectionPaths.test.tsx) exercises the real hook (not mocked, unlike every existing test that touches useFileTree) with a mocked tRPC client returning per-parentId fixtures. Confirms: a section's children (including a nested two-levels-deep folder) appear in rows without ever calling expand; an ordinary folder stays lazy; omitting sectionPaths entirely reproduces the original behavior unchanged.
• All existing tests touching this code still pass unchanged: fileBrowserAdminView.test.tsx, playbookFileTree.test.tsx, AgentOutputTab.test.tsx, AgentFileBrowserSelection.test.tsx, AgentViewLayout.test.tsx (47 tests, all green).
• pnpm --filter @zero/mail run types , zero errors in either touched file (pre-existing failures in this fresh worktree are all missing generated code , @/paraglide/*, react-router +types , unrelated to this change).
• eslint on both touched files , clean (one pre-existing, unrelated warning in FileBrowser.tsx predates this change, confirmed via git blame).

🤖 Generated with Claude Code