Self-hosted v0.0.5: API key auth broken — 401 "Either userId or orgId not found" even with banner key

[dupenodi]

Environment

• OS: macOS arm64 (darwin-arm64)
• supermemory-server: upgraded v0.0.3 → v0.0.5 via supermemory-server upgrade
• Bun: v1.3.4
• Data dir: custom SUPERMEMORY_DATA_DIR (project-local .supermemory/)
• LLM: GEMINI_API_KEY in ~/.supermemory/env (unrelated to this bug)

Steps to reproduce

1. Start from a working self-hosted install on v0.0.3 (auth works: POST /v3/documents/list with the banner API key returns 200).
2. Run supermemory-server upgrade (lands on v0.0.5).
3. Restart the server against the same SUPERMEMORY_DATA_DIR.
4. Copy the api key from the startup banner (or from $SUPERMEMORY_DATA_DIR/api-key).
5. Call an authenticated route, e.g.:

curl -sS -X POST http://localhost:6767/v3/documents/list \
  -H "Authorization: Bearer <banner-api-key>" \
  -H "Content-Type: application/json" \
  -d '{}'

Expected behavior

Same as v0.0.3 and the self-hosting docs: the API key printed at boot (stored in $SUPERMEMORY_DATA_DIR/api-key) authenticates Bearer requests. POST /v3/documents/list returns 200.

Actual behavior

Every authenticated API call returns 401:

{"error":"Unauthorized","details":"Either userId or orgId not found. Are you using the right API key?"}

The server is unusable post-upgrade. The startup banner still prints the key and still says it is “auto-applied for unauthenticated localhost requests.”

Error messages / logs

v0.0.5 also prints this on startup (not present on v0.0.3):

[better-auth/magic-link] `allowedAttempts` is ignored: tokens are consumed
atomically on the first verification call (GHSA-hc7v-rggr-4hvx). Any value
other than `1` has no effect; remove the option to silence this warning.

Note: better-auth / this error string already exist inside the v0.0.3 binary, so this may be a dependency-bump warning rather than a brand-new auth stack. The functional regression is real either way.

Additional context (ruled out)

1. Wrong API key — compared programmatically: .env value, on-disk api-key, and startup banner key all match exactly.
2. Wrong data directory — reproduced against the correct SUPERMEMORY_DATA_DIR.
3. Stale migrated auth state:
   • Deleted auth-secret only, let it regenerate, restarted → still 401.
   • Deleted api-key too (fresh key; org id preserved from instance-id) → still 401.

A brand-new API key still being rejected rules out a one-off migration artifact. Likely cause: v0.0.5 API-key → user/org middleware no longer attaches those values; the route gate (if (!userId || !orgId) return 401) is unchanged from v0.0.3.

Workaround: pin/downgrade to v0.0.3 (installer already supports this; docs PR #1238):

curl -fsSL https://supermemory.ai/install | bash -s -- 0.0.3

Existing $SUPERMEMORY_DATA_DIR data was preserved; no wipe needed. Avoid supermemory-server upgrade until this is fixed.

v0.0.5 release notes (“Pluggable embeddings for self-hosted”) do not mention an auth migration.

Happy to provide more logs or retest a fixed build.

[linear-code]

ENG-1035

[haydenfd]

+1