Windows: activation ancestor-walk fails unconditionally on stock/default ACLs (no OS-level denial in ProcMon trace) #1856

Summary

On Windows, install.ps1 fails at the "activation" step with activation could not reserve exclusive access; no activation was committed. — regardless of which directory is used as --dir, and independent of the CBM_CACHE_DIR location. This looks like the same "ancestor walk" ownership/ACL check discussed in #1830 (Linux/Docker userns-remap) and #1533 (Windows containers), but triggered here on a completely standard, non-containerized Windows 10 install by Windows' own out-of-the-box default ACLs.

Environment

• OS: Windows 10 Pro, build 10.0.19043 (21H1) — no TLS 1.3 support in schannel
• codebase-memory-mcp: v0.10.8 (windows-amd64)
• Running fully elevated as a local Administrator (confirmed SeCreateGlobalPrivilege and SeDebugPrivilege enabled, IsInRole(Administrator) = True)
• No antivirus/EDR installed (WinDefend service absent, SecurityCenter2 empty, no known AV process running)

Repro

irm https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1
# (had to patch line 11 to `Tls12` only -- see "Separate issue" below)
.\install.ps1 --dir=C:\Users\<user>\codebase-memory-mcp

Output:

Downloading codebase-memory-mcp-windows-amd64.zip...
Checksum verified.
Extracting...
Verified candidate: codebase-memory-mcp 0.10.8
error: activation could not reserve exclusive access; no activation was committed.
error: this is NOT a running-session problem — the reservation itself failed (coordination lock, leftover state, or permissions). ...

This reproduces identically:

• with a brand-new, freshly created --dir (clean ACL: owner+SYSTEM+Administrators+the account only, no other principals)
• with a brand-new CBM_CACHE_DIR pointed elsewhere (rules out leftover cache state)
• across three separate target directories

Root cause (confirmed via Process Monitor)

I captured a full ProcMon trace across a failing run. Every single Windows API call the process makes succeeds (CreateFile, the 296 MB staged-candidate write, QuerySecurityFile, etc.) — there is no ACCESS DENIED, SHARING VIOLATION, or any other OS-level denial anywhere in the trace. The process itself deliberately deletes its own staged candidate (SetDispositionInformationEx with FILE_DISPOSITION_DELETE | FILE_DISPOSITION_POSIX_SEMANTICS | FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK) and exits 1 right after inspecting the DACL of the target directory and its parent. This is an application-level decision, not an OS failure — i.e. the same class of check as posix_directory_parent_secure in #1830, just walking the Windows ACL ancestor chain instead of POSIX uid ownership.

I isolated two concrete triggers of the same check family, both on default, unmodified Windows ACLs:

1. --dir=C:\<fresh-dir> (parent = user profile root, e.g. C:\Users\Administrator): fails with the generic message above. The profile root carries Windows' standard (A;;0x1200a9;;;WD) ACE — Everyone/World, read-only, not inherited by children — which is present on essentially every Windows user profile by default.
2. --dir=C:\<fresh-dir-directly-under-C>: fails with a specific error instead:

   error: failed to stage install candidate: activation transaction I/O failed: acl-grants-cross-account-mutation to S-1-5-11 (os 0) at C:/<dir>
   

   S-1-5-11 is Authenticated Users — the account that gets create file/create subfolder rights on C:\ by default on every Windows install since Vista ((A;OICIID;0x1301bf;;;AU) inherited from the drive root). This is not a hardened/misconfigured machine; it's Microsoft's stock default.

Since (1) and (2) fire on stock Windows defaults with no containerization, no third-party ACL tooling, and no other logged-in principals actually able to write anything of consequence, the ancestor-walk check appears to be unconditionally too strict for Windows: any non-owner principal anywhere in the ancestor chain — even a read-only Everyone ACE, even the standard AU-create-only ACE on C:\ — trips it. This would make normal (non-Server-Core, non-freshly-re-ACL'd) Windows installs unable to complete activation at all.

Separate/related issue: TLS 1.3

install.ps1 line 11 hardcodes:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -bor [Net.SecurityProtocolType]::Tls13

On Windows 10 (schannel has no TLS 1.3 support before Windows 11 / Server 2022), setting this bitmask makes HttpClientHandler's GetAsync fail outright with WebException: İstek durduruldu: SSL/TLS güvenli kanalı oluşturulamadı. (SSL/TLS secure channel could not be created), even though the same machine's Invoke-WebRequest to the identical URL succeeds fine. Dropping the -bor Tls13 fixes it. Might be worth an OS-version check (or a try/fallback) before setting Tls13 in the bitmask, since combining an unsupported protocol flag with a supported one causes a hard failure rather than a graceful fallback here.

What I've ruled out

• Leftover lock/cache state (tested 3 different cache paths, all fresh/empty)
• File permissions on the leaf target directory (confirmed writable, full control)
• AV/EDR interference (none installed on this machine)
• Restricted/UAC-filtered token (fully elevated, SeCreateGlobalPrivilege + SeDebugPrivilege enabled)
• Port conflicts on 9749 (nothing listening)
• --dry-run (works fine — it's specifically the write/activation path that fails)

Suggested fixes

• Treat read-only ACEs (no write/delete/take-ownership bits) on ancestor directories as non-disqualifying — mirroring the fix direction discussed in Linux: ancestor walk fails unconditionally in Docker userns-remap containers (single-uid mapping, / owned by nobody/65534) #1830 for the POSIX overflow-UID case.
• Special-case the OS-default ACEs that ship on every Windows install (Authenticated Users create-only on C:\, Everyone/Users read-only on profile roots) rather than treating any non-owner ACE as a cross-account mutation risk.
• Consider exposing a CBM_SKIP_ANCESTOR_WALK-style escape hatch (as proposed in Linux: ancestor walk fails unconditionally in Docker userns-remap containers (single-uid mapping, / owned by nobody/65534) #1830) for Windows too. I checked: v0.10.8's binary does not contain that string at all (dumped all CBM_[A-Z_]+ identifiers from the executable — 44 env vars total, e.g. CBM_ALLOWED_ROOT, CBM_CACHE_DIR, CBM_RUNTIME_DIR, CBM_DIAGNOSTICS; no ancestor/skip-walk override among them), and setting it had no effect on the repro above. So the escape hatch discussed in Linux: ancestor walk fails unconditionally in Docker userns-remap containers (single-uid mapping, / owned by nobody/65534) #1830 isn't implemented yet, at least not for Windows/this version.
• For install.ps1: gate the Tls13 flag on [Environment]::OSVersion.Version (or catch-and-retry with Tls12 only) so it doesn't hard-fail on Windows 10.

Happy to provide the full ProcMon .pml/CSV or run further diagnostics if useful.