fix(windows): accept AppContainer capability grants on runtime ancestors

[mlandolfi90]

Symptom

On an ordinary Windows 11 developer machine, every CBM process died at startup:

codebase-memory-mcp: secure daemon endpoint could not be created

No CBM process was competing, and the same machine had run a daemon for days on an older build. The cause is environmental and, I suspect, increasingly common: an agent sandbox (Codex) had stamped the user's AppData with capability ACEs.

C:\Users\<user>\AppData  ->  S-1-15-3-3557520199-...  FullControl  (inherited to AppData\Local)

win_private_directory_tree_secure walks every ancestor of the runtime directory and refuses any mutation-granting ACE whose SID is not the exact user, SYSTEM, Administrators, TrustedInstaller, CreatorOwner (inherit-only) or OWNER RIGHTS. A capability SID matches none of them, so cbm_daemon_ipc_endpoint_new returns NULL and the process exits — including plain --version-adjacent paths that construct an endpoint.

Why I think accepting them on ancestors is sound

A capability SID (S-1-15-3-…, SECURITY_APP_PACKAGE_AUTHORITY) grants only to AppContainer processes that the same user's tooling provisioned. It cannot be used by another account, and it does not confer rights on a normal process. This is the same shape of argument the OWNER RIGHTS acceptance in 8b4e0fb already makes: the grant is reachable only by the party the walk is protecting.

The relaxation is deliberately narrow:

• Ancestors only. win_directory_component_secure passes ancestor_capability_ok = true.
• The runtime directory itself is unchanged. win_runtime_directory_secure passes false, so it still demands the exact-user owner and a protected DACL, and still re-stamps it.
• The SID test checks the identifier authority (15) and the capability RID class (3) explicitly, so it cannot widen to other S-1-15-* classes.

Note on the trust model

This does move a trust boundary, so I understand if you would rather discuss it in an issue before reviewing code — happy to convert. I am also open to a narrower shape if you prefer one: gating it behind an opt-in, or restricting acceptance to ancestors that lie inside the user's own profile.

What I would push back on is leaving it as-is: the failure gives the user one sentence with no cause, and the only remedies available to them are removing ACEs their sandbox depends on, or not running CBM.

🤖 Generated with Claude Code

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[mlandolfi90]

CI update — the platform-wide red was real and mine, and it is worth naming precisely because it is a good guard.

tests/test_windows_bundle_contract.sh pins the ancestor validation call by literal source text:

"win_file_security_secure(security, directory, false, mutation)",

Adding the capability parameter changed that text, so the contract failed on Linux and macOS too — the check reads the source rather than compiling it. That is the guard doing its job: it is exactly the line that decides how much an ancestor is allowed to grant, and it should not move quietly.

I have pushed an update to the needle, and used the occasion to pin the property this PR actually needs to be true rather than just the call shape:

"win_file_security_secure(security, directory, false, mutation, true)",
"win_private_mutation_rights(), false)",
"win_sid_is_app_capability",

The middle one is the important addition: it pins that win_runtime_directory_secure still passes false. If someone later let a capability ACE satisfy the runtime directory the daemon actually publishes into — the thing this relaxation must never reach — that contract now fails.

If you would rather this guard not be touched by a contributor PR at all, say so and I will drop the test commit and let you land the needle change yourself.

The remaining security / codeql-gate red is a timeout with the analysis still queued (BLOCKED: CodeQL timeout), not an alert.

🤖 Generated with Claude Code