Windows restricted_token: Hermes tools fail because MSYS2/git-bash cannot initialize (CreateFileMapping error 5)

[0xReSan]

Description

Under the restricted_token backend (the default for network: host), a Hermes agent running inside the sandbox cannot execute any of its file/tool operations (write_file, terminal, execute_code). All Hermes tools route through git-bash (MSYS2), and git-bash fails to initialize under the RestrictedToken sandbox with a fatal CreateFileMapping error.

This is not a sandbox file-permission failure — direct file writes via cmd.exe inside the same sandbox succeed. The failure is specific to MSYS2/Cygwin runtime initialization under a restricted token.

Test Environment

• Windows 11 Pro, build 26200 (Insider Preview)
• finsafe v0.9.30 (x86_64-pc-windows-msvc)
• Hermes Agent v0.19.1 (git install, Python 3.11.15)
• Git for Windows (MSYS2) — D:\Program Files\Git\bin\bash.exe (set as HERMES_GIT_BASH_PATH)
• Backend: restricted_token, network: host

Policy Used

schema_version: 1
kind: local-wrapper
program_mode: short-lived
network: host
windows:
  backend: restricted_token
filesystem:
  read_only_paths: []
  read_write_paths:
    - 'D:\finclaw\workspace'
    - '${USERPROFILE}\AppData\Local\hermes'
    - '${USERPROFILE}\AppData\Local\Temp'

Steps to Reproduce

# 1. Run hermes inside the sandbox, asking it to write a file
finsafe --policy policy.yaml run cmd /c "hermes -z \"Write the text 'hello' to D:\finclaw\workspace\test.txt\"" chat

Hermes attempts write_file → fails → falls back to terminal (PowerShell Set-Content) → fails again with the same underlying error.

Actual Behavior

Hermes reports both tool attempts failed:

Attempt 1: write_file D:\finclaw\workspace\hermes-test-write.txt
  Result: FAILED, bytes_written: 0
  Error: bash.exe fatal - CreateFileMapping S-1-5-21-...-1001.1, Win32 error 5 (ACCESS DENIED)

Attempt 2: terminal -> native powershell.exe Set-Content (fallback)
  Result: FAILED, exit_code 256
  Error: same bash.exe fatal - CreateFileMapping ... Win32 error 5

The workspace file is NOT created. finsafe itself reports exit_code=Some(0) (the outer cmd wrapper exits 0 even though the inner hermes tool call failed).

Root Cause Evidence (Procmon Analysis)

Logfile-25 (bash.exe crash chain)

8 git-bash processes, each spawning the next (MSYS2 fork emulation), all exit with STATUS_DLL_INIT_FAILED (-1073741502):

bash.exe (login shell)
  → create Conhost.exe
  → create bash.exe (usr/bin)
    → create WerFault.exe   (Windows Error Reporting fired — process crashed)
    → exit -1073741502      (STATUS_DLL_INIT_FAILED)
  → exit -1073741502

Logfile-26 (bash.exe inside sandbox, 177k events)

• 243 bash.exe processes spawned (fork chains)
• 31 ACCESS DENIED events, all on:
  HKLM\System\CurrentControlSet\Services\WinSock2\Parameters (Desired Access: All Access)
• No file-system ACCESS DENIED on the workspace / Temp paths — the sandbox DACLs are fine

Key: CreateFileMapping is a kernel-object operation

Procmon's default file/registry/network capture does not log CreateFileMapping failures, so the fatal error is only visible in bash's own stderr:

[main] bash (6004) ...bash.exe: *** fatal error - CreateFileMapping
S-1-5-21-2981251388-1693183809-1632240619-1001.1, Win32 error 5. Terminating.

S-1-5-21-...-1001.1 is the MSYS2 shared-memory mapping object named after the user SID (Cygwin/MSYS uses a named section for inter-process shared state). Creating it requires the SeCreateGlobalPrivilege (or an existing object whose DACL admits the restricted token). The RestrictedToken backend removes privileges, so the mapping cannot be created → MSYS runtime aborts → every Hermes tool that spawns bash dies before doing anything.

Comparison — Direct writes work fine

Same sandbox, no bash involved:

# cmd.exe direct write to Temp — SUCCESS
finsafe --policy policy.yaml self-confine -- cmd /c echo test > C:\Users\xuls2\AppData\Local\Temp\fs-test-1.txt   # file created

# Rust test program spawning a child that writes to workspace — SUCCESS
#   (parent spawns child exe; child writes D:\finclaw\workspace\child-write-test.txt)
finsafe --policy policy.yaml run D:\finclaw\child-write-test\target\release\child-write-test.exe
#   [child] wrote 57 bytes ... VERIFY: file exists — child write OK

So the sandbox itself correctly grants workspace/Temp write access and child-process creation. The breakage is confined to MSYS2/Cygwin runtime initialization under the restricted token.

Summary Table

Operation	Inside sandbox	Result
cmd /c echo > workspace\f.txt	RestrictedToken	✅ write OK
cmd /c echo > %TEMP%\f.txt	RestrictedToken	✅ write OK
Rust parent → child → write workspace	RestrictedToken	✅ child spawn + write OK
Hermes write_file (via git-bash)	RestrictedToken	❌ bash CreateFileMapping error 5
Hermes terminal → powershell Set-Content	RestrictedToken	❌ same bash error
git-bash bash.exe init	RestrictedToken	❌ STATUS_DLL_INIT_FAILED

Design Note (trade-off)

The Windows sandbox was originally designed for native Windows binaries — MSYS2/Cygwin runtimes (git-bash) are outside its intended compatibility scope. However, Hermes (and other agent toolchains that shell out through git-bash) requires MSYS2 to initialize for its write_file / terminal / execute_code tools. Supporting Hermes inside the sandbox therefore means either:

1. Keeping SeCreateGlobalPrivilege (or otherwise permitting the user-SID named shared-memory object) in the RestrictedToken posture, or
2. Having Hermes execute tools through a native Windows entry point (cmd.exe / PowerShell) instead of git-bash, or
3. Documenting that RestrictedToken + MSYS2-dependent agents is unsupported.

This issue focuses on the problem report; the trade-off note is provided as context for maintainers.

Files Referenced

• D:\finclaw\Logfile-25.CSV — bash fork chain, all STATUS_DLL_INIT_FAILED + WerFault
• D:\finclaw\Logfile-26.CSV — 243 bash processes, 31 WinSock2 registry ACCESS DENIED
• D:\finclaw\child-write-test\ — Rust repro: parent spawns child, child writes workspace (works under sandbox)

[Geeksfino]

Automated fix: A pull request is open for this issue.

• PR: Geeksfino/finsafe#179
• Status: In review — merge and public release are handled by a separate ship step.
• You will get another comment here when a public release is published.

[Geeksfino]

Automated dispatch: Cloud agent started for Geeksfino/finsafe.

• Agent: bc-ce0b2c09-0bae-424b-b2df-a993432d7f8f
• Run: run-dfa71988-2f7a-4b54-a4ed-3a499970c807

A PR will be opened when the agent finishes. Fixes will reference this issue.

[Geeksfino]

Status update (upstream review)

We opened an upstream fix attempt for this report (Geeksfino/finsafe#179). After risk review it was not accepted as an always-on change to the default RestrictedToken posture.

What we concluded

1. Your report is valid and reproducible as a Hermes/MSYS2 compatibility failure under restricted_token. Native Windows paths (cmd / direct child writes) already work — this is not a sandbox DACL / workspace-permission bug.

2. It is closer to an intentional weaker-path limitation than a FinSAFE deny-path regression. The RestrictedToken backend targets native Windows binaries. Cursor/Codex treat Git Bash CreateFileMapping Win32 error 5 the same way (sandbox incompatibility). Codex’s WRITE_RESTRICTED path only restores SeChangeNotifyPrivilege, not a broader privilege set.

3. The first fix hypothesis was rejected: always re-enabling SeCreateGlobalPrivilege after DISABLE_MAX_PRIVILEGE is the wrong default.

   • That privilege is for Global\ (cross-session) object creation and is not what ordinary (non-elevated) Users rely on for normal git-bash.
   • ACCESS_DENIED on the user-SID named mapping under RT is more likely a restricted-token / restricting-SID / object-namespace ACL interaction than “missing SeCreateGlobalPrivilege.”
   • Unconditionally restoring that privilege would widen Global-object creation when the parent token actually holds it (e.g. elevated), diverge from the Codex-aligned RT contract, and may be a no-op on typical UAC-filtered tokens (privilege never present / not fully assigned) while docs claimed a fix.

4. No Windows host acceptance proof was available for that privilege-widen approach, so we will not ship it as “MSYS2 fixed.”

What we did ship (docs)

WINDOWS-GUIDE (EN + ZH) now documents this trade-off on public main (docs-only sync; no CLI bump):

• https://github.com/finogeeks/finsafe/blob/main/docs/WINDOWS-GUIDE.md
• Via finogeeks/finsafe#30 → upstream port

Practical workarounds today

Approach	Notes
Prefer native Windows tool entry points (cmd.exe / PowerShell) for Hermes tools instead of git-bash	Matches RestrictedToken design
Use AppContainer where stronger isolation + different launch constraints fit the workload	Not a drop-in MSYS2 fix; path/ACL/ProjFS trade-offs apply
Treat RestrictedToken + MSYS2/git-bash agents as unsupported until a proven, opt-in design exists	Current product truth

Next engineering direction (if we reopen a runtime fix)

Preferred over always-on privilege widen:

• Agent-side native shell path for Hermes tools, and/or
• Explicit policy opt-in if we ever retain additional privileges, with Windows acceptance evidence that git-bash actually initializes under RT

We will comment again if/when a redesign lands and a public release ships. Thanks for the detailed Procmon / comparison table — that evidence is what made the review conclusive.

[Geeksfino]

Resolution of the first fix attempt

Private Geeksfino/finsafe#179 is closed without merge.

Your error string is the tell: CreateFileMapping S-1-5-21-…-1001.1 is a SID-named mapping, not a Global\\ object. RestrictedToken keeps your Windows user SID, so Git Bash under the sandbox hits the same name as host Git. Win32 5 is the WRITE_RESTRICTED token failing that open/create (object DACL / session namespace), not a missing SeCreateGlobalPrivilege. Native cmd working matches that: no MSYS2 shared section.

Workaround today: point Hermes at cmd.exe / PowerShell (unset HERMES_GIT_BASH_PATH) so tools do not spawn bash. Workspace writes were never the bug.

Next real fix (needs a Windows host): isolate the sandbox child’s object namespace so it does not share host \BaseNamedObjects. We will not switch this workload to AppContainer just to dodge git-bash — that reintroduces the slow node_modules ACL walk.

Design note: https://github.com/Geeksfino/finsafe/blob/main/docs/design/windows-rt-msys2-object-namespace.md

This issue stays open until that namespace work (or an equivalent) is proven on Windows 11.

[Geeksfino]

Fix in private PR: https://github.com/Geeksfino/finsafe/pull/275

Root cause was WRITE_RESTRICTED vs the host-created SID-named mapping (S-1-5-21-….1), not SeCreateGlobalPrivilege. The unrestricted parent now grants FinSAFE capability SIDs on that existing CreateFileMapping object.

Windows acceptance is dispatched on that branch (cmd-echo runs host git-bash first, then hermes-windows-oneshot.yaml bash -lc echo hello).

[Geeksfino]

Resolved — both layers of this report are in public releases.

The original CreateFileMapping S-1-5-21-….1 Win32 5 failure had two cases:

1. Direct bash.exe as the FinSAFE payload — fixed in v0.9.40 (capability SID grant on the host-created SID-named mapping). This is not SeCreateGlobalPrivilege.

   • Release: https://github.com/finogeeks/finsafe/releases/tag/v0.9.40
   • Merge: Geeksfino/finsafe#275

2. Hermes tools / cmd /c bash children (your write_file / terminal path) — a child under RestrictedToken still lacked the operator SID on WRITE_RESTRICTED, so Cygwin msys-*-sigwait died with ACCESS DENIED / 0xC0000142. That follow-up is finogeeks/finsafe#34, shipped in v0.9.41 as opt-in windows.msys2_child_ipc: true.

   • Release: https://github.com/finogeeks/finsafe/releases/tag/v0.9.41
   • Merge: Geeksfino/finsafe#283
   • Shipped hermes-windows-oneshot.yaml / hermes-windows-interactive.yaml already set the flag.

Upgrade to v0.9.41 and keep windows.msys2_child_ipc: true on the Hermes Windows policy. Default RestrictedToken still keeps NTFS write allowlisting; the flag attests that write allowlisting does not apply to user-owned objects for that session.

Install: see the release assets on the links above.