ProcessContainer: MSYS2/Cygwin runtimes (git-bash) cannot initialize — NtCreateDirectoryObject(\BaseNamedObjects\...) denied

@jsidewhite is already working on this.

Since Aug 28, 2026.

### Relevant area(s)

Linux, Windows

### Brief description of your issue

## Summary

MSYS2/Cygwin-based executables (git-bash, and anything else linking `msys-2.0.dll`)
cannot run under the `processcontainer` backend. The process launches successfully,
but the MSYS runtime aborts during initialization when it tries to create its shared
state directory in the session-global object namespace, which AppContainer processes
cannot write.

This is not a policy or configuration problem — no filesystem, capability, or UI
setting can grant it.

## Environment

- MXC: `main`
- Windows 11 25H2 (build 26200)
- Selected tier: `appcontainer-dacl` (T3); `--probe` reports
`baseContainerApiPresent: true`, `bfsCompiledIn: false`
- git-bash / MSYS2 runtime 3.6.5 (`x86_64-pc-msys`)

### Steps to reproduce

## Repro

Config:

```json
{
"version": "0.8.0-alpha",
"containment": "processcontainer",
"process": {
"commandLine": "\"C:\\tools\\git-bash\\bin\\bash.exe\" --version",
"cwd": "C:\\tools\\git-bash",
"timeout": 30000
},
"filesystem": {
"readonlyPaths": ["C:\\tools\\git-bash", "C:\\Windows"],
"readwritePaths": []
},
"fallback": { "allowDaclMutation": true },
"ui": { "disable": false }
}
```

```
wxc-exec.exe config.json
```

### Expected behavior

```
bash.exe --version
GNU bash, version 5.2.37(1)-release (x86_64-pc-msys)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
```

### Actual behavior

## Observed

```
0 [main] bash (NNNN) C:\tools\git-bash\usr\bin\bash.exe: *** fatal error -
NtCreateDirectoryObject(\BaseNamedObjects\msys-2.0S5-): 0xC0000022
Exit code: -1073741502 (0xC0000142)
```

`0xC0000022` is `STATUS_ACCESS_DENIED`; `0xC0000142` is `STATUS_DLL_INIT_FAILED`.

## Root cause

`msys-2.0.dll` passes an **absolute NT path** to `NtCreateDirectoryObject`.
AppContainer's named-object redirection lives in user-mode `kernelbase`
(`BaseGetNamedObjectDirectory`) and only covers the Win32 named-object APIs — it does
not rewrite absolute NT paths. The call therefore reaches the real global
`\BaseNamedObjects` and fails the `DIRECTORY_CREATE_SUBDIRECTORY` access check
(`SeChangeNotifyPrivilege` bypasses traverse, not create).

Verified by direct probe from inside the container, same container SID:

| Path | Result |
|---|---|
| `\BaseNamedObjects\test` | `0xC0000022` |
| `\Sessions\1\AppContainerNamedObjects\\test` | `STATUS_SUCCESS` |

The container's own namespace is writable; only the global one is denied.

An API trace of `bash -c "echo hi | tr a-z A-Z"` shows the full dependency is small —
exactly two absolute paths, with every child object created relative to the resulting
directory handle:

```
CreateDir Root=0x0 "\BaseNamedObjects\msys-2.0S5-"
CreateDir Root=0x0 "\Sessions\BNOLINKS\1\msys-2.0S5-"
CreateSection Root=0x124 "shared.5"
CreateSection Root=0x124 "cygpid." <- fork
CreateMutant Root=0x124 "cygpipe.input.mutex.-0x1" <- pipe
CreateMutant Root=0x124 "sig_send." <- signals
CreateSymlink Root=0x124 "winpid."
```

## Ruled out

- **Not Win32k.** Identical failure with `ui.disable: false`.
- **Not filesystem policy.** `\BaseNamedObjects` is an object-manager path; no
`readonlyPaths` / `readwritePaths` entry reaches it. Granting read-write on the
install directory changes nothing.
- **Not ACLs.** The install tree already carries
`ALL APPLICATION PACKAGES:(OI)(CI)(RX)`.
- **Not tier-specific.** Same result on `appcontainer-dacl`; the object namespace
boundary is a property of AppContainer, not of the tier.

## Impact

Any MSYS2/Cygwin-based tool is unusable under `processcontainer`. This includes
git-bash, which is a common developer shell on Windows.

`docs/learning-mode/capabilities.md` already classifies `\BaseNamedObjects` as
`unsupportedObjectType` ("outside the supported diagnostic model"), so even with
`captureDenials` enabled this denial is filtered out of the actionable output and
appears only in verbose logging.