Windows: index always fails with generic 'Pipeline failed' — protected-DACL cache dir breaks MoveFileExW(REPLACE_EXISTING) on this host

[roosteer]

Summary

On this Windows host, every index_repository run fails with the generic hint:

{"project":"...","status":"error","hint":"Pipeline failed. Check repo_path exists and contains source files. Try mode='fast' for a quicker diagnostic run."}

The pipeline itself runs all passes successfully (including gbuf.dump), the supervised worker exits 0 (index.supervisor.reap outcome=clean), no error-level log line is emitted anywhere, and no .db is ever published. A 1-file Go repo fails identically, so it is host-specific, not repo-specific. ui.config.write_fail ... reason=atomic_publish appears repeatedly in the daemon log as well.

Root cause (verified end-to-end)

The failure is an interaction between the Windows cache-DACL hardening and MoveFileExW on this host:

1. Since v0.9.1-rc.1, every CBM process start re-applies a protected, owner-only DACL to the cache directory (win_runtime_directory_secure in src/daemon/ipc.c, cbm_windows_stamp_dir_owner in src/foundation/compat_fs.c; re-applied unconditionally on each process start, not only at creation).
2. On this machine, MoveFileExW(src, dst, MOVEFILE_REPLACE_EXISTING) returns ERROR_ACCESS_DENIED (5) inside any directory whose DACL is protected (inheritance disabled), while plain rename, create and delete all work. Reproduced independently of CBM:
   • cmd /c "move /y r2.txt r1.txt" → Access is denied in the protected dir, works in %TEMP% and in sibling dirs with inherited ACLs.
   • Synthetic dirs: icacls /inheritance:r + single owner ACE → fails; icacls /inheritance:e → works.
3. CBM publishes the index via rename-replace (publish_writer_output in src/sqlite_writer.c → cbm_rename_replace → MoveFileExW; also finalize_staged_generation). The failure is silent (CBM_PIPELINE_PERSIST_FAILED with no log), which produces the misleading generic hint.
4. Proof: keeping the cache dir ACL in the healthy (inherited) state during a run (background loop re-applying icacls /inheritance:e while the pipeline executes) makes the exact same index succeed: status:"indexed", .db published.

So on this host the hardening itself makes the cache dir unusable for the rename-replace the pipeline depends on. No config switch exists to disable it (a non-conforming DACL is re-hardened; denying WRITE_DAC fails the daemon closed; UNC paths are refused; CBM_CACHE_DIR elsewhere gets hardened the same way).

Environment

Version	0.10.4
OS	Windows (domain-joined, UAC enabled, user in Administrators)
Cache dir	C:\Users\...\.cache\codebase-memory-mcp (default)

Related

• Windows x64: v0.9.1-rc.1 daemon leaves existing cache files unreadable (empty ACL) #1351, fix(daemon): make private directory DACL inheritable #1531 — the DACL hardening chain this builds on
• 0.10.2: cache ACL grants an ephemeral logon-session SID (S-1-5-5-X-Y) instead of the user SID, so the cache becomes unreadable after reboot (likely incomplete fix for #1351) #1601 — another symptom of the same hardening code (ephemeral logon-session SID in the cache ACL)

Suggested fixes

1. Fallback publish path when rename-replace fails (e.g. copy+delete, or write the final name directly) instead of silent PERSIST_FAILED.
2. Make the DACL hardening opt-out (env var) for hosts where it conflicts with local security policy.
3. At minimum: log the real OS error (which operation failed with which code) instead of the generic "Pipeline failed" hint — the current silence cost a full day of investigation.

[DeusData]

Thank you for this, and I'm sorry: you root-caused a blocker, wrote the fix, and this issue itself has had no reply at all until now. That is not the reception that work deserved.

Your diagnosis holds up. The chain you described — the pipeline runs every pass, the supervised worker exits 0, and no .db is ever published — is the signature of the publish step failing, not the indexing. And you identified the mechanism: our own protected cache-directory DACL breaks MoveFileExW(REPLACE_EXISTING) on that host.

Where things stand, honestly:

Not fixed in v0.10.5. I want to say that plainly rather than let you upgrade and re-hit it. What is in v0.10.5 is the diagnosis half — the publish failure no longer reports a meaningless errno with the Win32 error discarded, and one path that returned PERSIST_FAILED with no log line at all now says what happened. That is why you were told to "check repo_path exists" for what was actually an ACL problem. It will not fix your host, but it should stop misdirecting the next person.

Two changes are open against this. #1628 covers the reporting, and your own #1649 is the configurability piece. There is also #1634, which stops us re-stamping the runtime DACL on every process start — 11 "Security change" USN records per day on your machine, and a window a MoveFileEx publish can lose to. I pulled #1634 from v0.10.5 because it broke daemon startup in testing: I had conflated "grants nothing untrusted" with "protected against inheritance", and shipping it half-right would have traded your bug for a worse one.

On #1649 specifically — it is a real decision rather than a review backlog, which is why it has not simply been merged. An env-var opt-out for the DACL hardening weakens a boundary that protects the coordination endpoint for everyone, so we would rather first exhaust "give the operator a location that legitimately passes". v0.10.5 ships CBM_RUNTIME_DIR for exactly that: it relocates the rendezvous directory without relaxing any check — you choose an ancestry that passes, rather than switching the rule off. It would genuinely help to know whether that unblocks your host, because if there is no reachable location that passes on a normal Windows machine, that is the argument for your flag, and your report becomes the evidence for it. The maintainer decision on the opt-out is pending and I am not going to pre-empt it.

Thank you again — for the report, for chasing it to the actual Win32 call, and for writing the patch. Two of the three open changes here exist because of your work.