实测现象
在 Windows（本机 GetACP() == 936）上，mcpp 2026.9.25.1 从含有当前 ANSI 代码页无法表示的字符的工作目录启动时，连 --version 都会无输出地退出：
PS D:\VSProj> mcpp -- version
mcpp 2026.9 .25.1
PS D:\VSProj\mcpp- unicode- repro- 🧪> mcpp -- version
PS D:\VSProj\mcpp- unicode- repro- 🧪> $LASTEXITCODE
-1073740791 # 0xC0000409 同一目录下 mcpp build --configure-only 也是无输出、同一退出码。目录里放了最小的 mcpp.toml 和 src/main.cpp，但 --version 已能复现，因此故障发生在读取源码之前。ASCII 工作目录下同一 mcpp.exe 正常。这个签名比 #518 A 中的“没有源文件”更早，也不能靠改进 glob 的诊断覆盖。
同机的 mcpp 自带 Ninja 1.12.1 在该目录能正常运行，ninja.exe -t wincodepage 输出 Build file encoding: UTF-8。Ninja 上游也随 Windows 版本提供 UTF-8 activeCodePage manifest 。这说明当前复现至少不是 Ninja 首先拒绝工作目录；其他编译器和构建工具仍需逐一验证。
与已有问题的关系
这个新复现聚焦进程启动/命令分派阶段 的静默终止，并希望把修复和后续验证的边界写清楚。
建议方案
先修 mcpp 自己和 mcpp 生成的 build.mcpp.exe。 在 Windows PE 产物里嵌入 activeCodePage=UTF-8 manifest（Windows 10 1903+ 支持），让 MSVC STL 的窄路径转换与构建图中的 UTF-8 字符串一致。mcpp.exe 可走现有 [resources] 构建能力；build.mcpp.exe 是单独的 host 编译/链接路径，需要单独接入。同一阶段修掉 --version 的静默退出，失败时至少给出准确诊断。Microsoft 的应用程序 manifest 文档 说明了这个设置及系统版本要求。把 mcpp 的 Unicode 边界显式化。 内部/build.ninja/CDB 的路径字节约定为 UTF-8；进入 Win32 文件、命令行和环境 API 时使用 UTF-16/W API，或明确做 UTF-8↔UTF-16 转换。目前 Windows bounded process 路径仍使用 CreateProcessA、GetEnvironmentStringsA；只依赖进程 ACP 会让这个约定隐含在 manifest 和 OS 版本里。这个重构可以分阶段做，不必阻塞第 1 步的止血。按实际工具链验证下游，而非要求所有第三方工具统一补 manifest。 先检查 mcpp 固定使用的 Ninja（例如 -t wincodepage），再分别测试编译器驱动、链接器、资源编译器和项目声明的 host tool/action。第三方可执行文件的代码页不会因为 mcpp 的 manifest 自动改变；如果某一环不能消费 Unicode 路径，应点名该环和失败的路径，而不是宣称整个构建已受支持，也不宜静默修改第三方 exe。
建议验收
Windows CI 测试先确认 GetACP() != 65001，否则该回归用例不构成证据；在含 🧪 的工作目录运行 mcpp --version 和 mcpp build --configure-only，均应正常退出并有预期输出。
在相同目录构建最小 build.mcpp 项目，再测试含非 ACP 字符的成员目录和源文件名；验证 Ninja 构建文件、CDB 与子进程收到的路径没有乱码。至少对一条固定的 Windows 工具链实测端到端成功；其他工具链若有边界，应给出分阶段诊断。
保留 Windows: 进程 ACP 之外的路径,mcpp 只能跳过而不能构建 #518
实测现象
在 Windows（本机
GetACP() == 936）上，mcpp 2026.9.25.1 从含有当前 ANSI 代码页无法表示的字符的工作目录启动时，连--version都会无输出地退出：同一目录下
mcpp build --configure-only也是无输出、同一退出码。目录里放了最小的mcpp.toml和src/main.cpp，但--version已能复现，因此故障发生在读取源码之前。ASCII 工作目录下同一mcpp.exe正常。这个签名比 #518 A 中的“没有源文件”更早，也不能靠改进 glob 的诊断覆盖。同机的 mcpp 自带 Ninja 1.12.1 在该目录能正常运行，
ninja.exe -t wincodepage输出Build file encoding: UTF-8。Ninja 上游也随 Windows 版本提供 UTF-8 activeCodePage manifest。这说明当前复现至少不是 Ninja 首先拒绝工作目录；其他编译器和构建工具仍需逐一验证。与已有问题的关系
activeCodePage=UTF-8的方向，并明确指出仅给 mcpp 加 manifest 不等于端到端支持 Unicode 路径。这个新复现聚焦进程启动/命令分派阶段的静默终止，并希望把修复和后续验证的边界写清楚。
建议方案
build.mcpp.exe。 在 Windows PE 产物里嵌入activeCodePage=UTF-8manifest（Windows 10 1903+ 支持），让 MSVC STL 的窄路径转换与构建图中的 UTF-8 字符串一致。mcpp.exe可走现有[resources]构建能力；build.mcpp.exe是单独的 host 编译/链接路径，需要单独接入。同一阶段修掉--version的静默退出，失败时至少给出准确诊断。Microsoft 的应用程序 manifest 文档说明了这个设置及系统版本要求。build.ninja/CDB 的路径字节约定为 UTF-8；进入 Win32 文件、命令行和环境 API 时使用 UTF-16/W API，或明确做 UTF-8↔UTF-16 转换。目前 Windows bounded process 路径仍使用CreateProcessA、GetEnvironmentStringsA；只依赖进程 ACP 会让这个约定隐含在 manifest 和 OS 版本里。这个重构可以分阶段做，不必阻塞第 1 步的止血。-t wincodepage），再分别测试编译器驱动、链接器、资源编译器和项目声明的 host tool/action。第三方可执行文件的代码页不会因为 mcpp 的 manifest 自动改变；如果某一环不能消费 Unicode 路径，应点名该环和失败的路径，而不是宣称整个构建已受支持，也不宜静默修改第三方 exe。建议验收
GetACP() != 65001，否则该回归用例不构成证据；在含🧪的工作目录运行mcpp --version和mcpp build --configure-only，均应正常退出并有预期输出。build.mcpp项目，再测试含非 ACP 字符的成员目录和源文件名；验证 Ninja 构建文件、CDB 与子进程收到的路径没有乱码。至少对一条固定的 Windows 工具链实测端到端成功；其他工具链若有边界，应给出分阶段诊断。