Windows installer fails with CodexSandboxUsers ACL in %TEMP%

[RoccoZero]

Version

codebase-memory-mcp 0.10.0

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

The standard Windows installer fails during its activation transaction when the user's %TEMP% directory contains ACL entries for the local CodexSandboxUsers group created by the OpenAI Codex desktop sandbox.

Downloading, checksum verification, extraction, and candidate binary validation all succeed. Installation fails only during ACL validation with acl-grants-cross-account-mutation.

I expected the standard install.ps1 workflow to install successfully without requiring removal of CodexSandboxUsers, modification of the system %TEMP% ACL, a custom temporary directory, or manual binary installation.

Reproduction

1. Install and run the OpenAI Codex desktop app on Windows. It creates the local CodexSandboxUsers group and adds ACL entries for this group to the user's %TEMP% directory.

2. Open a normal Windows PowerShell session.

3. Run the official installation commands:

Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1
Unblock-File .\install.ps1
.\install.ps1

4. The archive is downloaded and verified successfully, but installation fails:

codebase-memory-mcp installer (Windows)
  arch:    amd64
  target:  C:\Users\<user>\AppData\Local\Programs\codebase-memory-mcp\codebase-memory-mcp.exe

Downloading codebase-memory-mcp-windows-amd64.zip...
Checksum verified.
Extracting...
Verified candidate: codebase-memory-mcp 0.10.0
codebase-memory-mcp install 0.10.0

error: failed to stage install candidate: activation transaction I/O failed:
acl-grants-cross-account-mutation to S-1-5-21-...-1004 (os 0)
at C:/Users/<user>/AppData/Local/Temp/cbm-install-<id>
error: installation failed (exit code 1)

5. The rejected SID resolves to the local group:

<computer>\CodexSandboxUsers

6. Using a private temporary directory without the CodexSandboxUsers ACL gets past the first error. However, when the target directory is owned by BUILTIN\Administrators, installation fails with:

error: failed to stage install candidate: activation transaction I/O failed:
owner-not-current-user (os 0)
at C:/Users/<user>/AppData/Local/Programs/codebase-memory-mcp

Expected: the official Windows installer should support common sandbox ACLs or create a private staging directory with suitable ownership and permissions.

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.

[Kiborgik]

Independent reproduction of both halves on Windows 11 26200, 0.10.0 standard, non-elevated. Two details that may be useful, plus the workaround that got me installed.

A second Codex mechanism produces the same refusal. Your rejected SID resolved to the local CodexSandboxUsers group. Mine did not resolve at all:

acl-grants-cross-account-mutation to S-1-5-21-4253504394-792029637-2192658114-2546237501 (os 0)
at C:/Users/<user>/AppData/Local/Temp/cbm-install-301192034

That SID appears verbatim in %USERPROFILE%\.codex\cap_sid, which Codex maintains as a capability registry keyed by writable root:

"writable_root_by_path": {
  "c:/users/<user>/appdata/local/temp": "S-1-5-21-4253504394-792029637-2192658114-2546237501",
  ...
}

So Codex grants %TEMP% mutation twice over by different means: the real CodexSandboxUsers group in your case, and a synthesized per-root capability SID in mine. The synthesized one has a foreign machine authority and an out-of-range RID, so it resolves to nothing and reads like an orphan ACE. Worth knowing if the fix keys on recognising the Codex group by name — that would miss this variant.

The workaround, both halves. install.ps1 stages in [System.IO.Path]::GetTempPath(), which honours TMP/TEMP, so redirecting them to a clean directory clears the first error without touching any ACL:

New-Item -ItemType Directory -Force "$env:USERPROFILE\cbm-stage"
$env:TMP="$env:USERPROFILE\cbm-stage"; $env:TEMP="$env:USERPROFILE\cbm-stage"; .\install.ps1

For your step 6, owner-not-current-user on the target: keeping the install directory under the user profile avoids it, since a directory created there is owned by you rather than by BUILTIN\Administrators. The default target already is, so that error suggests the earlier custom directory was created somewhere with the Administrators-default-owner policy in effect. compat_fs.c:435 documents that case directly — plain _wmkdir under that policy yields an Administrators-owned directory that the activation validator then rejects.

Version bracket. 0.9.0 has neither failure; the strict permission gate arrived in 0.9.1-rc (#1416). Overwriting the binary in place with 0.9.0 works and leaves the existing index intact, if you need something running meanwhile.

One thing I would not assume: whether your case and mine should be fixed the same way. CodexSandboxUsers is a real local group and therefore a genuine second principal, which is the exact thing the gate exists to refuse. The synthesized capability SID is arguably a different question. I filed #1533 for a third, narrower variant involving app container SIDs (S-1-15-2-* / S-1-15-3-*), which are not login-capable at all — deliberately kept separate from this report rather than folded in.

[Kiborgik]

Follow-up: the same grant breaks the product at runtime, not only during install, and via a different validator.

Running the repo's own Windows guard against a main build on the affected machine dies in its first section:

RED: bare `daemon` should print usage and fail:
codebase-memory-mcp: exact executable identity could not be verified (cache-private)
  - C:\Users\<user>\AppData\Local\Temp: DACL entry 0 grants mutation rights 0x00010112
    to untrusted identity (other S-1-5-21-4253504394-792029637-2192658114-2546237501)

That is the cache-private executable-identity check walking ancestors, not the activation transaction, refusing the same %TEMP% ACE described above. tests/windows/test_daemon_stability.py uses tempfile.mkdtemp(), so every section inherits it.

Redirecting TMP/TEMP to a clean directory makes the whole guard pass, all seven sections:

PASS: parameter surface rejects bare/unknown/out-of-range daemon invocations
PASS: hook fails open without a daemon; notice is visible once, then rate-limited
PASS: start survives an occupied --port, status reports the pid, second start is a no-op
PASS: stop refuses while a session is attached (listing its pid) and succeeds once it closes
PASS: kill -9 recovery - stale state cleared, cold client worked, fresh start got a new pid
PASS: permanent daemon survived 10 sequential + 2x6 parallel clients with an unchanged pid
PASS: 6 racing cold clients all succeeded and the shared ephemeral daemon retired

So on a machine with the Codex sandbox present, anything that resolves a temp path fails closed - the installer, and the daemon itself. Worth knowing if a fix targets only the activation transaction: the ancestor walk reaches the same ACE from at least two other places.