feat(memory): Graphnosis provider UI, MCP install, and onboarding#856
feat(memory): Graphnosis provider UI, MCP install, and onboarding#856nehloo wants to merge 2 commits into
Conversation
Add English copy and download links for the Graphnosis memory provider, a Capabilities → MCP Servers "Install Graphnosis MCP" card that registers the stdio server directly (npx @graphnosis/mcp-relay) via addMcpServer, and a Welcome onboarding card pointing to graphnosis.com. The memory provider itself ships as the standalone hermes-graphnosis plugin (github.com/nehloo-interactive/hermes-graphnosis); Hermes Desktop discovers it automatically since it runs Hermes Agent underneath. No dependency on any in-tree hermes-agent change.
|
Supersedes #763. That PR used an earlier approach — a hermes-agent catalog-preset install ( This PR rebuilds the same UI on current |
Greptile SummaryThis PR adds Graphnosis integration to Hermes Desktop. The main changes are:
Confidence Score: 5/5The latest provider-discovery fix looks safe to merge.
Important Files Changed
Reviews (2): Last reviewed commit: "fix(memory): register graphnosis in the ..." | Re-trigger Greptile |
| name: "graphnosis", | ||
| type: "stdio", | ||
| command: "npx", | ||
| args: ["-y", "@graphnosis/mcp-relay", "${HOME}/.graphnosis/mcp.sock"], |
There was a problem hiding this comment.
The MCP config writer preserves ${HOME}/.graphnosis/mcp.sock as a literal argv value, and stdio servers launched directly do not receive shell expansion. Unless the relay explicitly expands this syntax itself, the installed server cannot find the user's socket even though installation reports success; the value is also not portable to Windows.
There was a problem hiding this comment.
hermes-agent interpolates ${VAR} placeholders in MCP server config before spawn (tools/mcp_tool.py, "Recursively resolve ${VAR} placeholders"), so on macOS/Linux ${HOME} resolves to the real socket path — this matches the convention the other Graphnosis surfaces already use (the relay's own README and the prior catalog preset). You're right that it's not robust on Windows, where HOME is typically unset and the placeholder would stay literal. That's a pre-existing, cross-surface gap rather than something specific to this PR; the proper fix is to have @graphnosis/mcp-relay default to os.homedir()/.graphnosis/mcp.sock when no path arg is given, which I'm tracking on the relay package. Keeping ${HOME} here for consistency with the existing providers.
There was a problem hiding this comment.
Update: the relay fix has landed. @graphnosis/mcp-relay@1.0.3 (published) now expands a leading ~ and ${HOME}/$HOME itself via os.homedir() (and defaults to ~/.graphnosis/mcp.sock when no path arg is given), so the socket path resolves correctly even when the host spawns the server without a shell — including on Windows where HOME is unset. The ${HOME} value written here is therefore portable once users are on relay ≥1.0.3.
| graphnosis: | ||
| "Local encrypted engram graph — auto-prefetch, recall, remember. Requires Graphnosis app (no API key)", |
There was a problem hiding this comment.
Local Discovery Misses Description Key
When a local graphnosis plugin directory is discovered, the provider metadata falls back to the bare name because Graphnosis is absent from the known-provider map. MemoryProviders therefore looks up t("graphnosis") instead of this new memory.providers.graphnosis key, so the card displays only graphnosis rather than the added description.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Good catch — fixed in 847ed5b. graphnosis was missing from the KNOWN_PROVIDERS map in src/main/installer.ts (and the remote-mode map in src/main/ssh-remote.ts), so discovery fell back to the bare name and the card looked up t("graphnosis") instead of this key. Added graphnosis: { description: "memory.providers.graphnosis", envVars: [] } to both.
Local (installer.ts) and remote (ssh-remote.ts) memory-provider discovery
fell back to the bare provider name for anything absent from KNOWN_PROVIDERS,
so the Memory screen rendered t("graphnosis") — a literal "graphnosis" —
instead of the memory.providers.graphnosis description. Add the entry so the
description key resolves. (Flagged by review.)
Adds patches/memory-provider-known-map.patch (installer.ts + ssh-remote.ts):
without it, local/remote memory-provider discovery falls back to the bare
provider name, so the Memory screen renders t("graphnosis") instead of the
memory.providers.graphnosis description. Mirrors fathah/hermes-desktop#856
follow-up commit 847ed5b. (Flagged by automated review on the PR.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The stdio relay read process.argv[2] raw — path was required and never
expanded. Some MCP hosts spawn stdio servers without a shell and don't
interpolate ${HOME}; notably on Windows HOME is usually unset, so
${HOME}/.graphnosis/mcp.sock reached the relay as a literal, unusable path.
Now the socket-path arg is optional (defaults to ~/.graphnosis/mcp.sock), and
a provided path has a leading ~ and ${HOME}/$HOME expanded via os.homedir()
(cross-platform). Fixes the Windows gap flagged on fathah/hermes-desktop#856 —
consumers can keep passing ${HOME}/... or omit the arg entirely. README
updated; @graphnosis/mcp-relay bumped 1.0.2 -> 1.0.3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Summary
Adds optional UI surfaces for connecting Graphnosis — local, encrypted, on-device memory — to Hermes Desktop:
graphnosisprovideraddMcpServer(npx -y @graphnosis/mcp-relay ${HOME}/.graphnosis/mcp.sock)No coupling to hermes-agent
The memory provider ships as a standalone plugin (nehloo-interactive/hermes-graphnosis), which Hermes Desktop discovers automatically since it runs Hermes Agent underneath. No dependency on any in-tree hermes-agent change — the MCP install writes the server config directly rather than calling a catalog preset.
Test plan
🤖 Generated with Claude Code