feat(sessions): progressive loading, server-side search, and workspace scoping

[VooDisss]

Session Pagination & Search Enhancement

Changes

Progressive Session Loading

• fetchSessions() now accepts { limit, search } options
• Added pagination state: sessionFetchLimit, sessionHasMore (50-session pages)
• Scroll-to-bottom sentinel triggers loadMoreSessions() via IntersectionObserver
• Hydration loads initial 50 sessions; subsequent scrolls fetch 100, 150, etc.

Server-Side Search

• Added searchSessions() using session.list({ search, limit: 50, directory })
• Merges results into store (preserves active session, no replacement)
• Added "sessionList.loading.more" i18n key (7 locales)

Hybrid Search Performance

• Client-side filtering runs first — instant results for loaded sessions
• Server search only fires when no client matches exist
• Debounce reduced from 300ms → 150ms for server fallback

Workspace Scoping

• All session.list() calls pass directory: instance.folder
• Prevents cross-workspace session pollution

Files

• packages/ui/src/stores/session-state.ts
• packages/ui/src/stores/session-api.ts
• packages/ui/src/stores/instances.ts
• packages/ui/src/stores/sessions.ts
• packages/ui/src/components/session-list.tsx
• packages/ui/src/lib/i18n/messages/*/session.ts

[VooDisss]

Before vs After

Aspect	Before	After
Session loading	Fetches all sessions once, capped at 100 by server default	Fetches 50 initially, auto-loads 100, 150, 200... on scroll
Scroll behavior	Nothing — user sees max 100 sessions and thinks rest are missing	IntersectionObserver sentinel auto-fetches more when near bottom
Search scope	Client-side only among loaded sessions	Server-side across workspace, merged into store
Search API call	None — pure client filter	session.list({ search, limit: 50, directory }) with fallback
Search debounce	N/A (no server search)	150ms server fallback; instant for client matches
Active session on search	Disappears if not in search results (store replacement)	Preserved (merge-into-store semantics)
Cross-workspace leak	session.list() without directory returned sessions from ALL workspaces	directory: instance.folder scopes to current workspace
Single-letter freeze	"a" returned 200+ cross-workspace results, froze UI	"a" returns ≤50 workspace results; client-side shows instantly
"Resume Session" snap	Active session lost → main view switched to welcome screen	Active session stays in store → chat view remains
Session count accuracy	Hardcoded 100 limit hid true count	Progressive loading reveals true count naturally
Mobile UX	Same 100-session limit, no pagination	Scroll-to-bottom works naturally on mobile

[pascalandr]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Gatekeeper review for latest PR state. Assumption: the checked-out worktree reflects PR #511 HEAD, and the request is for review only, not code changes.

Verdict: changes requested / not ready to merge.

Findings:

1. Search is not actually workspace-complete once any loaded session matches.
   packages/ui/src/components/session-list.tsx:131-140
   The server search only runs when client-side filtering finds zero matches. If the query matches one of the first 50 loaded sessions, the server is never queried, so matching older/unloaded sessions remain hidden indefinitely. That contradicts the stated “server-side across workspace” behavior and creates a very easy false-negative search path. Better implementation: keep instant client filtering for responsiveness, but still debounce a server search for every non-empty query; merge/dedupe returned sessions and guard against stale query responses.

2. An existing refresh path bypasses pagination and can permanently disable load-more.
   packages/ui/src/App.tsx:408 calls fetchSessions(instanceId) with no limit. In the new fetchSessions, limit is undefined, so setInstanceSessionHasMore(instanceId, false) is reached via const hasMore = limit ? ... : false at packages/ui/src/stores/session-api.ts:160-161. After closing a session, this can refresh using the server default page and then hide the sentinel, leaving additional sessions unreachable. This path should use the current pagination limit or reset/refetch with the page size consistently.

3. Child-only search results can be merged but never rendered.
   packages/ui/src/stores/session-api.ts:294-325 merges every returned search session directly into the session map. getSessionThreads() only renders sessions whose parentId === null as thread roots and attaches children only if their parent is already present (packages/ui/src/stores/session-state.ts:539-583). If the API returns a matching child session without its parent, the result is silently invisible. Search needs to either hydrate missing parents, fetch the parent/thread family, or otherwise guarantee/render orphaned child results.

4. Search result merging can erase existing per-session UI/runtime fields.
   packages/ui/src/stores/session-api.ts:300-319 overwrites existing sessions but only preserves a subset of fields (agent, model, status, retry, idleSince). It drops fields that toClientSession() preserves, such as diff, pendingPermission, and pendingQuestion (packages/ui/src/stores/session-api.ts:335-361). If a search result contains an existing active session with pending input or cached diff state, the merge can clear UI indicators/cache state. Use the shared toClientSession() mapping or preserve all existing runtime fields explicitly.

Implementation quality notes:

• The cumulative limit pagination approach is simple but increasingly wasteful: loading 50, 100, 150, 200 re-downloads earlier pages each time. Acceptable for small counts, but not a scalable pagination implementation. If the SDK supports cursor/offset, use it; if not, keep this documented as a server API limitation.
• packages/ui/src/components/session-list.tsx is now ~928 lines, above the project’s source-file warning threshold. I would not block solely on that, but this PR adds more stateful async behavior into an already oversized component.
• There is an unrelated dirty worktree file: .opencode/package-lock.json. I did not inspect or modify it.

Validation:

• Ran npm run typecheck --workspace @codenomad/ui, but it could not provide a meaningful result because dependencies are not installed in this worktree (Cannot find module 'solid-js', @opencode-ai/sdk, etc.).

Recommended bar before merge:

• Make server search complete for every non-empty query while retaining instant client results.
• Fix all fetchSessions() callers so pagination state is not bypassed.
• Ensure search results render correctly for child sessions and preserve existing runtime session fields.
• Add focused tests or a documented manual test matrix for: query with partial loaded matches, query matching only unloaded sessions, query matching child-only sessions, clearing search, closing a session after progressive loading, and preserving active/pending session state during search.

--
Yours,
CodeNomadBot

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/26645371000

Artifacts expire in 7 days.
Artifacts:

• pr-511-3894f6fdae8088be2c80ca782e87c73081a3541b-tauri-macos
• pr-511-3894f6fdae8088be2c80ca782e87c73081a3541b-tauri-linux
• pr-511-3894f6fdae8088be2c80ca782e87c73081a3541b-tauri-windows
• pr-511-3894f6fdae8088be2c80ca782e87c73081a3541b-electron-macos
• pr-511-3894f6fdae8088be2c80ca782e87c73081a3541b-tauri-macos-arm64
• pr-511-3894f6fdae8088be2c80ca782e87c73081a3541b-electron-windows
• pr-511-3894f6fdae8088be2c80ca782e87c73081a3541b-electron-linux

[VooDisss]

@pascalandr I want you to perform the gatekeeper checks for latest PR state

Commit: f938c96b

Fix	File	What Changed
001 Search completeness	session-list.tsx	Removed hasClientResults gate. Server search always runs in background (150ms debounce). Stale query guard (queryAtDispatch) ignores superseded responses.
002 Pagination bypass	session-api.ts	fetchSessions only sets hasMore when limit is explicitly provided. App.tsx close-session refresh no longer hides the sentinel.
003 Child results	session-api.ts	After search merge, scans for children whose parent is missing. Fetches each missing parent via session.get() and adds to store.
004 Field preservation	session-api.ts	Replaced manual merge with toClientSession(instanceId, apiSession, existingSession) — preserves diff, pendingPermission, pendingQuestion, revert, etc.

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/26648733114

Artifacts expire in 7 days.
Artifacts:

• pr-511-f938c96bd61fb4d5e401b1d4c93b1345d795ec05-tauri-macos
• pr-511-f938c96bd61fb4d5e401b1d4c93b1345d795ec05-tauri-linux
• pr-511-f938c96bd61fb4d5e401b1d4c93b1345d795ec05-tauri-windows
• pr-511-f938c96bd61fb4d5e401b1d4c93b1345d795ec05-tauri-macos-arm64
• pr-511-f938c96bd61fb4d5e401b1d4c93b1345d795ec05-electron-macos
• pr-511-f938c96bd61fb4d5e401b1d4c93b1345d795ec05-electron-windows
• pr-511-f938c96bd61fb4d5e401b1d4c93b1345d795ec05-electron-linux

[shantur]

@CodeNomadBot

check again

[codenomadbot]

Re-check complete for latest PR state at f938c96b. Assumption: this worktree reflects PR #511 HEAD. Request understood as a gatekeeper re-review after the claimed fixes.

Verdict: still changes requested / not ready to merge.

Findings:

1. Close-session refresh still bypasses the pagination contract and can drop loaded sessions.
   packages/ui/src/App.tsx:408 still calls fetchSessions(instanceId) with no limit. The latest fix avoids immediately setting hasMore=false for an unbounded fetch (packages/ui/src/stores/session-api.ts:155-163), but it does not solve the real state-consistency problem: fetchSessions() replaces the whole instance session map with whatever the server default returns (packages/ui/src/stores/session-api.ts:220-223). If the user has progressively loaded 150+ sessions, or has already reached the end, closing a session can replace the store with the default page and leave sessionFetchLimit / sessionHasMore describing a different dataset. Worst case: user loaded all sessions, hasMore=false, close one session, store is replaced by the server default subset, and the sentinel remains hidden, making the omitted sessions unreachable. This caller should use the current pagination limit or explicitly reset pagination and fetch the page size.

2. In-flight search responses are not actually guarded against stale queries and can corrupt pagination after search is cleared.
   packages/ui/src/components/session-list.tsx:135-145 only guards clearing the local isSearchFetching flag. It does not stop searchSessions() from merging stale results or mutating global pagination state. searchSessions() unconditionally calls setInstanceSessionHasMore(instanceId, false) for both empty and non-empty results (packages/ui/src/stores/session-api.ts:291-293, packages/ui/src/stores/session-api.ts:340-341). Repro shape: type a query, let the request start, clear the query, the clear path refetches paginated sessions, then the old search response returns and sets hasMore=false. The normal list can now hide the load-more sentinel even when more sessions exist. The stale-query guard needs to be applied before committing search results/global pagination state, not only before clearing a local loading flag.

Previously reported items status:

• Server search now runs for every non-empty query rather than only when client matches are empty. That addresses the original completeness gate, subject to the stale-response issue above and the intentional limit: 50 cap.
• Search merging now uses toClientSession(), so the specific runtime-field loss from the previous version is addressed.
• Child-only search results now attempt to fetch missing parents. That addresses the invisible-child issue for the common case where session.get({ sessionID }) can retrieve the parent.

Implementation quality notes:

• isSearchFetching is currently written but not read anywhere in session-list.tsx. That is not a merge blocker by itself, but it is dead state in already complex async UI logic.
• packages/ui/src/components/session-list.tsx remains oversized at ~921 lines, above the project warning threshold. Not a blocker alone, but it increases the risk of this stateful pagination/search logic regressing.

Validation:

• Ran npm run typecheck --workspace @codenomad/ui; it still cannot produce a meaningful validation result in this worktree because dependencies are missing (solid-js, @opencode-ai/sdk, etc.). The output also surfaces PR-area TypeScript errors around the new searchSessions map updates, but with missing dependency types the result is too noisy to classify confidently here. CI/build artifacts should be treated as the source of truth for compile status.

Required before merge:

1. Fix all fetchSessions() callers so pagination state and the stored dataset cannot diverge.
2. Add a real stale-search guard/cancellation mechanism so old search responses cannot mutate sessions or sessionHasMore after the query changes or clears.
3. Manually verify the race cases: close session after loading past the first page, close session after reaching the end, clear search while a server search is in flight, and rapidly type two different queries with out-of-order responses.

--
Yours,
CodeNomadBot

[shantur]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Gatekeeper review complete for latest PR state at 19457f25. Assumption: this worktree reflects PR #511 HEAD. Request understood as a fresh ruthless review for regressions and implementation quality.

Verdict: changes requested / not ready to merge.

Findings:

1. Server-search failures can hide valid loaded client-side matches.
   packages/ui/src/stores/session-api.ts:351-353 and packages/ui/src/components/session-list.tsx:154-158
   The component correctly shows instant client-side filtered results while the server search is loading. But if searchSessions() fails, the catch path calls setSessionSearchResults(instanceId, trimmedQuery, [], requestId), marking the current search as complete with zero results. Because filteredThreads() switches to getSessionSearchThreads() whenever searchQuery === query && !searchLoading, a transient server/API failure replaces real loaded matches with an empty list. That is a regression from the intended hybrid behavior: server search should enhance client results, not make existing local results disappear on failure. Better implementation: on search error, clear/ignore the search state for that request and keep client-side filtering active, or track an error state separately without returning empty authoritative results.

2. Child-only search results still depend on best-effort parent hydration with no fallback.
   packages/ui/src/stores/session-api.ts:316-344 and packages/ui/src/stores/session-state.ts:693-704
   The latest version improves this by fetching missing parents, but if session.get({ sessionID: parentId }) fails, the matching child remains in resultIds while getSessionSearchThreads() can only render it through its parent root. buildSessionThreads() then skips the result because the parent is absent. That means a valid server search result can still be silently invisible under a partial API failure. This is less severe than the previous version, but a gatekeeper-quality implementation needs a fallback: either include an orphan/result row shape, retry/hydrate the full family, or do not mark the search complete as authoritative until required parents are available.

Previously reported blocker status:

• The close-session refresh issue is substantially addressed: App.tsx now calls fetchSessions(instanceId, { start: 0, limit: getSessionFetchLimit(instanceId) }) instead of an unbounded fetch.
• Stale search response handling is substantially improved: search state now uses requestId checks before committing final search results.
• Search and pagination state are now separated, which is a better direction than mutating sessionHasMore from search.
• Search result merging still uses toClientSession(), preserving runtime fields such as diff, pendingPermission, and pendingQuestion.

Implementation quality notes:

• The PR description still says 50-session pages, but SESSION_PAGE_SIZE is now 100 in packages/ui/src/stores/session-state.ts:64. Not a code blocker, but update the PR description or explain the intentional change.
• The newer pagination model is cleaner than cumulative limit refetching, but it assumes the SDK/server supports roots, start, and limit exactly as used in session.list(). CI/type coverage should verify this against the real SDK types.
• packages/ui/src/components/session-list.tsx remains oversized at ~921 lines, above the project warning threshold. Not a blocker by itself, but the added async pagination/search behavior would be easier to reason about if extracted later.

Validation:

• Ran npm run typecheck --workspace @codenomad/ui; it still cannot produce a meaningful local result because this worktree lacks installed dependencies (solid-js, @opencode-ai/sdk, etc.). The output is dominated by missing module/type errors, so CI should be treated as the compile source of truth.

Required before merge:

1. Do not commit empty authoritative search results on server search failure when client-side matches exist.
2. Add a fallback or non-authoritative failure mode for child search results whose parent hydration fails.
3. Manually verify: query with loaded matches while server search fails, query matching only a child whose parent fetch fails, clearing a query while search is in flight, closing a session after loading beyond the first page, and reaching the end of pagination then refreshing.

--
Yours,
CodeNomadBot

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/26809511914

Artifacts expire in 7 days.
Artifacts:

• pr-511-19457f253bff2516dcb77dd924f2136ff5fd816e-tauri-macos
• pr-511-19457f253bff2516dcb77dd924f2136ff5fd816e-tauri-windows
• pr-511-19457f253bff2516dcb77dd924f2136ff5fd816e-tauri-linux
• pr-511-19457f253bff2516dcb77dd924f2136ff5fd816e-electron-macos
• pr-511-19457f253bff2516dcb77dd924f2136ff5fd816e-tauri-macos-arm64
• pr-511-19457f253bff2516dcb77dd924f2136ff5fd816e-electron-windows
• pr-511-19457f253bff2516dcb77dd924f2136ff5fd816e-electron-linux

[shantur]

@CodeNomadBot

How about now?

[codenomadbot]

Re-check complete for latest PR state at 2cff04bd. Assumption: this worktree reflects PR #511 HEAD.

Verdict: still changes requested / not ready to merge.

Findings:

1. Refetching children no longer prunes stale/deleted child sessions.
   packages/ui/src/stores/session-api.ts:222-227 and packages/ui/src/stores/session-api.ts:428-435
   The new pagination model changed fetchSessions() from replacing the instance session map to merging page results into the existing map. That is necessary for progressive pages, but fetchSessionChildren() also only merges the latest child list for a parent. It never removes children that were previously loaded for the same parent but are absent from the latest session.children() response. Because buildSessionThreads() renders children by iterating all sessions in the instance map and grouping by parentId (packages/ui/src/stores/session-state.ts:620-640), stale children can remain visible after a refresh, close-session refresh, or any child-list refetch. The previous full-map replacement implicitly pruned these. The fix should replace the child set for the refreshed parent, not just add/update returned children, while preserving unrelated sessions and runtime fields for children that still exist.

Previously reported blocker status:

• Resolved: Server search failures are now non-authoritative. The catch path clears search state instead of committing an empty search result, so loaded client-side matches remain visible.
• Resolved enough: Child-only search results with failed parent hydration now clear search state rather than committing unrenderable authoritative results. That falls back to client filtering instead of silently showing an empty authoritative server result.
• Resolved: Close-session refresh now uses the current fetch limit instead of an unbounded/default fetch.
• Resolved: Stale search responses are guarded with request IDs before committing final results.

Implementation quality notes:

• The PR body still describes 50-session pages, while SESSION_PAGE_SIZE is now 100 in packages/ui/src/stores/session-state.ts:64. Update the PR description or align the constant.
• packages/ui/src/components/session-list.tsx remains oversized at ~921 lines, above the project warning threshold. Not a blocker alone, but this is now carrying meaningful async pagination/search orchestration.

Validation:

• Ran npm run typecheck --workspace @codenomad/ui; local validation is still not meaningful because this worktree lacks installed dependencies (solid-js, @opencode-ai/sdk, etc.). CI should be treated as compile source of truth.

Required before merge:

1. When fetchSessionChildren(instanceId, parentSessionId) succeeds, remove stale children for that parent that are not in the returned child list.
2. Manually verify: delete or otherwise remove a child session, trigger a session refresh/children refetch, and confirm the child disappears from the sidebar/thread without leaving stale status/count state.

--
Yours,
CodeNomadBot

[shantur]

@CodeNomadBot

Now?

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/26810846896

Artifacts expire in 7 days.
Artifacts:

• pr-511-2cff04bdd68062f006526305da50b2835391373a-electron-linux

[codenomadbot]

Re-check complete for latest PR state at ba20e1d2. Assumption: this worktree reflects PR #511 HEAD.

Verdict: no blocking findings from this scoped gatekeeper review.

Findings:

• No new merge-blocking regressions found in the inspected session pagination/search changes.

Previously reported blocker status:

• Resolved: fetchSessionChildren() now prunes stale children absent from the latest session.children() response and clears associated loaded/message/info/cache state for those stale child IDs.
• Resolved: Server-search failures remain non-authoritative and fall back to client-side filtering.
• Resolved: Child-only search results with failed parent hydration clear search state instead of committing unrenderable authoritative results.
• Resolved: Close-session refresh uses the current fetch limit instead of an unbounded/default fetch.
• Resolved: Stale search responses are guarded with request IDs before committing final search results.

Residual notes, not blockers:

• The PR body still describes 50-session pages, while SESSION_PAGE_SIZE is now 100 in packages/ui/src/stores/session-state.ts. Update the description before merge to avoid reviewer/operator confusion.
• packages/ui/src/components/session-list.tsx remains oversized at ~921 lines, above the project warning threshold. This does not need to block this PR, but the async search/pagination behavior should be a future extraction candidate.

Validation:

• Ran npm run typecheck --workspace @codenomad/ui; local validation is still not meaningful because this worktree lacks installed dependencies (solid-js, @opencode-ai/sdk, etc.). CI should remain the compile source of truth.

Recommended manual verification before merge:

1. Load multiple pages, close a session, confirm the loaded range and sentinel remain consistent.
2. Search with loaded local matches while forcing server search failure, confirm local matches stay visible.
3. Search for a child-only result where parent hydration succeeds, confirm the result renders under the parent.
4. Remove/delete a child, refetch children, confirm the stale child disappears and counts/status update.

--
Yours,
CodeNomadBot

[shantur]

Thanks @VooDisss

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/26811042159

Artifacts expire in 7 days.
Artifacts:

• pr-511-ba20e1d200d326a0d64691e5dbb36a094d4c27f1-tauri-macos
• pr-511-ba20e1d200d326a0d64691e5dbb36a094d4c27f1-tauri-linux
• pr-511-ba20e1d200d326a0d64691e5dbb36a094d4c27f1-tauri-windows
• pr-511-ba20e1d200d326a0d64691e5dbb36a094d4c27f1-electron-macos
• pr-511-ba20e1d200d326a0d64691e5dbb36a094d4c27f1-tauri-macos-arm64
• pr-511-ba20e1d200d326a0d64691e5dbb36a094d4c27f1-electron-windows
• pr-511-ba20e1d200d326a0d64691e5dbb36a094d4c27f1-electron-linux