README describes recall and config behavior the plugin no longer has

[Chebaleomkar]

Summary

I went through every claim in the README and checked it against the code on main (dee043f). Most of it is accurate, but several sections describe behavior from before recall moved to direct mode and containers were unified. The most important ones affect what users expect the agent to see. Line numbers below refer to README.md and src/ on main.

What the plugin actually injects (high impact)

1. Features, "Context injection" (L128) says the first message injects "your profile, all project knowledge, and (if autoRecallEveryPrompt is on) a semantic search over personal memories". It injects only the profile (static facts plus "Recent Context"): both callers pass empty results to formatContextForPrompt (src/index.ts:229, src/v2/runtime.ts:950).
2. Features, "Reasoned recall" (L128) describes advisory mode ("the agent is shown a directive... searches only when it decides to"). The default is direct (src/config.ts:72), which the README's own "Direct Recall" section (L150) describes correctly, so the page contradicts itself.
3. Example output (L133-146) shows Project Knowledge: and Relevant Memories: sections that are never produced. The real first-message block has ◪ markers and Recent Context: (src/services/context.ts), and direct recall injects a separate <supermemory-context> block (src/services/recall.ts:115).
4. autoRecallEveryPrompt (L332-335) is described as adding a first-message personal search. It is now only a legacy switch that maps to recallMode when that is unset (src/config.ts:116-117). CONFIG.autoRecallEveryPrompt itself is never read.
5. In-chat commands (L42-44) list /supermemory-init as the in-chat install. It's the codebase-index alias (src/cli.ts:340), and the README says so correctly in three other places. There is no in-chat install.

Config and tool reference (medium)

6. maxMemories, "Max memories injected per request": direct recall is hard-capped at 5 (MAX_RECALL_RESULTS, src/services/recall-results.ts:4). maxMemories is the per-search limit (src/services/client.ts:255).
7. maxProjectMemories, "Max project memories listed": only used for compaction (src/services/compaction.ts:230, src/v2/runtime.ts:991).
8. supermemory tool: search accepts limit (src/services/memory-tool.ts:198), and without a scope it searches both personal and project memories (:217-227). The README says project is the default for all modes. The tool's own help output also omits limit for search (:99).
9. Container override precedence. The README presents projectContainerTag as the override and says SUPERMEMORY_REPO_TAG is "checked before the config value". getProjectTag (src/services/tags.ts:280) actually checks six sources: .claude/.supermemory-claude/config.json, then SUPERMEMORY_REPO_TAG, then the Cursor config, then projectContainerTag, then ~/.codex/supermemory.json, then the generated tag. So a Claude Code or Cursor project config silently overrides projectContainerTag, and nothing in the docs says so.
10. SUPERMEMORY_DEBUG, "enable debug logging": it only appends the [recall-decision] instruction in advisory mode (src/services/recall.ts:38). Logging is always on.
11. The generated /supermemory-login command says "Start a local server on port 19877" (src/cli.ts:212), but the port is random (src/services/auth.ts:156). That text is written into users' command files, so agents repeat it.

Gaps (low)

12. filterPrompt is a supported key (src/config.ts:29) but isn't documented. Worth confirming as intended: when the client connects, the plugin calls settings.update({ shouldLLMFilter: true, filterPrompt }) (src/services/client.ts:170), so it changes the user's Supermemory settings. It would help if the docs said so.
13. The captureEveryNTurns default isn't stated. It's 0 on fresh installs, and 3 when a config file exists but omits the key (src/config.ts:201-204).
14. The LLM-agent Step 1 (L58-66) says install "creates the /supermemory-index command" and then repeats itself. It creates five commands and also writes tui.jsonc and the Supermemory config file.

Checked and accurate

Installation commands, the Direct Recall section (5 results, 3 s fail-open, short prompts skipped, per-session dedupe), capture cadence and lifecycle events, privacy redaction, keyword detection, memory types, OpenCode 2 plugin ids and log lines, the other env vars, and the Oh My OpenCode flag.

Suggestion to prevent drift

Most of this crept in when behavior changed (direct recall, unified containers, OpenCode 2) without the Features table and config comments being updated. Two lightweight guards could help, and I'm happy to follow up if they're wanted:

• A small bun test that checks the README's config keys and defaults, tool modes and types, env var table, and command list against the source of truth in code.
• Running typecheck and bun test on pull requests. Today they only run inside the release workflow when the version changes.