[Desktop 0.18.2] project_create writes to projects.db successfully but sidebar shows no project entry

[onekooo]

Summary

Calling the project_create tool (which the TUI exposes to bind a session to a folder) returns success and writes the expected rows to projects.db / project_folders / project_meta. However, Hermes Desktop 0.18.2 shows no visible change in the UI after the call — neither immediately, nor after a full process restart. The sidebar contains no project entry, the active-project indicator in the top dropdown is unchanged, and the session list is not grouped by project.

This makes the feature effectively a no-op on Desktop, even though the data layer claims the project was created.

Environment

• Hermes Desktop: 0.18.2 (build stamp ac6dd59, built 2026-07-08)
• OS: Windows 10 22H2 (build 26200.8655)
• Install method: bootstrap-installer (Tauri-based, per apps/bootstrap-installer/ source paths in the local snapshot)
• HERMES_HOME: C:\Users\Administrator\AppData\Local\hermes

Steps to reproduce

1. Launch Hermes Desktop 0.18.2. Sidebar shows the default list (新建会话 / 技能与工具 / 消息平台 / 产物) with no project entries.
2. From inside a TUI/CLI session, call:

   project_create(name="Hermes Workspace", path="D:\Hermes-workspace")
   

3. The tool returns:

   { "success": true, "id": "p_2280acb5", "slug": "hermes-workspace",
     "name": "Hermes Workspace", "primary_path": "D:\\Hermes-workspace" }

4. Verify the database was actually written (via the bundled python):

   SELECT * FROM projects;
   -- ('p_2280acb5','hermes-workspace','Hermes Workspace', ...,
   --  'D:\\Hermes-workspace', 1783518882, 0)
   SELECT * FROM project_folders;
   -- ('p_2280acb5','D:\\Hermes-workspace',NULL,1,1783518882)
   SELECT * FROM project_meta;
   -- ('active_id','p_2280acb5')

   → All three tables are populated. The project_meta row also marks the new project as active_id, suggesting Desktop is expected to consume this.
5. Fully kill the Desktop main process and respawn it (this is important — see "What I tried" below) to rule out any hot-reload/cache hypothesis.
6. Observe the sidebar.

Expected behaviour

After step 2 (or after step 5), the sidebar should show a project entry representing Hermes Workspace bound to D:\Hermes-workspace, allowing me to click into a session that is anchored to that directory — i.e. the same session-scoped cwd binding that the TUI gets from project_create should propagate to the Desktop UI.

Actual behaviour

Sidebar is byte-for-byte identical before the project_create call and after a full Desktop restart. (I diffed two screenshots and the user also visually confirmed: "没有什么不一样" / "no visible difference".)

The new process is verifiably a fresh start, not the same process that served the sidebar before the call — see "What I tried" for the evidence.

What I tried (so maintainers don't suggest them)

• Diffed screenshots before/after project_create while the same Desktop process was running → no diff. (Not conclusive on its own: a running Electron app could just not re-render the sidebar.)
• Killed the Desktop main process (taskkill /F /PID 23976) and observed the children auto-reaped → confirmed by:
  • Renderer / GPU / network / utility children gone
  • 5-second later Get-Process Hermes shows brand-new PIDs: 6384 (main), 17084 (gpu), 33416 (network), 16456 (renderer), 4268 (audio)
  • New --launch-time-ticks=1307749876511 (old: 1307190469658)
  • New --field-trial-handle=2084,... (old: 2116,...)
  • Three independent indicators that this is a fresh Electron process tree that should have re-read projects.db from disk on launch
• Inspected the in-memory state via SQLite directly — projects.db is populated, so the file is on disk and readable; whatever Desktop is doing on startup, it isn't reading this table into the UI.

Suggested root-cause direction (not a fix)

Based on AGENTS.md ("desktop features are welcome and land routinely"), the most likely cause is that the projects.db → Desktop UI binding is not implemented in v0.18.2, while the Python-side project_create tool was landed (and writes the data the future UI will need). In other words, this is a "data layer ahead of UI" situation, not a regression.

A rough map of where to look in the source:

• project_create itself: probably in hermes_cli/ or agent/tools/ (whatever implements the tool registry entry for project_create).
• Desktop sidebar rendering: apps/desktop/ — the React components that render the "新建会话 / 技能与工具 / 消息平台 / 产物" entries. None of them currently iterate projects / project_folders from projects.db on startup, or the new entry would have appeared after the restart.
• Desktop main-process IPC: needs a projects:list / projects:read channel that reads projects.db and pushes results to the renderer.

I am happy to open a follow-up PR for the renderer+IPC part if maintainers agree this is the gap — but I want to confirm the design first since AGENTS.md is strict about not bolting on raw env vars and prefers the existing hermes tools / hermes setup UX.

Additional context (lower-priority, but related)

While diagnosing this I noticed two related issues that may or may not be the same root cause:

1. state.db → sessions.cwd is sometimes NULL even for sessions that clearly ran inside a project. Example: the session that created D:\Hermes-workspace\hello.py has cwd = NULL in state.db, while its sibling session that created hello.go (created minutes later, same directory) has cwd = 'D:\Hermes-workspace'. The on-disk files confirm both sessions were anchored to the same folder at runtime; the metadata just wasn't persisted for the first one. (See SQL: SELECT id, started_at, cwd FROM sessions WHERE started_at > strftime('%s','2026-07-08');)

2. A user-visible workaround question this raises: "How do I get files from different sessions to land in different directories?" Today the only answer is cd in the terminal before opening a new session, or write_file with an absolute path. If project_create + Desktop UI integration is the intended answer, that integration is the missing piece — and that's exactly what this issue is about.

Reproduction artefacts I can provide on request

• projects.db snapshot (before/after the call) — already shown in step 4
• state.db rows for today's 4 sessions, including the cwd discrepancy
• Screenshot of the sidebar before and after the Desktop restart
• PowerShell transcript of the Get-CimInstance Win32_Process output for Hermes.exe pre/post kill

[teknium1]

Thanks for the detailed reproduction and the related Project Cockpit context in #61484.

This automated hermes-sweeper review found that the reported projects.db → Desktop sidebar behavior is already implemented on main and was included in the reported build lineage:

• 488ae376dbef8e411f30e844e8b40ba55fc97e19 (feat(desktop): render backend-authoritative projects sidebar) introduced the Desktop project-sidebar implementation.
• apps/desktop/src/app/chat/sidebar/index.tsx:491 refreshes projects.list and projects.tree when the grouped project sidebar is active and the gateway connects.
• apps/desktop/src/store/projects.ts:237 and :256 populate renderer state from those RPCs; tui_gateway/server.py:10796 serves projects.list directly from the per-profile project store.
• The implementation commit is an ancestor of build stamp ac6dd598a and is contained in release v2026.7.7.2 (Desktop 0.18.2).

Closing as implemented on main. If the packaged Windows application still does not show a project after this code path, that is a separate runtime/package/backend-connection regression rather than the missing UI binding described here.