[AksharP5]

cap recordings list misses recordings after changing Desktop's storage folder. It can return an empty library even though Desktop and an explicit --dir both find the recording.

Read Desktop's current and previous storage paths, include the default folder, and deduplicate equivalent roots before using the existing scanner. Automatically discovered unreadable folders are skipped, matching Desktop. Explicit --dir stays exclusive and retains read errors. The combined list stays newest first.

Closes #2942.

Before / after

The same generated MP4 recordings and isolated Desktop settings were used with the baseline and patched production listing modules.

Scenario	Before	After
One custom recording, empty default folder	[]	Custom, with outputExists: true
Recordings in current, default, and previous folders	Default only	All three recordings, newest first
Custom path also appears in history through a symlink	Custom recording omitted	Custom recording appears once
Explicit --dir points to custom storage	Custom only	Custom only

Validation

• Five unit tests pass using the actual production module and project parser in an isolated Cargo executable. Scoped Clippy passes with --all-targets --no-deps -- -D warnings.
• The before/after executable checks pass for custom/default/previous folders, alias deduplication, explicit-directory isolation, and missing or corrupt settings. A real permission-denied previous folder is skipped; explicitly selecting it still returns an error.
• Added a Linux CLI integration test for default discovery and exclusive --dir, and wired it and the five unit tests into Linux CI. Updated the command documentation.
• cargo fmt --all, README formatting, and git diff --check pass.
• Full cargo check -p cap --locked --offline stops in ffmpeg-sys-next because the local FFmpeg headers lack libavcodec/avfft.h. The full CLI integration test has not run locally.

Confidence Score: 5/5

The PR appears safe to merge; no blocking issues remain.

Summary

Updates cap recordings list to find recordings in Desktop's current, default, and previous storage folders.

• The CLI lists recordings from Desktop's current, default, and remembered folders.

The earlier ordering-test concern is addressed: the test now supplies four fixed creation times across two folders and checks the exact returned order. No new actionable issues were found in the changes since the previous review. Tests were not run during this review.

_{Reviews (2) · Last reviewed commit: "test(cli): verify newest-first recording..." · Reviewed by Greptile}

[vercel]

@AksharP5 is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[richiemcilroy]

Thanks @AksharP5, reading the same custom and previous storage folders as the desktop app is the right fix, and the new tests run in Linux CI. One small follow-up from the Greptile review before we merge: the merge test in apps/cli/src/recordings.rs (around line 250) collects the results into a HashSet, so it would still pass if recordings came back oldest first or grouped by folder. Could you give the fixtures distinct, controlled creation times across the folders and assert the exact newest-first order?

[AksharP5]

Addressed in 0dc4e74. Four fixtures now have fixed creation times interleaved across two folders, and the test asserts their exact newest-first order. It fails if ordering is reversed or the global sort is removed. All five production-module tests and scoped Clippy pass with the real project parser; an executable replay also confirms real-metadata ordering and exclusive --dir behavior. cargo fmt passes. The full CLI cargo check still stops at the existing local FFmpeg header mismatch, libavcodec/avfft.h missing.

[richiemcilroy]

@greptileai review