Feature Request: Support remote SLM daemon in the Hermes native plugin

[unfall103-debug]

Problem

The Hermes native plugin currently requires the SLM CLI/runtime to be installed locally on the same host as Hermes.

For example, after installing and enabling:

superlocalmemory 4.1.13

the Hermes plugin loads correctly, but:

/slm status

returns:

SLM CLI is unavailable. Install the owning runtime;
the Hermes plugin never installs Python packages.

This makes the native Hermes plugin difficult to use in a distributed deployment where the SLM runtime is intentionally hosted on a dedicated server.

Use case

I run Hermes and SuperLocalMemory on separate machines:

Hermes
  192.168.50.156
      |
      | LAN
      v
SuperLocalMemory
  192.168.50.144:8765

The SLM daemon and all memory data are intentionally centralized on the SLM server.

Hermes can already access the remote SLM daemon through its HTTP MCP endpoint, so the remote architecture itself works.

However, the native Hermes plugin still expects a local slm CLI/runtime.

This means I have to install another SLM runtime on the Hermes host just to satisfy the native plugin, even though the actual SLM service and memory database are already running remotely.

Requested feature

Please add first-class support for a remote SLM daemon in the Hermes native plugin.

For example, allow the plugin to be configured with something conceptually like:

SLM_DAEMON_URL=http://192.168.50.144:8765

or:

SLM_REMOTE_URL=http://192.168.50.144:8765

with the plugin executing its /slm commands, skills, advisors, and lifecycle hooks against the remote SLM daemon instead of requiring a local SLM runtime.

Ideally:

Hermes host
  └── Hermes native plugin
          |
          | HTTP/API
          v
Remote SLM daemon
  └── memory/database

The Hermes host should not need to maintain a second SLM database or run a second SLM daemon.

Why this would be useful

This would make the Hermes plugin consistent with SLM's distributed deployment model.

It would allow:

• one centralized SLM memory service
• multiple Hermes/agent clients
• no duplicate local SLM databases
• no SLM runtime installation on every agent host
• centralized memory management
• agent-specific isolation using the existing remote SLM mechanisms

Current workaround

The remote SLM MCP endpoint works correctly, but that does not provide the full native Hermes plugin experience.

The native plugin itself still reports:

SLM CLI is unavailable

when the SLM runtime is not installed locally.

Environment

SLM: 4.1.13
Hermes: current release
OS: Linux
Deployment: separate Hermes and SLM hosts
SLM daemon: HTTP on LAN

Remote SLM endpoint:

http://192.168.50.144:8765/mcp/

The MCP integration is already working and exposes the SLM tools successfully.

Expected result

The Hermes native plugin should be able to operate as a remote client to an existing SLM daemon, without requiring a second local SLM runtime/database.

[bgausden]

The same gap exists in the Claude Code plugin (and, by the same launcher design, Copilot/Codex), so it may be worth treating this as a cross-plugin feature rather than Hermes-only. Notes from reading the code at 5bfa47c, in case they help scope it:

1. MCP half is mostly solved already. The daemon serves Streamable HTTP MCP at /mcp/<agent_id>, and slm connect --transport http-mcp-remote already configures the mcp-remote stdio→HTTP bridge (docs: npx route for the mcp-remote bridge, with the config that matches it #126 is about its npx form). A plugin could expose this as SLM_LAUNCHER=remote + a URL, with slm-launch exec'ing the bridge and ensure-venv skipping the local venv entirely.
2. Hooks are the hard half, by design. SLM_HOOK_DAEMON_URL rejects any non-loopback host (post_tool_async_hook.py L50–75) so a hostile env var can't exfiltrate the install token via X-SLM-Hook-Token. Remote hooks would need an explicit opt-in (separate variable, https or allowlisted private range, and a token scoped to the remote host rather than the local install token) — worth a security decision before implementation. Until then a plugin in remote mode should probably disable its hooks rather than fail silently.
3. SLM_DAEMON_URL isn't implemented. The distributed-deployment doc suggests it, but nothing in src/ reads it — filed separately as Docs: SLM_DAEMON_URL is documented for hub/remote clients but nothing reads it #142 so the doc can be fixed independently of this feature.

Related: #139 (Windows launcher has no SLM_LAUNCHER at all, so any remote mode there depends on it) and #141 (hooks call bare slm and fail silently without a system install).

---

This comment was generated by an AI assistant (Claude) from a read of the code at 5bfa47c, and reviewed by a human before posting.