Corrupted file making MCP fail to start after 0.10.2 update through powershell

Version

0.10.2

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

After I updated to 0.10.2, it was failing to start in grok build. Luckily i tasked GB on finding what happened, it located the problem, fixed it, which instantly fixed MCP memory and allowed it to start again

Hopefully that picture actually loads because thats its explanation of how it fixed it.

Reproduction

Update from 0.9 to 0.10.2 in powershell with the update command.

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

I searched existing issues and this is not a duplicate.
My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

@KeanuPwnsU

Thanks for flagging this @KeanuPwnsU — a start failure right after a 0.10.2 update is exactly what we want to hear about fast, and we'd like to fix it properly rather than guess.

Unfortunately the screenshot is the only description of what was wrong, and we can't tell from it which file was corrupted or how. Could you share, when you get a chance:

Which file the fix touched (full path) — from the assistant's explanation in that image.
What was wrong with it — truncated, empty, wrong encoding, wrong contents?
The output of codebase-memory-mcp doctor (or any error text the MCP client showed at startup).
Whether the update was run as powershell -ExecutionPolicy Bypass -File "<install-dir>\install.ps1" or some other path.

Two candidates we'd check first, both of which your details would confirm or eliminate: a config/state file left half-written by the 0.9 → 0.10.2 transition, or a PowerShell encoding issue in a generated file. If you still have the broken copy, that alone would likely be conclusive.

Marking awaiting-reporter while we wait — a comment reopens it any time.

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

the codebase-memory-mcp --version you're on
the exact steps or command you ran
a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

codebase-memory-mcp v0.10.2 startup failure — reporter notes for DeusData

Reporter: KeanuPwnsU (Jacob)
OS: Windows 10/11 (hostname DESKTOP-XAWRS9A)
Product version after update: codebase-memory-mcp 0.10.2
Build fingerprint (from daemon / logs): f1222762211789d45b1adfa08fe6aef4ee3947a1d45861b5ce2d82f3c4147005
MCP client: Grok Build (xAI) via ~/.grok/config.toml
Date of failure: 2026-08-11 (evening local)
Status of broken artifact: Fixed in place — the original broken NTFS ACL state was repaired; we do not still have an unmodified “broken copy” of _config.db unless something was snapshotted outside this machine. File size/timestamps of the same path after fix are recorded below.

This document answers the maintainer questions on the GitHub issue so the root cause can be confirmed or eliminated without guessing from a screenshot.

1. Short answer (what was actually wrong)

Question	Answer
Which file did the fix touch?	`C:\Users\Jacob\.cache\codebase-memory-mcp\_config.db`
What was wrong with it?	Not truncated, not empty, not wrong encoding. The SQLite file existed (~12 KB) but had empty / missing NTFS ACLs so no principal could open it. Result: Windows `Access Denied` → CLI error `cannot open config database` → daemon never became ready within 30s → MCP client timed out.
`codebase-memory-mcp doctor`?	No `doctor` subcommand in 0.10.2 help output. Running `codebase-memory-mcp doctor` produced no stdout and exit code 0 (likely not a real diagnostic command on this build). Use the error/CLI outputs below instead.
How was the update run?	Not fully known from the assistant session. User reported updating to 0.10.2 (installer mentioned deleting indexes / reindex on restart). Exact invocation (`install.ps1` vs `update` vs double-click vs other) should be filled in by reporter if remembered (section 6).

Two candidates from maintainers:

Config/state half-written by 0.9 → 0.10.2 — Partially consistent. _config.db was recreated around update time; project index DBs were gone (only orphaned -shm/-wal). The decisive failure mode we hit was permissions on _config.db, not obviously corrupt SQLite payload (after ACL fix, config list and daemon start succeeded without rewriting the DB bytes).
PowerShell encoding issue in a generated file — Not observed. No evidence of a mangled .ps1 / UTF-16 script / bad BOM as the hang cause. Binary was fine (--version worked). Failure was open(config DB) denied.

2. Environment / install layout

Active binary (what Grok was configured to start)

Path:   C:\Users\Jacob\.local\bin\codebase-memory-mcp.exe
Size:   296090624 bytes
MTime:  2026-08-11 6:43:43 PM (local)
Version (stdout): codebase-memory-mcp 0.10.2

Grok MCP config (`C:\Users\Jacob\.grok\config.toml`) — path was already correct

[mcp_servers.codebase-memory-mcp]
command = "C:/Users/Jacob/.local/bin/codebase-memory-mcp.exe"
enabled = true
# Added later as cushion after diagnosis (not the root cause):
startup_timeout_sec = 90

Conclusion: This was not “MCP pointing at the wrong place.” The configured path existed and reported 0.10.2.

Secondary older binary still on disk (not used by Grok)

C:\Users\Jacob\AppData\Local\Programs\codebase-memory-mcp\codebase-memory-mcp.exe
Size ~273333760, LastWriteTime 2026-07-08

Cache / state root

C:\Users\Jacob\.cache\codebase-memory-mcp\

Daemon rendezvous dir (stale locks present while daemon was down)

C:\Users\Jacob\AppData\Local\cbm-daemon-c888acc3ae367a1e\
  cbm-lifetime.lock
  cbm-participant-group-v1.lock
  cbm-rendezvous.lock          (contained pipe name cbm-daemon-...)
  cbm-startup-v2.lock
  cbm-version-cohort-*.lock

Daemon status while broken:

daemon: not running

After failed start attempts:

codebase-memory-mcp: CBM daemon could not start within 30000 ms
error: CBM daemon could not start within 30000 ms

3. Maintainer Q1 — Which file the fix touched (full path)

Primary broken file (the one that blocked startup)

C:\Users\Jacob\.cache\codebase-memory-mcp\_config.db

Fix commands applied (by assistant diagnosis)

takeown /F "C:\Users\Jacob\.cache\codebase-memory-mcp\_config.db"
icacls "C:\Users\Jacob\.cache\codebase-memory-mcp\_config.db" /grant "%USERNAME%:(F)"
icacls "C:\Users\Jacob\.cache\codebase-memory-mcp\_config.db" /grant "Administrators:(F)"

# Also reset ownership/ACL on entire cache tree:
takeown /F "C:\Users\Jacob\.cache\codebase-memory-mcp" /R /D Y
icacls "C:\Users\Jacob\.cache\codebase-memory-mcp" /grant "%USERNAME%:(OI)(CI)F" /T

Secondary cleanup (not the open-failure, but left by the “indexes deleted” upgrade)

Removed orphaned SQLite sidecars with no matching main .db:

C:\Users\Jacob\.cache\codebase-memory-mcp\C-Users-Jacob-source-repos-ACCLoser-ACCLoser.db-shm
C:\Users\Jacob\.cache\codebase-memory-mcp\C-Users-Jacob-source-repos-ACCLoser-ACCLoser.db-wal
C:\Users\Jacob\.cache\codebase-memory-mcp\ChessPilot.db-shm
C:\Users\Jacob\.cache\codebase-memory-mcp\ChessPilot.db-wal
C:\Users\Jacob\.cache\codebase-memory-mcp\D-FBackup-newInt.db-shm
C:\Users\Jacob\.cache\codebase-memory-mcp\D-FBackup-newInt.db-wal
C:\Users\Jacob\.cache\codebase-memory-mcp\IsochronicBeatGenerator.db-shm
C:\Users\Jacob\.cache\codebase-memory-mcp\IsochronicBeatGenerator.db-wal
C:\Users\Jacob\.cache\codebase-memory-mcp\Stockfish-Keanu.db-shm
C:\Users\Jacob\.cache\codebase-memory-mcp\Stockfish-Keanu.db-wal

Cleared stale files under:

C:\Users\Jacob\AppData\Local\cbm-daemon-c888acc3ae367a1e\

Note: Project indexes really were gone after update (matches installer message about deleting indexes / reindex later). After fix, cli list_projects returned empty until reindex. That is separate from the daemon refuse-to-start bug.

4. Maintainer Q2 — What was wrong with the file?

What it was not

Hypothesis	Observed?
Truncated / zero-length	No — length 12288 bytes while broken
Empty file	No
Wrong encoding (text)	N/A — binary SQLite DB, not a text config
Wrong SQLite contents / corrupt payload as primary symptom	Unlikely as first failure — after ACL repair only, opens worked; no rewrite/recreate of `_config.db` was required for recovery
Wrong Grok `command=` path	No
Binary won't run at all	No — `--version` / `--help` worked immediately

What it was

NTFS security descriptor problem: effectively no usable access ACEs on _config.db.

Evidence while broken:

Directory C:\Users\Jacob\.cache\codebase-memory-mcp showed normal ACL:
- DESKTOP-XAWRS9A\Jacob:(F)
File _config.db via icacls:
- Printed the path and “Successfully processed 1 files” but listed no ACE lines (empty DACL appearance).
.NET open tests:

EXCLUSIVE open of _config.db: Access to the path '...\ _config.db' is denied.
SHARED read open: Access Denied.

After takeown + grant FullControl to user + Administrators:

EXCLUSIVE open after ACL fix: OK

Immediately after that, without rewriting the DB:

codebase-memory-mcp config list   → exit 0 (~1.5s)
  auto_index = false
  auto_index_limit = 50000
  auto_watch = true
  ui-lang = auto

codebase-memory-mcp daemon start  → exit 0 (~7s)
  daemon: started (permanent, pid …)
  build 0.10.2

Timestamps on `_config.db` (still the same inode path after fix)

FullName:      C:\Users\Jacob\.cache\codebase-memory-mcp\_config.db
Length:        12288
CreationTime:  2026-08-11 6:44:37 PM
LastWriteTime: 2026-08-11 6:46:01 PM

Binary install mtime was 6:43:43 PM same day — config DB created ~1 minute later, consistent with post-update first run / migration, then failure window.

ACL after fix (current; original empty ACL is gone)

C:\Users\Jacob\.cache\codebase-memory-mcp\_config.db
  BUILTIN\Administrators:(F)
  DESKTOP-XAWRS9A\Jacob:(F)

If you need a conclusive broken sample: we no longer have the pre-takeown security descriptor. Repro would need either:

capturing icacls / Get-Acl before repair next time, or
finding whether the installer/update path creates _config.db with a null DACL / wrong owner under some Windows profiles.

5. Maintainer Q3 — Errors / MCP client text / “doctor”

`doctor`

$ codebase-memory-mcp doctor
(no output)
exit code: 0

codebase-memory-mcp --help (0.10.2) does not list a doctor command. Available relevant surfaces include daemon, config, cli, install, update, etc.

CLI errors while broken

# config list / any path that needs the config store:
error: cannot open config database

# daemon start:
level=info msg=version_cohort.claimed_unheld build=f1222762211789d45b1adfa08fe6aef4ee3947a1d45861b5ce2d82f3c4147005
codebase-memory-mcp: CBM daemon could not start within 30000 ms

# daemon status (during/after failed start attempts):
error: CBM daemon could not start within 30000 ms
daemon: not running
hint: `codebase-memory-mcp daemon start` keeps a daemon warm so CLI commands and hooks skip the per-command startup cost.

Grok MCP client symptoms

Session banner: MCP server codebase-memory-mcp timed out after 30s (default startup timeout).
Grok stderr log (C:\Users\Jacob\.grok\logs\mcp\codebase-memory-mcp.stderr.log) while failing often only showed:

level=info msg=version_cohort.claimed_unheld build=f1222762211789d45b1adfa08fe6aef4ee3947a1d45861b5ce2d82f3c4147005

i.e. the MCP child process started far enough to log version-cohort, then never completed MCP initialize within the client timeout — consistent with hanging on daemon/config open rather than a wrong executable path.

After fix (success path)

daemon: started (permanent, pid …)
daemon: active (permanent)
  build: 0.10.2 (f12227622117...)
cli list_projects → {"projects":[],"hint":"No projects indexed. Call index_repository(repo_path=...) first."}

(Empty projects expected: upgrade had deleted indexes; reindex is separate.)

Later, with Grok restarted, Core 1 reconnected successfully (server listed as connected with tools).

6. Maintainer Q4 — How the update was run

From the assistant’s session we cannot prove the exact command. User description:

Updated https://github.com/DeusData/codebase-memory-mcp to 0.10.2
Updater/installer text mentioned deleting indexes and that they would be reindexed on restart
Full PC restart did not fix MCP until the ACL issue was repaired
Grok config already pointed at C:/Users/Jacob/.local/bin/codebase-memory-mcp.exe

Reporter: please fill in if you remember:

[ ] powershell -ExecutionPolicy Bypass -File "<install-dir>\install.ps1"
[ ] irm https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 | iex
    (or similar one-liner)
[ ] codebase-memory-mcp update
[ ] codebase-memory-mcp install -y / --force
[ ] Downloaded windows-amd64 zip from GitHub Releases and replaced the exe manually
[ ] Other: ________________________________

Known install locations on this machine after update:

Active: C:\Users\Jacob\.local\bin\codebase-memory-mcp.exe (0.10.2, ~296 MB)
Leftover older tree: C:\Users\Jacob\AppData\Local\Programs\codebase-memory-mcp\ (pre-0.10 size/date)

7. Timeline (local, 2026-08-11)

Time (approx)	Event
6:43:43 PM	New `codebase-memory-mcp.exe` written under `.local\bin` (0.10.2)
6:44:37 PM	`_config.db` created
6:46:01 PM	`_config.db` last write
~6:46+ PM	Daemon lock files appear under `cbm-daemon-…`; daemon never stays healthy
Same evening	Grok: MCP connect timeout 30s; CLI: cannot open config database / daemon could not start within 30000 ms
Diagnosis	Empty ACL on `_config.db` → Access Denied
Fix	`takeown` + `icacls` grants; orphaned `-shm`/`-wal` removed; stale daemon locks cleared
Post-fix	`daemon start` OK; `config list` OK; projects empty until reindex

8. What we think is the product bug (for maintainers)

Creating or rewriting _config.db (and possibly other cache files) without a guaranteed inherited/explicit DACL that allows the same user who runs the MCP/daemon to open the file. On this box the directory ACL was fine; the file had effectively no ACE list → Access Denied.
Error surface: client-facing failure is a 30s daemon start timeout and a short cannot open config database, with MCP stderr only showing version_cohort.claimed_unheld. Hard for users to map that to “permissions on _config.db.”
Upgrade path: index wipe (documented) + new config DB in a narrow time window after binary replace; if file create uses a code path that sets a null/empty security descriptor under some Windows conditions, every post-upgrade first start would hang until ACL is repaired.
Optional hardening: on cannot open config database, print the full path, the OS error (Access Denied vs locked vs missing), and suggest icacls <path> / repair steps. A real doctor command would help.

This does not look like the maintainer’s second candidate (PowerShell encoding of a generated script) based on what we measured.

9. Reproduction hints (for you to try)

On Windows, after a 0.9.x → 0.10.2 update that recreates config:

Immediately inspect:

icacls "$env:USERPROFILE\.cache\codebase-memory-mcp\_config.db"
# Look for missing ACE lines / Access Denied on open

Simulate empty DACL (careful, lab only) and confirm same symptoms:

# Conceptual only — do not run casually on a good install
# Create a test file with an empty DACL and point config at it, or
# strip ACEs from a copy of _config.db and observe daemon start timeout.

Confirm recovery with ownership/ACL repair only (no DB rewrite), matching this report.

10. Paste-ready GitHub comment (short)

### Paths
- **Broken file:** `C:\Users\Jacob\.cache\codebase-memory-mcp\_config.db`
- **Binary:** `C:\Users\Jacob\.local\bin\codebase-memory-mcp.exe` (**0.10.2**, build `f1222762211789d45b1adfa08fe6aef4ee3947a1d45861b5ce2d82f3c4147005`)
- **MCP client:** Grok Build → command above (path was correct; not a misconfig)

### What was wrong
Not truncated / empty / wrong encoding. File size 12288 bytes. **NTFS ACL was empty (no usable ACEs)** → Windows **Access Denied** on open → CLI: `error: cannot open config database` → `CBM daemon could not start within 30000 ms` → MCP client 30s timeout. Grok stderr only showed `version_cohort.claimed_unheld`.

### Fix that worked (without rewriting DB contents)

takeown /F "..._config.db"
icacls "..._config.db" /grant "%USERNAME%:(F)"

Then `daemon start` and `config list` succeeded. Project indexes were already deleted by the upgrade (orphaned `*.db-shm`/`*.db-wal` only); reindex separate.

### doctor
No `doctor` command in 0.10.2 help; `codebase-memory-mcp doctor` printed nothing, exit 0.

### Update method
(Please fill: install.ps1 / update / other — installer mentioned deleting indexes for reindex on restart.)

### Broken copy
No longer retained; ACL was repaired in place. Happy to capture `icacls`/`Get-Acl` pre-fix if this reproduces after next update.

11. Attachments / related local logs

Path	Notes
`C:\Users\Jacob\.grok\logs\mcp\codebase-memory-mcp.stderr.log`	During failure: version_cohort lines
`C:\Users\Jacob\.cache\codebase-memory-mcp\logs\`	Worker logs (present during diagnosis)
`C:\Users\Jacob\.grok\config.toml`	MCP `command=` (correct)

Generated for issue follow-up after local diagnosis of the 0.10.2 post-update start failure. File lives in the newInt workspace for easy copy/paste to GitHub.

@KeanuPwnsU

Thank you @KeanuPwnsU for the detailed ACL evidence. It answers the maintainer request, so awaiting-reporter has been removed.

This matches the root cause established in #1351: v0.10.2 protected the cache directory with an owner ACE that had no object/container inheritance flags, so children such as _config.db could be created with an empty DACL and become unreadable even to the owner. That is also why repairing the ACL restored the existing database without changing its bytes.

Fixed on main by @Kiborgik in #1531, merge 7f23a66a, and included in the v0.10.3 release candidate. Directories now receive an inheritable owner-only ACE, while leaf objects retain the strict owner-only policy. Closing this report as resolved on main; thank you again for turning the screenshot into conclusive filesystem evidence.

My pleasure, I'm a huge fan. If I had more compute I would be tempted to work on it myself. Thanks a bunch for it. I use it in tandem with my MCP smart search / read I created and together they drop the usage by a whole lot for me. MCP memory does the heavy lifting, searching through giant SDK's and things, then it seamlessly switches to "core 2" which is my smart MCP search/read I made in python when it narrows down on targets. I had a third core, a special MCP diff editor I made for antigravity CLI, but it was incompatible with how grok build handles its data. Native edits are really good with grok anyways.

Best of wishes with your future coding endeavors! (Maybe eventually I will fork and try to bolt my MCP tool directly to this to help make it a slightly more dynamic swiss army knife)

Corrupted file making MCP fail to start after 0.10.2 update through powershell #1551

Description