What's happening
The plugin reads its config from ~/.config/opencode/supermemory.jsonc first and falls back to supermemory.json, and the README tells users to create the .jsonc file. The CLI (install and status), however, only ever looks at supermemory.json. So for anyone whose config lives in supermemory.jsonc:
status contradicts itself. The key is loaded and works (Connected: yes), but the source is reported as not configured. Someone debugging auth is told they have no key while it's working, and isn't told which file to edit.
install creates a second config file. Because it can't see the .jsonc, it treats the setup as a fresh install and writes a new supermemory.json containing a copy of the API key (comments stripped) plus different settings (recallMode: "direct", captureEveryNTurns: 0). Those settings never take effect because .jsonc wins, so the user ends up with two configs that disagree and a second plain-text copy of their key.
Why it matters
This is the README's own headless setup path (Step 1 install → Step 3 create supermemory.jsonc → Step 4 status), so users following the docs exactly land on the misleading not configured at the verification step. Re-running install later (e.g. to upgrade) then duplicates the key into supermemory.json.
It doesn't break memory recall or capture inside OpenCode (the plugin loads the right file), and users who authenticate with login or SUPERMEMORY_API_KEY aren't affected. Impact is confusion while debugging plus an unexpected extra copy of the API key on disk.
Reproduce
Sandboxed HOME and a fake key, so nothing real is touched. Reproduced with the published 2.0.15 on Linux (WSL2 Ubuntu 24.04) and Windows 11:
export HOME=$(mktemp -d); unset SUPERMEMORY_API_KEY
mkdir -p ~/.config/opencode
printf '{\n // per README\n "apiKey": "sm_test_key_1234"\n}\n' > ~/.config/opencode/supermemory.jsonc
bunx opencode-supermemory@latest status | grep "API key"
bunx opencode-supermemory@latest install --no-tui > /dev/null
ls ~/.config/opencode/ | grep supermemory
cat ~/.config/opencode/supermemory.json
Actual
API key: sm_tes...1234 (not configured)
supermemory.json
supermemory.jsonc
{
"apiKey": "sm_test_key_1234",
"recallMode": "direct",
"captureEveryNTurns": 0
}
Expected
API key: sm_tes...1234 (~/.config/opencode/supermemory.jsonc)
supermemory.jsonc
Cause
src/config.ts loads supermemory.jsonc before supermemory.json, but exports CONFIG_FILE = CONFIG_FILES[1], which is always supermemory.json.
install uses that path to decide "existing vs. fresh install" (cli.ts:419) and writeInstallDefaults writes there with JSON.stringify, dropping comments.
status → getKeySource() (cli.ts:535-547) reads only that path, with plain JSON.parse, so a .json containing comments isn't recognised either.
Workaround for affected users
If you have both files, delete ~/.config/opencode/supermemory.json; supermemory.jsonc is the one the plugin uses.
What's happening
The plugin reads its config from
~/.config/opencode/supermemory.jsoncfirst and falls back tosupermemory.json, and the README tells users to create the.jsoncfile. The CLI (installandstatus), however, only ever looks atsupermemory.json. So for anyone whose config lives insupermemory.jsonc:statuscontradicts itself. The key is loaded and works (Connected: yes), but the source is reported asnot configured. Someone debugging auth is told they have no key while it's working, and isn't told which file to edit.installcreates a second config file. Because it can't see the.jsonc, it treats the setup as a fresh install and writes a newsupermemory.jsoncontaining a copy of the API key (comments stripped) plus different settings (recallMode: "direct",captureEveryNTurns: 0). Those settings never take effect because.jsoncwins, so the user ends up with two configs that disagree and a second plain-text copy of their key.Why it matters
This is the README's own headless setup path (Step 1
install→ Step 3 createsupermemory.jsonc→ Step 4status), so users following the docs exactly land on the misleadingnot configuredat the verification step. Re-runninginstalllater (e.g. to upgrade) then duplicates the key intosupermemory.json.It doesn't break memory recall or capture inside OpenCode (the plugin loads the right file), and users who authenticate with
loginorSUPERMEMORY_API_KEYaren't affected. Impact is confusion while debugging plus an unexpected extra copy of the API key on disk.Reproduce
Sandboxed
HOMEand a fake key, so nothing real is touched. Reproduced with the published 2.0.15 on Linux (WSL2 Ubuntu 24.04) and Windows 11:Actual
Expected
Cause
src/config.tsloadssupermemory.jsoncbeforesupermemory.json, but exportsCONFIG_FILE = CONFIG_FILES[1], which is alwayssupermemory.json.installuses that path to decide "existing vs. fresh install" (cli.ts:419) andwriteInstallDefaultswrites there withJSON.stringify, dropping comments.status→getKeySource()(cli.ts:535-547) reads only that path, with plainJSON.parse, so a.jsoncontaining comments isn't recognised either.Workaround for affected users
If you have both files, delete
~/.config/opencode/supermemory.json;supermemory.jsoncis the one the plugin uses.