~/github/rlai master*
❯ npx supermemory local
npm notice run npx
npm notice run 'supermemory' local
██████ ██ ██ ██████ ███████ ██████ ███ ███ ███████ ███ ███ ██████ ██████ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ████ ████ ██ ████ ████ ██ ██ ██ ██ ██ ██
█████ ██ ██ ██████ █████ ██████ ██ ████ ██ █████ ██ ████ ██ ██ ██ ██████ ████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██████ ██████ ██ ███████ ██ ██ ██ ██ ███████ ██ ██ ██████ ██ ██ ██
local · self-hosted · running on this machine
◆ encrypted local storage /home/culex/github/rlai/.supermemory
✗ startup failed
Could not unlock local storage at /home/culex/github/rlai/.supermemory/data.
The data is almost certainly intact — this is a key mismatch, not corruption.
The key is derived from this machine's stable id, so the usual cause is a
changed runtime environment rather than changed data:
• the service runs without /usr/sbin on PATH, so macOS can't read the
hardware id (common under launchd) and an older build keyed off the hostname
• the machine's hostname changed, or the data was moved to another machine
Try this first — it is non-destructive:
• run on the original machine, as the original user
• make sure /usr/sbin is on PATH (macOS reads the hardware id via ioreg there)
Only if you accept losing this data, back it up before starting fresh:
mv /home/culex/github/rlai/.supermemory /home/culex/github/rlai/.supermemory.bak
details also written to /home/culex/github/rlai/.supermemory/error.log
supermemory derives the encryption key from /etc/machine-id. The flow is:
Read /etc/machine-id (33 bytes)
Pipe it through pw6() which XORs it with a hardcoded byte array, then PBKDF2-derives a key
The derived key is used for AES-256-GCM encryption of the data file
The issue is likely that your /etc/machine-id hasn't changed — modified Feb 9, 2026.
The env.enc file IS the encrypted configuration (your API key, auth secret, etc.), and the data/ file is the encrypted PGLite database. The unlock error comes from trying to decrypt the data file when the server starts, using the key derived from reading env.enc which is encrypted with a different key.
So the real question is: what key was env.enc encrypted with, and why doesn't it match what the server derives today?****
0.0.5
CachyOS