Code Pluginsource linked

Gralkor Memory (OpenClaw)v4.0.4

OpenClaw memory plugin powered by Gralkor (Graphiti + FalkorDB). Installs a plugin that supervises the Gralkor Python server and wires its HTTP API into OpenClaw hooks and tools.

@gralkor/openclaw·runtime @gralkor/openclaw·by @gralkor
Community code plugin. Review compatibility and verification before install.
openclaw plugins install clawhub:@gralkor/openclaw
Latest release: v4.0.4Download zip

Capabilities

configSchema
Yes
Executes code
Yes
HTTP routes
0
Plugin kind
memory
Runtime ID
@gralkor/openclaw

Compatibility

Built With Open Claw Version
2026.5.7
Plugin Api Range
>=2026.5.7
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Suspicious
high confidence
!
Purpose & Capability
The core purpose is coherent: persistent graph-backed memory with recall, capture, and manual memory tools. However, it automatically captures conversation turns, serializes intermediate tool activity, indexes workspace memory files, and sends memory/transcript content to configured LLM providers, which is powerful and privacy-sensitive.
!
Instruction Scope
The README discloses the main hooks and tools, but the artifact also contains a comment saying code was split so scanners do not see environment access near fetch, which is a concrete transparency concern. Tool-call arguments and tool results are included in captured behavior without evident redaction.
!
Install Mechanism
The plugin supervises a bundled Python FastAPI server, runs uv to sync dependencies, and may download an architecture-specific wheel from GitHub Releases at runtime without an in-artifact checksum or signature check. That is purpose-related but supply-chain sensitive.
!
Credentials
Starting a local server and passing provider API keys are expected for this plugin, but the subprocess inherits the full parent environment and the server manager can kill any process holding its configured port or matching a redislite redis-server argv pattern. Those controls are broader than the plugin's ownership boundary.
!
Persistence & Privilege
Persistent storage is the plugin's purpose, and dataDir is operator-configured, but automatic long-term capture and workspace memory-file indexing can persist sensitive prompts, tool parameters, local notes, or proprietary content unless the user has carefully scoped their workspace and logging settings.
Scan Findings in Context
[SDI-4] unexpected: Accepted as a material transparency concern: the file explicitly says the env-building code was separated to prevent install-time scanners from correlating process.env and fetch.
[SSD-2] unexpected: Accepted in substance for the same artifact-backed reason: the scanner-avoidance comment is not needed for memory functionality and weakens trust even though the surrounding behavior is otherwise disclosed.
[SDI-2] unexpected: Accepted for process termination scope: killing any listener on the port and any matching redislite redis-server process is broader than stopping only plugin-owned children.
[SDI-2] expected: Partially accepted for runtime wheel retrieval: downloading a compatibility wheel is purpose-related for the managed server, but lack of checksum or signature verification makes installation riskier than a fully bundled or pinned artifact.
[SQP-2] expected: Mostly purpose-aligned: conversation capture, recall injection, provider calls, and workspace memory indexing are central to a memory plugin and are described in the README, but redaction, consent, and retention controls are not strong enough for sensitive environments.
[SQP-2] unexpected: Accepted for verbose/test logging and raw config logging: the manifest discloses verbose test mode, but logging full config or episode/search data can expose API keys or sensitive memory content if enabled.
[SC1] expected: Low-weight finding: loose dev dependency ranges affect reproducibility but do not materially change the runtime security verdict.
[SC4] expected: Relevant supply-chain signal: graphiti-core is a core dependency and the project uses a frozen lock, but the requirements allow a broad range, so users should verify the resolved version is patched for their deployment.
[staticScan:suspicious.dangerous_exec] expected: Downgraded from the static label: spawning uvicorn is expected for this plugin's managed Python server, but it contributes to the overall Review verdict because the server manager also performs broad process cleanup.
[staticScan:suspicious.exposed_secret_literal] expected: Overridden as a false positive for hardcoded secret exposure: the code maps user-supplied config values into environment variables; it does not contain a literal API key in the inspected artifact.
[VirusTotal] expected: Clean telemetry from 62 engines is supportive but not decisive; the Review verdict is based on artifact behavior, not VirusTotal.
What to consider before installing
Install only after reviewing the data flow and operating it in a controlled environment. Use a dedicated dataDir, provide only the API keys required, keep test mode off, avoid storing secrets in prompts or MEMORY.md files, and be aware it can start local services, install Python dependencies, download a wheel on some platforms, and terminate processes that conflict with its port or redislite runtime.
dist/gralkor/server-manager.js:109
Shell command execution detected (child_process).
dist/config.js:39
File appears to expose a hardcoded API secret or token.
Patterns worth reviewing
These patterns may indicate risky behavior. Check the VirusTotal and OpenClaw results above for context-aware analysis before installing.

Verification

Tier
source linked
Scope
artifact only
Summary
Validated package structure and linked the release to source metadata.
Commit
ee0984bd9bd5
Tag
v4.0.4
Provenance
No
Scan status
suspicious

Tags

latest
4.0.4

@gralkor/openclaw

OpenClaw memory plugin powered by Gralkor — a temporally-aware knowledge-graph memory service (Graphiti + FalkorDB). This package is the OpenClaw harness: it embeds the Gralkor TypeScript adapter (src/gralkor/) and the Gralkor Python FastAPI server (server/, bundled in the npm tarball), supervises that server under OpenClaw's managed-service lifecycle, wires the HTTP API into OpenClaw hooks, and exposes memory_search, memory_add, memory_build_indices, and memory_build_communities as tools.

The adapter and server used to live in the now-deprecated @susulabs/gralkor / @susulabs/gralkor-ts packages; they are embedded here, so installing @gralkor/openclaw pulls everything in one package — no external Gralkor dependency.

Compatibility

Requires OpenClaw >= 2026.5.7. Two loader behaviours matter:

  • The 2026.5.7 loader gates tool registration on the manifest's contracts.tools field — declared in openclaw.plugin.json.
  • The loader exposes capability handlers (registerTool / hooks / registerService) in full, discovery, and tool-discovery registration modes, and the tool-discovery pass is the one that builds the agent's tool-dispatch map. The plugin registers its tools/hooks in all three of those modes (the uvicorn server service is started only in full).

Older builds that registered tools only in full mode loaded but their tools resolved to "tool not found"; they are not supported.

Install

openclaw plugins install @gralkor/openclaw --dangerously-force-unsafe-install

(The install-time security scanner flags Gralkor as critical because this plugin spawns a bundled Python server. Inspect server/ if you'd like to verify there's nothing weird going on.)

Then configure before enabling — the plugin id is @gralkor/openclaw, so config keys carry the full scoped name:

openclaw config set plugins.entries.'"@gralkor/openclaw"'.config.dataDir /path/to/gralkor-data
openclaw config set plugins.entries.'"@gralkor/openclaw"'.config.googleApiKey 'your-key-here'   # or OPENAI/ANTHROPIC/GROQ
openclaw config set plugins.entries.'"@gralkor/openclaw"'.config.agentName 'YourAgent'

openclaw config set --json plugins.allow '["@gralkor/openclaw"]'
openclaw config set plugins.entries.'"@gralkor/openclaw"'.enabled true
openclaw config set --json plugins.entries.'"@gralkor/openclaw"'.hooks.allowConversationAccess true
openclaw config set plugins.slots.memory '@gralkor/openclaw'

hooks.allowConversationAccess: true is required — without it OpenClaw blocks the plugin's agent_end hook and memory capture stops after each turn.

The @ and / in the plugin id make openclaw config set's bracket parsing brittle; the canonical way to set these keys is a direct write to openclaw.json (this is what the agents deployment's init.sh does). See agents/agent/init.sh for the reference flow.

Restart OpenClaw. First boot takes 1–2 min while uv sync resolves Graphiti + falkordblite; subsequent starts reuse the venv.

What this plugin does

Three hooks + four tools, all fed by the embedded Gralkor HTTP server:

  • before_prompt_build — registers the session's group, scans workspace memory files for new content (MEMORY.md, memory/*.md), and auto-recalls relevant facts which get injected into the prompt.
  • agent_end — posts the just-finished turn to /capture as a canonical [{role, content}] message list (user → behaviour(s) → assistant). The Gralkor server owns the capture buffer and flushes on idle or on explicit session-end. OpenClaw-specific filtering happens here: harness-internal sub-agent runs (e.g. sessionKey === "temp:slug-generator") and synthetic turns (the /new//reset meta-prompt) are skipped, and Conversation info / Sender (untrusted metadata) envelope blocks are stripped from the user message before capture.
  • session_end — posts /session_end to flush the session's buffer now instead of waiting for the idle window.
  • memory_search tool — calls the same POST /recall path as the before_prompt_build hook. There is no separate slow-search endpoint: manual and auto lookups do identical server work.
  • memory_add toolPOST /tools/memory_add. Fire-and-forget; the server queues the add for async Graphiti extraction.
  • memory_build_indices / memory_build_communities tools — operator-maintenance actions (rebuild graph search indices; run community detection). Not for routine use — the tool descriptions tell the agent not to call them unprompted.

Session and group identity

  • session_id is OpenClaw's sessionKey — required at every boundary. Hooks and tools throw synchronously if ctx.sessionKey is missing or blank; there is no "default" bucket. (OpenClaw's argument shape for hooks and tool factories is documented in OPENCLAW_INTEGRATION_2026-04-02.md.)
  • group_id is the sanitised agentId (hyphens replaced with underscores — a RediSearch constraint). Per-agent graph partition; agents never see each other's memory.

Every hook and tool derives group_id independently from its own ctx.agentId (sanitizeGroupId(agentId ?? sessionKey)) at the register boundary — there is no shared session→group map. Recall, capture, search, and add therefore target the same per-agent partition regardless of invocation order or which Node process handles the turn, so a tool call never depends on before_prompt_build having run first.

Configuration

Set under plugins.entries["@gralkor/openclaw"].config in ~/.openclaw/openclaw.json. See openclaw.plugin.json for the full schema; the useful knobs are:

  • agentName (required) — display name labelling this agent's turns in stored and recalled memory.
  • dataDir (required) — writable directory for the Python venv + FalkorDB database.
  • search.maxResults — cap on facts returned by the memory_search tool.
  • llm / embedder — provider + model override (defaults: Gemini).
  • googleApiKey / openaiApiKey / anthropicApiKey / groqApiKey — one is required.
  • interpretMaxOutputTokens — output-token budget for the server's interpret pipeline on each recall (unset → server default of 2000).
  • test (default: false) — verbose server-side logging.

Testing

Unit tests use GralkorInMemoryClient from the embedded src/gralkor/testing.ts — real behaviour, no network, no Python. Full suite runs via pnpm test (typecheck + vitest unit + Python pytest under server/).

Development

pnpm install
pnpm run build
pnpm run test
openclaw plugins install -l .   # link this local checkout

License

MIT.