Workspaces absent from UI workspaces tab in plugin settings

[Midway65]

Went to the settings tab for workspaces and none of the workspaces I've set up appear in the list only two are shown Undefined and Default workspace. When I go to .nexus/nexus/workspaces they are all there but when I check the .obsidian/plugins/nexus/data.json there is no listing for workspaces at all. The result being that when I opened claude desktop and called for one of my workspaces to be activated it was not found even though it exists in the workspace directory. Is there a way to rectify this? Windows 11 environment.

[Midway65]

Agents are listed in their tab appropriately.

[ProfSynapse]

Everything gets saved in a sqlite database now - do you have a .nexus/cache.db file? And what version are you on?

[Midway65]

I did a some research with claude here is the result.

Bug Report: Workspaces Tab Displays Only 2 Entries Despite 18 Named Workspaces

Plugin: Nexus MCP
Environment: Obsidian Desktop (Windows 11)
Nexus version: [insert your version]
Date observed: 2026-02-19

---

Summary

The Workspaces tab in the Nexus UI displays only two entries — "Undefined" and "Default" — despite 18 named workspaces existing in .nexus/workspaces/. The MCP API (memoryManager.listWorkspaces) returns all 18 workspaces correctly. The bug is isolated to the tab UI display layer.

---

Environment

• OS: Windows 11
• Obsidian version: 1.12.2
• Nexus plugin version: 4.3
• Vault location: local path (synced via Proton Drive)
• .nexus/ location: vault root

---

Steps to Reproduce

1. Create multiple named workspaces via memoryManager.createWorkspace across separate Claude Desktop sessions
2. Open Obsidian and navigate to the Nexus Workspaces tab
3. Observe that only 2 workspaces are displayed regardless of how many exist in .nexus/workspaces/

---

Expected Behavior

The Workspaces tab should display all workspaces returned by memoryManager.listWorkspaces — in this case, 18 named workspaces.

---

Actual Behavior

The tab displays exactly 2 entries:

• "Undefined" — corresponds to ws_default.jsonl, whose workspace_created event has an empty name field
• "Default" — corresponds to ws_Default Workspace.jsonl

All other named workspaces (e.g. Investing, PineScript, LCSH, Economics, etc.) are invisible in the tab.

---

Diagnostic Findings

Investigation of .nexus/workspaces/ and cache.db revealed the following:

1. JSONL files are intact and correctly named

The workspace directory contains 18 named .jsonl files (e.g. ws_Investing.jsonl, ws_PineScript.jsonl). All are valid and readable. memoryManager.listWorkspaces via MCP returns all 18 with correct names and descriptions — confirming the data layer is healthy.

2. The workspaces table in cache.db is also correct

Direct SQLite inspection of cache.db shows all named workspaces present in the workspaces table with their UUIDs, names, descriptions, and rootFolder paths intact.

3. The sessions table reveals the likely root cause

All sessions in cache.db have workspaceId = 'default' (a literal string), regardless of which named workspace was active during the conversation. Example rows:

id                                   | workspaceId | name
-------------------------------------|-------------|------------------------------
2125cc63-1f5f-4ef0-b657-2fdaeb470f43 | default     | nexus-verify
d04164f0-8d04-4cad-981c-ab9a9ae697c2 | default     | nexus-verify
382196b4-07a1-49fe-b77b-01df7db5a7ba | default     | s-final-portfolio
64e24126-a4c9-41ed-81b9-75c4c77ad81a | default     | s-final-portfolio

This suggests the tab UI filters or groups workspaces by session activity, and since all sessions reference workspaceId = 'default', only the default workspace bucket surfaces in the UI.

4. ws_default.jsonl has no name in its creation event

The workspace_created event in ws_default.jsonl has name = "" (empty string), causing the tab to render it as "Undefined". Appending a workspace_updated event with a name field did not resolve the display — suggesting the tab reads only the creation event or the SQLite cache, not the full event log.

5. File sizes

ws_default.jsonl has grown to ~108MB (4,853 JSONL lines) because every session that does not explicitly call loadWorkspace is routed into the default workspace. This may also contribute to UI rendering issues.

---

Hypothesis

The Workspaces tab appears to derive its list from sessions in cache.db grouped by workspaceId, rather than querying the workspaces table directly or reading the JSONL files. Since all sessions store workspaceId = 'default', named workspaces with no associated sessions are not surfaced.

If this is correct, the fix would be for the tab to query the workspaces table (or JSONL directory) directly as the source of truth, independent of session activity.

---

Workaround

The MCP API is unaffected. memoryManager.listWorkspaces and memoryManager.loadWorkspace(name) function correctly. Users can explicitly call loadWorkspace at session start to route work into the correct named workspace.

---

Files Relevant to Investigation

File	Size	Notes
.nexus/workspaces/ws_default.jsonl	~108MB	Empty name in workspace_created; absorbs all unrouted sessions
.nexus/cache.db	~135MB	workspaces table correct; sessions table has workspaceId = 'default' for all rows
.nexus/workspaces/ws_.jsonl	86KB–11MB	18 files, all valid, all invisible in tab

---

Request

1. Fix the Workspaces tab to query the workspaces table (or JSONL directory) directly as its data source, not derive the list from session activity
2. Resolve the workspace_created empty-name case so it displays a fallback label (e.g. "Default") rather than "Undefined"
3. Consider routing sessions to the named workspace UUID in cache.db when loadWorkspace is called, so session-based grouping works correctly going forward
4. Consider a size warning or auto-archival mechanism for ws_default.jsonl when it exceeds a threshold

[Midway65]

version 4.2 and 1.12.2 of obsidian

[Midway65]

Additional Test: cache.db Rebuild

Test performed: Closed Obsidian, renamed cache.db → cache.db.bak, restarted Obsidian, allowed full reindex.

Result: Tab still displays only "Undefined" and "Default" after a clean cache rebuild.

Conclusion: The bug is not caused by stale cache data. The workspaces table is repopulated correctly on rebuild (confirmed via prior SQLite inspection showing all 18 workspaces present). The tab's query logic itself is the defect — it does not read from the workspaces table or JSONL directory. The session-filter hypothesis is confirmed: the tab derives its list from session activity (workspaceId grouping) rather than the workspace registry, and since all sessions carry workspaceId = 'default', only the default bucket is displayed regardless of cache state.

[ProfSynapse]

Hey can you update your version? you're a few behind I want to see if that works.

[Midway65]

Actually I made and error. I was using 4.3 when this happend. Tried upgrading that and no change. I wound up deleting the plugin and renaming the original .nexus folder to preserve the workspaces. Is there any way to restore them to the new install? Not a huge loss but would be helpful. As an aside I turn off all syncing while working with obsidian open and nexus to avoid issues with sqlite.

[ProfSynapse]

There definitely should be can you use an agentic coding tool or even claude cowork probably to investigate your jsonl files/sqlite...were they ever there and they just disappeared one day?

[goaroundme]

Hey, I'm having the same issue, and asked codex to do a review, here is the response, it seems to think undefined is the .workspace/.trace-schema, deleting that folder causes it to recreate the same folder/file

Codex:
That behavior now makes sense from the code and your files.

What’s happening

undefined workspace comes from a bug in legacy fallback scanning.
Fallback workspace loader scans *.json and does not exclude hidden/system files: main.js (line 292).
You have .trace-schema.json (migration marker), and it gets treated as a workspace.
That file has no name, so UI renders it as undefined.
Marker file path is explicitly created here: main.js (line 224825).
Your real workspaces are in .nexus and valid.
Files exist with correct workspace_created events:
ws_01d27b6c-e79b-49da-abb0-b344a131f1b4.jsonl
ws_f316fff5-920b-42ad-810f-12d6c2cc0122.jsonl
SQLite cache also has all 3 correct rows (default, ID_Professional_Branding, test).
Settings UI can cache fallback results too early.
WorkspacesTab uses prefetchedWorkspaces if present and skips reloading: main.js (line 227391).
Prefetch runs immediately in settings display: main.js (line 230248).
If that prefetch occurs before adapter is ready, it uses fallback (.workspaces), giving exactly Default + undefined.
Why you see “default + undefined” after restart

It’s not that your workspace disappeared from storage.
You’re seeing a stale/legacy fallback list (plus .trace-schema.json misclassified as a workspace).
If you want, I can patch main.js with two targeted fixes:

Exclude hidden/schema files in listWorkspaceIds().
Make WorkspacesTab always refresh from workspaceService even when prefetchedWorkspaces exists.

User:
problem with updating main.js is it will be overwritten next update, what can i do with configuration to fix it

Codex:
You’re right, patching main.js is fragile. Best config/data-only workarounds:

Set your default workspace directly in config
Edit data.json
Set "defaultWorkspaceId" to your real workspace ID (from ws_.jsonl)
Example: "defaultWorkspaceId": "f316fff5-920b-42ad-810f-12d6c2cc0122"
This makes chat load the correct workspace even when the settings list is wrong.
Stop the legacy fallback from showing undefined
The undefined item is .trace-schema.json being misread as a workspace.
Easiest config workaround: rename .workspaces to .workspaces-archived-manual (keep backup).
Nexus data is in .nexus, so your actual workspaces remain intact.
If you need the Workspaces settings UI to look correct immediately
Mirror each workspace into legacy files:
create .json with id,name,description,rootFolder,created,lastAccessed,isActive,sessions:{}
This feeds the fallback path without editing plugin code.
Most practical combo: do 1 + 2.
If you want, I can give exact JSON content for each workspace file from your current .nexus data.

[ProfSynapse]

Ok looking into it deeper...so weird because if you use the workspace tooling it find it no problem so just not showing up in the UI. Will work on this.

[Midway65]

I was able to restore the UI listing of all the workspaces and the conversations that I had lost. The following is a discription of what happened and how I used claude code to recover them. In my case I think it was a crash as I keep my sync off while using obsidian and then sync on closure. Anyway hope this helps.

What Happened

The Nexus plugin stores data in two places:

• Data files: .nexus/workspaces/ws_[name].jsonl and .nexus/conversations/ — your actual data (never lost)
• SQLite cache: .nexus/cache.db — the index the UI reads from

There are two file formats in .nexus/workspaces/:

• UUID-named files (e.g. ws_1c44e658-....jsonl) — current format, contain workspace_created as first event
• Name-named files (e.g. ws_LCSH.jsonl) — legacy format, first event is trace_added; historical, do not need to be re-registered

The SQLite cache can lose track of your workspaces and conversations while the data files remain intact. They become invisible in the UI but are not deleted.

Two common triggers:

1. Plugin reload or crash — the cache is not rebuilt automatically on restart
2. Sync programs — SQLite databases cannot be safely synced by generic file sync tools

---

Prevention: Sync Programs

SQLite uses auxiliary files during writes — a WAL journal (.db-wal) and a shared memory file (.db-shm). When a sync client uploads cache.db without its WAL file, replaces the local DB with an older cloud copy during a conflict, or holds a file lock that interrupts a write, the result is exactly this failure: JSONL files intact, SQLite cache empty or stale.

The JSONL files are append-only flat text and sync safely. Only cache.db is at risk.

Risk by sync tool

Tool	Risk	Notes
Proton Drive	High	No file exclusion support; vault inside sync folder means every DB write races the sync client
OneDrive	High	Known file locking conflicts with SQLite WAL; can replace DB with older version
iCloud	High	"Optimized storage" can evict cache.db to cloud while JSONL files remain local
Obsidian Sync	Medium	Designed for Obsidian but SQLite files are explicitly cautioned against in their docs
Dropbox / Google Drive	Medium	Similar WAL and conflict copy issues as OneDrive
Syncthing	Low	Supports .stignore exclusions — can exclude cache.db while syncing JSONL files

---

Windows

Proton Drive:
No file exclusion support. Options in order of preference:

• Move the vault outside the Proton Drive folder and sync with Syncthing or Obsidian Sync instead
• Pause sync via the system tray icon before opening Obsidian; resume after closing

OneDrive:
Supports folder-level exclusions:

• Open OneDrive Settings → Account → Choose folders → deselect the .nexus folder entirely
• Or exclude specific files by adding them to a .nosync pattern in OneDrive advanced settings

Windows Defender / antivirus:
Real-time scanning can also lock SQLite files briefly. If rebuilds happen frequently with no obvious sync cause, add .nexus\cache.db to your antivirus exclusion list.

Syncthing (recommended replacement for Proton Drive):
Add a .stignore file in the vault root:

cache.db
cache.db-shm
cache.db-wal

This syncs all JSONL source files while each machine rebuilds its own local cache.

---

Mac

iCloud Drive:
"Optimize Mac Storage" is the primary risk — it evicts files to cloud when disk space is low, including cache.db. To prevent:

• System Settings → Apple ID → iCloud → iCloud Drive → Options → deselect the Obsidian vault folder
• Or move the vault to a location outside the iCloud Drive folder (e.g. ~/Documents with iCloud Drive disabled for Documents)

Proton Drive (Mac):
Same no-exclusion limitation as Windows. Use the menu bar icon to pause sync, or move the vault.

OneDrive (Mac):
Preferences → Account → Choose Folders → deselect the .nexus folder.

Syncthing (recommended replacement):
Same .stignore approach as Windows — add to the vault root:

cache.db
cache.db-shm
cache.db-wal

---

Linux

Syncthing (recommended):
The best sync option on Linux. Add .stignore in the vault root:

cache.db
cache.db-shm
cache.db-wal

This syncs all JSONL files while each machine maintains its own local cache.

OneDrive (unofficial client — e.g. onedrive by abraunegg):
Supports exclusions via ~/.config/onedrive/config:

skip_file = "cache.db|cache.db-shm|cache.db-wal"

Proton Drive (Linux beta):
Limited client with no exclusion support. Avoid storing the vault inside the Proton Drive mount point.

iCloud:
No native Linux client — not applicable.

---

Universal fallback

If your sync tool has no exclusion support, use the Pause sync option in the system tray or menu bar before opening Obsidian, and resume after closing. This prevents conflicts but requires discipline. Since recovery takes ~30 seconds and data is never at risk, accepting occasional rebuilds is also a reasonable trade-off.

---

Recovery Steps

Step 1 — Open the Obsidian Developer Console

Press Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac), then click the Console tab.

The first time you open it, you may need to type allow pasting and press Enter before you can paste code.

---

Step 2 — Confirm your workspace files exist

const plugin = app.plugins.plugins['nexus'];
const adapter = await plugin.serviceManager.container.get('hybridStorageAdapter');
const files = await adapter.syncCoordinator.jsonlWriter.listFiles('workspaces');
console.log('Workspace files found:', files.length);
console.log(files);

You should see a list of .jsonl files including UUID-named ones.

---

Step 3 — Rebuild SQLite cache from JSONL files

This is the primary recovery method. It clears the SQLite cache and replays all events from the JSONL source files:

const plugin = app.plugins.plugins['nexus'];
const adapter = await plugin.serviceManager.container.get('hybridStorageAdapter');
const result = await adapter.syncCoordinator.fullRebuild({

onProgress: (msg, current, total) => {

console.log([Rebuild] ${msg} (${current}/${total}));

}

});
console.log('Rebuild result:', JSON.stringify(result, null, 2));

Look for "success": true and eventsApplied > 0 in the result. Zero errors is expected.

---

Step 4 — Verify data is in SQLite

const plugin = app.plugins.plugins['nexus'];
const ws = await plugin.serviceManager.container.get('workspaceService');
const all = await ws.getAllWorkspaces();
console.log('Total workspaces:', all.length);
console.log('Names:', all.map(w => w.name));

You should see all your workspaces listed here before touching the UI.

---

Step 5 — Force the settings Workspaces tab to refresh

Important: The Nexus settings panel (Settings → Community Plugins → Nexus → Options) caches the workspace list in prefetchedWorkspaces and will continue showing stale data even after closing and reopening. Simply closing/reopening the settings dialog is not sufficient.

With the Nexus settings panel open, run:

const sv = app.setting.activeTab;
sv.prefetchedWorkspaces = null;
await sv.prefetchWorkspaces();
sv.display();

Your workspaces should now appear in the Workspaces tab.

---

Step 6 — Force the sidebar conversation list to refresh

The conversation list in the Nexus sidebar also caches stale data. With the Nexus sidebar open, run:

const leaves = app.workspace.getLeavesOfType('nexus-chat');
const view = leaves[0].view;
const cm = view.conversationManager;
await cm.loadConversations();
view.conversationList.setConversations(cm.getConversations() || []);

Your conversations should now appear in the sidebar.

---

Notes

• Your data is never at risk — the .jsonl files are the source of truth and are not modified by this process
• fullRebuild is safe to run multiple times — it clears and fully rebuilds from JSONL each time
• The UI cache bug (prefetchedWorkspaces not invalidating after rebuild) means Step 5 is always required after Step 3
• If errors is non-zero in the rebuild result, those files may be corrupted or in an unexpected format; check them individually
• Prompts are stored in .obsidian/plugins/nexus/data.json (not in .nexus) — back up this file separately to preserve custom prompts

[ProfSynapse]

Okkk I think I fixed it try downloading the new version and try again.

[Midway65]

That's great. I'll give it a try. If there is one thing I'm good at is breaking things. I'll let you know if anything else comes up. Other than that I continue to think this plugin is the best of class for a Claude MCP. Thanks!