Summary
The desktop project's switcher continues to show a project after its directory has been deleted outside OpenKnowledge. There is no visible action to remove the stale entry from the recent-project list.
This makes it look as if the project still exists, even though only its cached recent-project record remains.
Environment
- OpenKnowledge:
0.33.0-beta.13
- macOS:
26.0.1
- Architecture: Apple Silicon (
arm64)
Steps to reproduce
- Create or open an OpenKnowledge project.
- Close or switch away from it.
- Delete the project's directory from the filesystem.
- Open the desktop app and open Switch project.
Actual behavior
The deleted project is still listed in the project switcher with its old path.
The path no longer exists on disk, but the entry remains in:
~/Library/Application Support/OpenKnowledge/state.json
Specifically, the old path is retained under recentProjects; associated entries may also remain in projectSessions and projectWindowBounds.
There is no visible context-menu or project-switcher action to remove the stale record.
Expected behavior
At least one of the following:
- The desktop app automatically detects and prunes or visually marks recent projects whose paths no longer exist; and/or
- Each project-switcher entry provides Remove from recent projects.
This action should only remove desktop-app history/state. It should be clearly distinct from:
ok deinit, which removes OpenKnowledge integration while preserving content;
- moving a project directory to Trash;
- permanently deleting project files.
Suggested UX
Add a context-menu action such as Remove from recent projects. For missing paths, the app could show a warning and offer Locate folder… or Remove.
If an entry is removed, clean its keys from:
recentProjects
projectSessions
projectWindowBounds
lastOpenedProject when applicable
Why this matters
OpenKnowledge is local-first, so users commonly move, rename, or delete project folders outside the app. A stale entry without a removal path creates ambiguity about whether the project was actually deleted and forces users to edit internal application state manually.
Summary
The desktop project's switcher continues to show a project after its directory has been deleted outside OpenKnowledge. There is no visible action to remove the stale entry from the recent-project list.
This makes it look as if the project still exists, even though only its cached recent-project record remains.
Environment
0.33.0-beta.1326.0.1arm64)Steps to reproduce
Actual behavior
The deleted project is still listed in the project switcher with its old path.
The path no longer exists on disk, but the entry remains in:
~/Library/Application Support/OpenKnowledge/state.jsonSpecifically, the old path is retained under
recentProjects; associated entries may also remain inprojectSessionsandprojectWindowBounds.There is no visible context-menu or project-switcher action to remove the stale record.
Expected behavior
At least one of the following:
This action should only remove desktop-app history/state. It should be clearly distinct from:
ok deinit, which removes OpenKnowledge integration while preserving content;Suggested UX
Add a context-menu action such as Remove from recent projects. For missing paths, the app could show a warning and offer Locate folder… or Remove.
If an entry is removed, clean its keys from:
recentProjectsprojectSessionsprojectWindowBoundslastOpenedProjectwhen applicableWhy this matters
OpenKnowledge is local-first, so users commonly move, rename, or delete project folders outside the app. A stale entry without a removal path creates ambiguity about whether the project was actually deleted and forces users to edit internal application state manually.