[Bug] Memory Viewer starts twice on OpenClaw startup (port 18799 → 18800 fallback)

[prospect1314521]

Bug Description

When starting OpenClaw with the memos-local-openclaw-plugin, the Memory Viewer service is initialized twice, causing a port conflict.

Observed Behavior

1. First startup (when OpenClaw gateway starts):

   07:41:15 [plugins] MemOS Memory Viewer → http://127.0.0.1:18799
   07:41:15 [plugins] memos-local: password reset token: bd6c755f...
   

2. Second startup (when sending the first message/conversation):

   07:42:16 [plugins] memos-local: service.start() not called by host, self-starting viewer...
   07:42:16 [plugins] Viewer port 18799 in use, trying 18800
   07:42:17 [plugins] MemOS Memory Viewer → http://127.0.0.1:18800
   

Impact

• Does not break functionality: The plugin correctly falls back to port 18800, so memory features still work.
• Confusing logs: Users see two different Viewer URLs and two different password reset tokens.
• Resource waste: Two instances of the Viewer server are running unnecessarily.

Expected Behavior

The Memory Viewer should only start once during OpenClaw initialization. The second initialization triggered by the first conversation should be skipped if the service is already running.

Environment

• OpenClaw version: 2026.4.2
• memos-local-openclaw-plugin version: 1.0.8
• OS: Windows
• Configuration: plugins.slots.memory + plugins.allow both include the plugin

Possible Cause

The plugin might be registered/loaded twice due to overlapping configuration triggers (plugins.allow + plugins.slots.memory), or the service.start() lifecycle hook is not properly checking if the viewer is already running before attempting to start it again.

[prospect1314521]

Additional Bug: workspaceDir fallback causes EPERM error on Windows

When opts.workspaceDir is not passed to initPlugin(), the code falls back to process.cwd():

// src/index.ts line 55
const workspaceDir = opts.workspaceDir ?? process.cwd();

Problem: When OpenClaw gateway starts, the current working directory may be C:\Windows\System32. This causes SkillInstaller.workspaceSkillsDir to resolve to C:\Windows\System32\skills, and attempting to create skill folders there triggers:

EPERM: operation not permitted, mkdir 'C:\Windows\System32\skills\troubleshoot-openspace-cloud-connection'

Fix: Change the fallback to path.join(stateDir, "workspace") instead of process.cwd(), ensuring it always points to ~/.openclaw/workspace regardless of the launch directory.

[prospect1314521]

Additional Context: Port leak triggered by /new command

Every time the user executes the /new command (creating a new session), the plugin attempts to start a new Viewer instance instead of reusing the existing one.

This causes the port to increment continuously:

Viewer port 18799 in use, trying 18800
Viewer port 18800 in use, trying 18801
Viewer port 18801 in use, trying 18802

Root cause: The plugin does not properly check if a Viewer is already running before attempting to start a new one. The service.start() lifecycle hook or the self-starting fallback is triggered on every new session, rather than only once during plugin initialization.

[fevenor]

For 2026.4.2, the openclaw doctor command also start a new MemOS instance and causes the doctor execution to hang.

[prospect1314521]

Yes! I also experienced this issue. Because I use AI for troubleshooting, the AI runs standard troubleshooting procedures every time, and gets stuck whenever it runs Doctor-related commands (like openclaw plugins doctor)! I have to explicitly tell it not to run this command!

[prospect1314521]

I looked into the root cause: openclaw plugins doctor connects to the running OpenClaw gateway, which triggers full plugin initialization. Plugins like memos-local start persistent background services (e.g., an HTTP Viewer server). Because these services are designed to run continuously, the doctor command never exits and hangs indefinitely.

It's an architecture issue in OpenClaw's CLI where doctor triggers the full plugin lifecycle instead of just doing a lightweight config check. I've opened an issue on their repo to get it fixed.

[prospect1314521]

Here's a temporary workaround if you need to run openclaw plugins doctor without it hanging:

Temporary Workaround

1. Temporarily disable the memos plugin by editing ~/.openclaw/openclaw.json:

"plugins": {
  "allow": [
    "openclaw-lark"
  ],
  "slots": {}
}

(Remove "memos-local-openclaw-plugin" from allow and clear the slots.memory field)

2. Run doctor:

openclaw plugins doctor

3. Restore the config afterwards:

"plugins": {
  "allow": [
    "openclaw-lark",
    "memos-local-openclaw-plugin"
  ],
  "slots": {
    "memory": "memos-local-openclaw-plugin"
  }
}

Root Cause

The doctor command triggers full plugin initialization, which starts the persistent Viewer server. OpenClaw's CLI architecture doesn't have a "read-only diagnostic mode" for plugins yet.

Tracking issue on OpenClaw repo: openclaw/openclaw#61283

[prospect1314521]

You can try this config:

"memorySearch": {
  "enabled": false
}

This disables OpenClaw's built-in memory search. With it off, the frontend should only open once on your first conversation instead of repeatedly. The checker should also stop hanging after this. Worth a try.

[prospect1314521]

You should really try this! After disabling memorySearch and switching the summarizer to a lighter model (since skillEvolution can use a better model, I downgraded the summarizer), my speed improved by 100x! Not exaggerating — it used to be incredibly slow, and now it's so fast that I'm actually hitting API rate limits regularly.