Repository navigation
productivity plugin: dashboard.html forgets TASKS.md / memory folder on every reload #1095
Description
Problem
dashboard.html (from the productivity plugin) uses the File System Access API (showOpenFilePicker / showDirectoryPicker) to load TASKS.md and the memory/ folder. Every time the dashboard is reopened — a new browser tab, a restart, even just closing and reopening the file — it forgets the file/folder you picked last time and makes you re-select both from scratch. For a dashboard meant to be a daily driver, that's a meaningful bit of friction.
Proposed fix
The File System Access API supports persisting a FileSystemFileHandle / FileSystemDirectoryHandle in IndexedDB and re-querying permission on it later (handle.queryPermission() / handle.requestPermission()), without re-showing the picker dialog. I've implemented this in our own copy of dashboard.html:
After a successful pick, the handle is saved to a small IndexedDB store (productivity-dashboard / handles).
On page load, the dashboard tries to restore the saved TASKS.md handle and memory folder handle:
If permission is still granted, it reloads silently — no prompt at all.
If permission needs reconfirming (prompt state), the empty-state screen swaps its button to a one-click "Reconnect" instead of the full file picker.
Either way, a second button — "Choose a different file" / "Choose a different folder" — stays visible so switching to a different file is never blocked by the reconnect flow.
If the file's been moved/deleted, it falls back to the normal picker automatically.
This only touches dashboard.html (two new small buttons in the empty-state markup, plus the IndexedDB helper + refactored load functions in the script). No changes to TASKS.md/CLAUDE.md format, no new dependencies, no build step.
A patch is attached (dashboard-reconnect.patch) generated against the current productivity/skills/dashboard.html, and I'm happy to open this as a PR directly if that's preferred over a patch on an issue.
Caveats worth noting for reviewers
This relies on the File System Access API, so it only works in Chromium-based browsers (Chrome, Edge, etc.) — same limitation the dashboard already has today for the picker itself.
The saved handle lives in the browser's IndexedDB for the page's origin (typically shared across local file:// pages in Chromium), not in the markdown files themselves, so it's per-browser/per-machine and never travels with the files — confirmed this doesn't leak across users if the same dashboard.html is shared or copied.
Activity
AbarnaaSree commentedon Sep 17, 2026
I’d like to work on this issue.
The proposed IndexedDB-based handle persistence looks like a focused way to address the repeated file/folder selection without changing the existing TASKS.md or memory folder format.
I’d like to first review the current
dashboard.htmlloading and empty-state flows, then implement the reconnect behavior with persistedFileSystemFileHandle/FileSystemDirectoryHandlevalues, including permission re-checking and fallback to the existing picker when a handle is no longer usable.I’ll also add/verify the relevant edge cases, such as switching to a different file or folder and handling moved or deleted paths.
If the attached patch is still representative of the preferred approach, I’m happy to use it as a reference while implementing the change cleanly in the repository.