Windows 10 1607: v0.10.1 fails to start — unresolved load-time import DeriveCapabilitySidsFromName (0xC0000139) #6953

Before you start

• I searched existing issues and this is not a duplicate. 我已搜索过现有 issue。

What happened? 发生了什么？

After updating from v0.10.0 to v0.10.1 on a Windows 10 Pro 1607 (build 14393.447) machine, the app no longer starts. Before anything runs, Windows shows the loader dialog:

无法定位程序输入点 DeriveCapabilitySidsFromName 于动态链接库 …
(EN: The procedure entry point DeriveCapabilitySidsFromName could not be located in the dynamic link library …)

and the process exits with 0xC0000139 (STATUS_ENTRYPOINT_NOT_FOUND) — no stdout, no logs. v0.10.0 (official asset, same machine) starts fine and prints codewhale 0.10.0 (1be1a703b975).

Root cause: the v0.10.1 executable has exactly one load-time import this Windows build cannot resolve — api-ms-win-security-base-l1-2-2.dll!DeriveCapabilitySidsFromName (that API set forwards to KERNELBASE.dll; on this build, KERNELBASE/kernel32/userenv and the security API sets do not export the function). Because it is a static, non-delayed import, the loader fails before main — regardless of the fact that the only consumer (the extension-host LPAC sandbox, crates/tui/src/extension_host/windows.rs, the registryRead capability SID derivation from the 0.10.1 LPAC work af5fa5c23 / 935c08662) is experimental and off by default (extension_host = false).

Import-surface audit of the two official Windows binaries (every imported (dll, function) pair checked with GetProcAddress on this 1607 system):

• v0.10.0 — 411 imports / 29 DLLs — 0 unresolved
• v0.10.1 — 454 imports / 31 DLLs — 1 unresolved (the symbol above); nothing else is missing, and no OS-version gate or PE-header OS-version bump was introduced

The current main still contains the same call, so any 0.10.2-line build will fail the same way on this OS.

Steps to reproduce 复现步骤

1. On Windows 10, version 1607 (build 14393), take the official v0.10.1 asset codewhale-windows-x64.exe (sha256 76a6156b…d22729, matching the release's codewhale-artifacts-sha256.txt).
2. Run codewhale.exe --version (or the .bat launcher).
3. The loader dialog appears and the process exits with 0xC0000139; no output. For contrast, the v0.10.0 asset on the same machine prints codewhale 0.10.0 (1be1a703b975) and exits 0.

Codewhale version 版本

0.10.0

Where did it happen? 在哪里出现？

TUI (terminal interface)

Operating system 操作系统

Windows

How did you get Codewhale? 获取方式

GitHub Releases download

Provider and model 提供商和模型

No response

Terminal and shell 终端

No response

codewhale doctor (optional)

Logs, screenshots, anything else (optional)

Proposed solution

Requirement-level scope (implementation follows the project's own conventions; no specific files or code are prescribed):

1. The registryRead capability SID does not have to come from that API — it is a stable, deterministic value that can be checked against the OS API on any Windows runner that has it. The sandbox can obtain it without a static import from a module that older Windows builds do not provide (runtime resolution, or obtaining the value another way — the project's call).
2. On builds without the capability API, refuse Native-host activation with a clear, feature-scoped error (consistent with the documented macOS/Linux "otherwise activation is refused" behavior) instead of failing the whole process at startup.
3. Keep LPAC behavior and the token checks unchanged on Windows versions that support them today.
4. Consider documenting the oldest supported Windows build and keeping release binaries within it, with a release-time check that every import resolves on that floor — this class of regression would then be caught before shipping.