Windows x64: v0.9.1-rc.1 daemon leaves existing cache files unreadable (empty ACL)

[ertankucukoglu]

Version

codebase-memory-mcp 0.9.1-rc.1

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

When I tested v0.9.1-rc.1 against an existing local CBM installation and cache on Windows, the new daemon/ACL path left existing cache files with an empty ACL. The same Windows user could no longer read _config.db, log files, or sampled project database files.

After that, MCP requests such as search_graph and check_index_coverage did not complete within 15–20 seconds. Starting the RC daemon again reproduced the empty ACL on _config.db.

I expected the installer/daemon either to preserve usable file permissions or to fail safely before changing existing permissions. It must not leave the current user's cache unreadable.

Reproduction

Prerequisite: Windows x64 with an existing CBM installation/cache. The existing installation or one of its parent directories has inherited cross-account ACL entries.

1. Back up the existing CBM executable, configuration, and cache.
2. Verify the official v0.9.1-rc.1 Windows amd64 release archive and run install.ps1 with --skip-config against the existing installation.
3. The installer rejects the existing installation directory with: acl-grants-cross-account-mutation
4. Retry with an owner-private temporary directory. Activation then aborts with: active CBM sessions and operations could not be stopped safely; no activation was committed.
5. Place the checksum-verified RC binary in a user-private directory without changing agent configuration, then start the daemon: codebase-memory-mcp.exe daemon start
6. Observe: daemon.runtime_config_open_failed reason=config_db_unavailable
7. Inspect the existing CBM cache: _config.db, logs, and sampled project .db files have an empty ACL and are unreadable by the current user.
8. Start the RC daemon again; the empty ACL on _config.db is reproduced.
9. On an already-indexed 31-node project, check_index_coverage did not complete within 15 seconds through the CLI. Small MCP search_graph and check_index_coverage calls did not complete within 15–20 seconds.

No repository source code is required for this reproduction; the failure occurs before source analysis.

Logs

activation transaction I/O failed: acl-grants-cross-account-mutation
active CBM sessions and operations could not be stopped safely; no activation was committed.
daemon.runtime_config_open_failed reason=config_db_unavailable

Diagnostics trajectory (memory / performance / leak issues)

CBM_DIAGNOSTICS=1 was enabled. The daemon created a local trajectory.ndjson file. I have not attached it because it may contain local environment details; I can provide a redacted extract if needed.

Project scale (if relevant)

31 nodes / small existing project / failure occurs before source analysis

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.

[ertankucukoglu]

Here is the issue log in zip format.
cbm-v0.9.1-rc.1-windows-acl-report.zip

[hetasshi]

I can reproduce the same issue on Windows x64 with the v0.9.1-rc.1 UI build.

Existing stable installation with 6 indexes in:
C:\Users\user.cache\codebase-memory-mcp

The archive downloaded, checksum verification passed, extraction passed, and the candidate binary was verified successfully. Installation then failed during activation with:

activation transaction I/O failed: acl-grants-cross-account-mutation to S-1-5-21-398329113-3246588833-669947113-1583456143 (os 0)

Temporary path:
C:\Users\user\AppData\Local\Temp\cbm-install-132218333

The installer reported that all 6 existing indexes were being kept. I did not attempt to bypass the ACL check or start the RC daemon afterward.