Troubleshooting
Resolve macOS quarantine, Photos permissions, Gemini errors, backend startup, indexing failures, port conflicts, and resets.
Start with the smallest check that matches the symptom. The desktop app’s status indicator should be green, and this request should return JSON:
curl http://127.0.0.1:7242/status“MemSearch is damaged and can’t be opened”
Current releases are not notarized. If you downloaded MemSearch from the project’s Releases page, clear the quarantine attribute once:
xattr -cr /Applications/MemSearch.appUse the real path if the app is not under /Applications. Then open it normally.
Photos access denied
- Open System Settings → Privacy & Security → Photos.
- Enable access for MemSearch.
- Quit and reopen MemSearch if the permission list does not update.
- Select Index Photos again.
The current backend accepts full authorized status. Limited or denied access can produce a 403 response.
If people are missing but image indexing works, name the people in Photos and use Refresh People. Confirm that the configured library contains:
database/Photos.sqliteInvalid, expired, or rate-limited Gemini key
Search maps common Gemini failures to local 503 responses:
| Detail | Likely cause | Action |
|---|---|---|
| API access denied / 403 | Invalid, revoked, restricted, or unauthorized key | Create/check the key in Google AI Studio, then save it in Status |
| Model not found / 404 | Configured preview model was renamed or unavailable | Verify MEMSEARCH_EMBEDDING_MODEL; rebuild the index if you change it |
| Rate limited / 429 | Gemini quota or request-rate limit | Wait and retry; lower concurrency for repeated indexing failures |
| Generic embedding API error | Network, account, request, or service issue | Read the detailed response/log and test again |
Saving a key in the desktop Status page writes it to Electron Store and restarts the backend. The onboarding field only checks that the value is non-empty, so a bad key may surface later during the first index or search request.
Backend disconnected or reconnecting
The desktop app health-checks http://127.0.0.1:7242/status. During a deliberate restart it may show Reconnecting to backend… before it displays a hard error.
- Wait through first-run dependency setup; the first launch allows up to 120 seconds.
- Select Restart Backend from the Status error panel.
- Confirm the log path shown below.
- Confirm nothing else owns port 7242.
- Verify that the packaged app contains its backend resources, or that source development has
backendbesideelectron.
An unexpected backend exit after reaching ready state triggers one automatic restart after two seconds.
First-run dependency setup fails
The desktop app searches these uv locations:
app bundle resources/bin/uv
~/.local/bin/uv
~/.cargo/bin/uv
/usr/local/bin/uv
/opt/homebrew/bin/uvIf none exists, it runs the official installer. Install manually when that step fails:
curl -LsSf https://astral.sh/uv/install.sh | shThen reopen MemSearch. For a source checkout, verify independently:
cd backend
uv sync
uv run memsearch statusThe packaged app puts its writable Python environment at:
~/Library/Application Support/MemSearch/venvIf that environment is incomplete, quit the app, move the directory aside as described under reset procedures, and relaunch.
Port 7242 is already in use
Inspect the listener:
lsof -nP -iTCP:7242 -sTCP:LISTENDo not run a source memsearch serve process at the same time as the Electron desktop backend. Current Electron startup evicts a process already answering on port 7242 before it launches the managed server.
For a standalone source server, choose another loopback port:
MEMSEARCH_PORT=7243 uv run memsearch serveUpdate the Raycast Backend URL accordingly. The current Electron renderer is hard-coded to port 7242, so changing the backend port is not a desktop-app workaround.
Indexing reports failures or skips everything
Check these conditions:
- The folder exists and the current process can read it.
- Files use a supported extension.
- Files are not empty or above
MEMSEARCH_MAX_FILE_SIZE_MB. - A path component is not hidden,
node_modules,.git,__pycache__,.DS_Store, orThumbs.dbunder the default exclusions. - The file is actually newer than the stored entry; unchanged items are expected to be skipped.
- PDF or image files are not corrupt.
- Gemini is reachable and the key has quota.
- ChromaDB and thumbnail directories are writable.
File status retains up to 100 detailed errors. Photos status exposes the first embedding failure and the latest result briefly after a run.
Photos indexing appears stuck
The current asset string identifies phases such as scanning, checking existing photos, downloading, and embedding. An iCloud asset request can block while PhotoKit downloads the original.
- Confirm network access and Photos sync.
- Wait for the current download.
- Use Stop Indexing; the desktop restarts the backend because PhotoKit cancellation is not always prompt.
- Retry. Already written assets remain and unchanged assets are skipped.
Search returns no results
- Check that Status has items in the chosen modality.
- Select All Types.
- Try a shorter, concrete query.
- Remove incorrect
@personfilters. - Refresh people after renaming faces in Photos.
- Re-index the source after changes.
- Check for a Gemini error; every query must be embedded before local comparison.
Raycast cannot connect
Use http://localhost:7242 or http://127.0.0.1:7242 as the extension’s Backend URL and confirm /status with curl. Start the desktop app or uv run memsearch serve. See the full Raycast troubleshooting guide.
Logs
The desktop-managed backend appends logs here:
~/Library/Application Support/MemSearch/logs/backend.logWatch recent lines while reproducing a problem:
tail -f "$HOME/Library/Application Support/MemSearch/logs/backend.log"The file can contain local paths, filenames, dates, and service error text. Review it before sharing.
Source runs print directly to the terminal unless you redirect them.
Reset procedures
Clear search data only
Use the confirmed desktop action, or:
cd backend
uv run memsearch clearThis preserves configuration, the API key, logs, and source files.
Reset backend UI-managed settings
Quit MemSearch, preserve a backup, and relaunch:
mv "$HOME/Library/Application Support/MacMemorySearch/config.json" \
"$HOME/Library/Application Support/MacMemorySearch/config.json.backup"Environment variables still override defaults after this reset.
Rebuild the desktop Python environment
Quit MemSearch and move the environment aside:
mv "$HOME/Library/Application Support/MemSearch/venv" \
"$HOME/Library/Application Support/MemSearch/venv.backup"The next launch recreates it and may take up to two minutes.
Reset onboarding and the stored key
Quit MemSearch, then move the Electron Store file aside:
mv "$HOME/Library/Application Support/MemSearch/config.json" \
"$HOME/Library/Application Support/MemSearch/config.json.backup"On the next launch, onboarding runs again. This also removes the active Electron settings file containing the plaintext Gemini key; the .backup still contains that sensitive value until you secure or remove it.
Backups remain sensitive
The commands above are recoverable because they move data instead of deleting it. Backup files can still contain configuration or the Gemini key and should be protected accordingly.
Full index-directory reset
If ChromaDB is damaged and the normal clear command cannot run, quit every Memsearch process and move the local index and thumbnail directories aside:
mv "$HOME/Library/Application Support/MacMemorySearch/chroma" \
"$HOME/Library/Application Support/MacMemorySearch/chroma.backup"
mv "$HOME/Library/Application Support/MacMemorySearch/thumbnails" \
"$HOME/Library/Application Support/MacMemorySearch/thumbnails.backup"Relaunch and re-index. Source files and Photos assets are unaffected.