[Linuxuser67]

Root cause

With Cookies from Browser = Brave, a manual paste runs yt-dlp with --cookies-from-browser=brave:<profile>.

The profile and cookie DB are readable in the Flatpak, and the Brave Safe Storage key item exists, is unlocked, and is readable. The same command fails outside the Flatpak, so the sandbox is not the cause.

The failure is in yt-dlp's keyring walk. It iterates the default login collection and aborts when it reaches a stale/deleted item path before the valid Brave item. The D-Bus trace:

• default collection: /org/freedesktop/secrets/collection/login
• Brave item: /org/freedesktop/secrets/collection/login/1 (label Brave Safe Storage)
• yt-dlp requests /org/freedesktop/secrets/collection/login/2 → Object does not exist at path … → top-level ERROR: Item does not exist!

A Secret Service backend switch (for example oo7 ↔ gnome-keyring) can leave such ghost paths in the collection. Reverting the backend does not necessarily rebuild the item list; the stale path keeps breaking yt-dlp before it reaches the valid Brave entry.

Fix

• On a cookie-extraction failure with --cookies-from-browser and no staged handoff jar, retry the probe once without that flag.
• Latch the failure for the session so later previews/downloads do not repeat the broken keyring walk. A staged extension jar still wins. Changing the browser preference or restarting clears the latch.
• If the retry also fails, the error notes that browser cookies could not be read and were skipped, so an authenticated URL failure is explainable.

This does not repair the keyring. Direct browser-cookie extraction stays blocked until the collection is rebuilt; the extension is the reliable authenticated path. The fallback makes public previews usable and prevents the failed keyring walk from blocking them.

Tests

• Pure tests for the retry predicate (keyring/DB/decrypt failures retry; generic auth/URL failures do not; a staged --cookies jar is preserved) and for dropping only the browser-cookie flag.
• Fake-yt-dlp test: the first attempt with the browser flag emits Item does not exist!; the retry drops the flag, succeeds, and latches the session.

CI run: https://github.com/Linuxuser67/Grab/actions/runs/39558894514 (pending; audit waits on #504).

The audit job is red only because of the two base-wide advisories addressed by the separate #504 lockfile PR. Merge #504 first, then rebase this PR.

Verification for the user

After this merges and a beta.6 Flatpak is attached:

1. Manual paste with Brave selected: the preview should load (public URL) even while the keyring is still broken.
2. Extension handoff: the staged jar should still be used and win over browser cookies.
3. Change the browser preference (or restart): the latch clears and direct browser cookies are attempted again.
4. Repairing the keyring (stopping leftover oo7 services and restarting the GNOME keyring/session so the login collection is rebuilt) is what restores direct browser-cookie extraction. If an authenticated/private URL still fails after the no-cookie retry, use the extension.

[Linuxuser67]

Closing this: the root cause is a stale keyring item path (a ghost entry left by a Secret Service backend switch), not a Grab code defect. The keyring repair is the fix; the fallback is not needed for the reporter's setup. The branch and analysis remain available if we want graceful degradation later.