Windows / WSL2 与 macOS 对齐调查

English

基线：bca1183fcc1cd9f4820bb54139ecdaaf63adfcf6，2026-09-07。 目标用户已经有 WSL2；目标是下载 Windows 包后，完成与 macOS 相同的科研操作。 分支现已在原调查之后加入产品修复。下方基线观察是历史记录，不能当作当前分支的运行结果。本次验收针对 WSL2 x86_64，不代表所有 Windows 配置均已认证。

已实现的修复

最终全量回归也复现了原有 HTTP 超时竞争：连接自身先超时、看门狗后触发时，异常类型不一致。修复集中在共用的有界读取层；测试分别覆盖两种顺序，并避免把无关的 TLS 证书加载放进仅 200 ms 的 socketpair 测试时限。

分层上，WSL 策略放在 security/wsl.py，加密存储放在 security/windows_dpapi.py，沿用现有内核协议、科学服务和 UI。环境检查、自定义工具这两个短进程也补齐沙箱描述符传递。硬链接扫描保留在团队隔离和 Windows 文件系统工作区，不再给每个普通 Linux 开发目录增加全树扫描。

验收包括 harness.smoke.wsl_sandbox、真实 Python/R 中断、离线回归、原生 PowerShell 5.1 启动器测试，以及实际 Windows 浏览器和安装包操作。最终结果见本文末尾的修复验收记录。

基线结论

WSL 能运行现有 Linux Python 内核，问题集中在产品没有准备齐运行条件，以及 Windows 与 Linux 之间多出的边界。 macOS 包已经准备了 Python、科学依赖和启动环境，系统另外提供沙箱与钥匙串。 WSL2 的存在并不保证发行版里有可用的沙箱、已解锁的密钥服务，或正确的 Linux 工具环境。

最优先的问题是 Cell 能通过 Windows 互操作绕过现有沙箱。 普通 Linux 边界 smoke 全部通过后，真实的 enforced Cell 仍然成功运行 Windows PowerShell，修改了沙箱工作区外的一个合成标记文件。 现有 smoke 的绿色结果不能作为 WSL 安全边界验收。

实测边界与证据

• 在独立 OpenAI4S-Parity-Test 发行版内，以普通用户执行。系统是官方 Ubuntu 24.04.4、x86_64、WSL2 内核 6.18.33.2-microsoft-standard-WSL2。
• 初始环境没有 bubblewrap、secret-tool、Rscript、Conda 或 Linux Node。之后仅在测试发行版安装 bubblewrap 0.9.0 和开发工具，再补装 libsecret-tools、gnome-keyring、dbus-user-session。
• 已验证源码复制步骤、真实 host.bash、真实 Python kernel、合成坏包安装和生成 CLI 的环境。CLI 环境探针使用假解释器，只证明 PATH 传递，不冒充完整安装包执行。
• 所有安全探针只使用临时目录和自建标记文件；没有读取真实密钥、调用模型供应商或修改 Docker 发行版。
• macOS 对照来自当前构建和运行代码，本机没有执行真实 macOS DMG。已有 WSL2 不代表任意发行版、网络模式、CPU 架构都已通过。
• 可复现探针与运行回执保留了观察结果。回执中的临时路径只说明本次运行，不是产品默认路径。

官方镜像 SHA-256：9b2f7730dc68227dd04a9f3e5eab86ad85caf556b8606ad94f1f29ff5c4fd3f5，与 Ubuntu 校验清单一致。

完整产物也已实测：Linux payload 约 406 MiB、解包约 1.4 GiB；现有验证器成功导入 38 个科学包。 从实际 Windows ZIP 解压到含中文和空格的目录后，PowerShell 5.1 启动器退出 0 并报告 ready，普通用户安装与 daemon 启动成功。 Windows 访问测试端口得到未认证 401、认证后首页 404，安装目录确实没有默认 UI。 这证明连接和认证能够工作，而产物及 ready 检查没有覆盖默认页面。 真实 launcher 的 status 返回运行中的同一 PID，重复打开复用该 daemon，stop 返回 0，停止后 status 返回 1 并报告 not running；测试 daemon 已停止。 补装密钥组件后，D-Bus ReadAlias(default) 返回 /，Collections 仅有 session；SecretBroker 的存储自检超时，未得到可持久使用的默认密钥库。

从上到下：用户流程

flowchart LR
    A[Windows 解压并双击] --> B[选择 WSL 发行版和用户]
    B --> C[检查依赖并安装 Linux payload]
    C --> D[启动 Linux daemon]
    D --> E[Windows 浏览器打开认证地址]
    E --> F[配置模型与保存密钥]
    F --> G[上传数据并执行 Python / R / Bash]
    G --> H[查看与下载产物]
    H --> I[停止、重开、更新与恢复]

浏览器上传、下载和 WebSocket 已有 HTTP 通道，先验证这些通道，不需要先设计 Windows/Linux 全盘路径转换。 代理、Fake-IP、localhost 转发和回退已有实现，但本次未改变全局网络设置，不能把某一个网络模式通过推广到所有机器。

已确认的问题与调用链

Python 的 POSIX shell=True 默认调用 /bin/sh，见 subprocess 文档。 这些问题不支持“WSL 的 Linux syscall 普遍不兼容”的结论；它们各有具体的环境或流程原因。

从下到上：脚本与进程盘点

逐文件清单记录了基线的全部 226 个 .sh / .command / .ps1 / .cmd 文件、6 个生成的 shell heredoc，以及 25 处直接可识别的 Python subprocess / host.bash 调用。 还有两个远程计算 .sh.tmpl 模板，需要按渲染后的运行环境判断，不能混同桌面启动器。 224 个 .sh / .command 在真实 Ubuntu Bash 下全部通过 bash -n；语法通过不是依赖齐全，也不是工作流通过。 AST 清单不保证捕获动态别名、生成代码或配置里的任意命令。 针对领域 shell 脚本检索 brew、osascript、pbcopy/pbpaste、/Applications、/Users、/opt/homebrew 等 macOS 特征未发现匹配；这只排除了这组明确特征，不能替代逐工作流运行。

R、Conda、完整领域 CLI 未随 macOS 基础包提供，属于共同的能力准备问题。 Stage 1 standard-profile 门禁默认关闭；不能根据它在开启时要求 named python/r 环境，推断默认 Python 必然不能运行。

验证记录

现有 CI 和 release 的 windows-launcher job 覆盖 PowerShell 解析及「机器没有 WSL 时正确拒绝」，没有执行有 WSL2 的安装成功路径。 Linux runner 的沙箱 smoke 也不包含 Windows 互操作。因此修复后需要独立的真实 WSL2 验收，不能只依赖这两个现有绿色检查。

测试条件需要区分：第一次直接调用 .venv/bin/pytest 时，uv 未进入 PATH，产生 1 个发布构建命令断言失败；中断时另有 5172 passed / 103 skipped。改用正确 PATH 与 uv run 后，该失败项单独通过。随后磁盘上的全量尝试因 I/O 等待中断，1951 passed / 38 skipped，未算作全量通过。最终离线回归使用普通用户、私有内存临时目录，并保留失败用例数据；实际安装、密钥、沙箱和重定位探针使用真实 Windows/WSL 文件系统。

完整运行中，tests/test_mcp_client.py::test_streamable_http_body_watchdog_interrupts_a_chunked_slow_drip 得到原始 TimeoutError，而测试期待 MCPTimeout；tests/test_skill_product_surface.py::test_team_member_cannot_reactivate_legacy_host_skill_poison_over_http 的 HTTP helper 没有收到状态行。两项单独复验通过，根因尚未确定，不能归因于 WSL、tmpfs 或本次文档/探针改动。唯一 warning 来自刻意模拟原生 win32 不支持沙箱的测试。

修复顺序与完成条件

1. 先闭合 WSL 边界并确定安全密钥方案。 新增真实 WSL 回归，涵盖 Windows 进程/IPC、文件与凭据读取、路径别名及网络通道。验证停止和持久 Python/R 仍然可用；不要依赖全局关闭用户机器的 WSL 功能来通过测试。
2. 修正共享产物与执行环境。 默认 UI、资源检查、bundle CLI PATH、Linux 工具发现、console script 重定位、前后台 Bash；验收从 ZIP 解压后的应用出发，隐藏构建目录，不能依赖开发机已有 Python/Node/Conda。
3. 完成 Windows 启动与恢复流程。 发行版能力探测、缺依赖准备、解包后切换、管理命令脱离新包、运行版本识别和安全重启；覆盖空格/中文路径、坏包、重复启动及并发。
4. 走完整科研流程和重启回归。 配置真实模型、上传 CSV、Python/图表/下载、准备 R、代表性专业 CLI、Stop 后继续、关闭重开、WSL 重启和升级。MCP/Ark 登录作为相应扩展能力单独验收。

未完成项：真实 macOS 对照运行、Windows on ARM、多发行版、多网络模式、真实供应商登录/模型调用、所有领域脚本、WSL/Windows 重启后的完整产品恢复。 这些是明确的待验收范围，不应写成已经通过。

复现

在普通 WSL 用户的干净 checkout 中，先确保有 Bash、rsync；沙箱探针需要 bubblewrap。 将下例的 Windows 临时目录换成自己已有的目录；脚本只在其中新建并清理自己的随机子目录。

python3 scripts/probe_wsl_parity.py \
  --windows-scratch /mnt/c/path/to/audit-temp \
  --output /tmp/wsl-parity.json
OPENAI4S_KERNEL_SANDBOX=enforce python3 -m harness.smoke.linux_sandbox

第一条命令退出 0 只代表收集完毕，要读取 JSON 中的失败观察，特别是 windows_marker_changed。 第二条在当前基线能通过，却覆盖不到第一条证实的 Windows 互操作问题。

对实际安装包的重定位，使用自己构建时的目录和安装后的路径执行下面的检查。 --tmpfs 只在这个子进程的 mount namespace 内遮住构建目录，不会删掉或移动实际目录。 本次第一条 f2py 执行失败，后两条成功；包内另有 21 个命令带同类绝对 shebang，未声称全部逐个执行。

PARITY_APP=/path/to/installed/OpenAI4S-0.2.0-linux-x86_64
PARITY_BUILD_ROOT=/path/to/checkout/.build
bwrap --unshare-net --ro-bind / / --tmpfs "$PARITY_BUILD_ROOT" \
  --dev /dev --proc /proc -- "$PARITY_APP/runtime/bin/f2py" -v
bwrap --unshare-net --ro-bind / / --tmpfs "$PARITY_BUILD_ROOT" \
  --dev /dev --proc /proc -- "$PARITY_APP/runtime/bin/python3" -m numpy.f2py -v
bwrap --unshare-net --ro-bind / / --tmpfs "$PARITY_BUILD_ROOT" \
  --dev /dev --proc /proc -- "$PARITY_APP/runtime/bin/pip" --version

并发构建、安装和全量测试期间还观察到 WSL 服务连接超时 (0x8007274c)；一次 launcher 将失败展示为目录不可达，而同一中文/空格目录此前已成功安装。 本轮没有确定服务超时的根因，也不据此认定 Unicode 路径不兼容。后续应单独验证 WSL 服务故障时的超时、重试和诊断信息。

修复验收记录 — 2026-09-07

以下结果更新了上方的基线失败记录。测试仍在隔离的 Ubuntu 24.04 WSL2 x86_64 发行版内以普通用户运行；Windows 浏览器为 Chromium，启动器使用 Windows PowerShell 5.1。核心没有新增第三方依赖。

• 真实 WSL smoke 在强制隔离下通过：Windows 程序、复制到工作区的程序与互操作加载器、宿主进程路径别名、互操作 socket 和 Hyper-V socket 都不能绕过边界。受隔离的环境探针和动态工具能够运行。Python 与 R 都能在中断后继续使用原变量；R/jsonlite 是测试准备项，没有加入基础安装包。
• 实际 Windows 浏览器完成了认证、默认页面与资源加载、通过 DPAPI 保存/删除合成模型密钥、CSV 原样上传下载、均值 2.0 的计算、PNG 展示与下载、结果表精确校验、刷新后继续使用 dataframe、中断后继续计算和 Notebook 导出。Notebook 执行显式开启了 OPENAI4S_NOTEBOOK_REPL=1；没有调用真实模型供应商。
• 最终 payload 的随包 Python 和科学依赖运行校验通过。最终 Windows ZIP 的原生校验通过，覆盖 payload 摘要、PowerShell ASCII、CRLF/LF 和资源契约。wheel/sdist 构建及校验通过。全文件 pre-commit、严格 mypy、160 个目录的双语索引和源码凭据扫描通过；离线场景 harness 为 38/38 通过。
• 最终 ZIP 从 Windows 源码 checkout 工作目录启动后，通过了上述科研流程。启动器退出后，连续 120 秒的五次纯 Windows 健康检查均成功；期间没有通过 WSL 命令或 UNC 读取维持发行版运行。
• 在旧服务运行时安装最终 payload，旧 PID、运行包身份和内存中的 dataframe 均保留，已保存的结果内容完全一致。正常停止并仅重启测试 WSL 发行版后，最终包重新打开原结果，重新读取输入 CSV 算出总和 6。合成 DPAPI 密钥在重启后仍能读取，随后删除成功。这不表示内存变量能跨服务重启保存。
• 在没有 payload 的启动器目录中，管理命令仍然可用。最终包正常停止返回 0；较早一次停止超过默认五秒等待而返回 2，随后自行退出并释放隐藏 WSL 进程，没有使用强制停止。
• 更广的现有浏览器 smoke 在没有并发构建时，仍超过了 20 秒的排队准入等待。单独带计时的诊断观察到 18.585 秒后正常接手，其中创建内核 0.447 秒、科学环境初始化 10.247 秒；早先有负载时为 39.1 秒。未经修改的完整浏览器脚本未通过，首次计算的性能对齐仍未认证。并发负载下还出现过 WSL 服务连接超时。
• 并发全量回归在约 83% 时被 4 GB 测试虚拟机的 OOM 终止，未记作完整通过。清理负载后，独立启动又暴露 W11：脱离终端的 Linux 服务不能阻止本机 systemd WSL 发行版自动停止。相关生命周期差异也见 Microsoft 的说明。修复由 Windows 启动器持有服务进程，不修改全局 WSL 设置。
• 最终独立全量离线回归完成：8345 通过、107 跳过、0 失败，耗时 1052.39 秒；唯一警告来自预期的不支持平台沙箱测试。使用两个测试进程和私有的 1 GiB tmpfs 临时目录，后段在隔离发行版内添加的 2 GiB 交换文件已停用并删除。内核生命周期/MCP 专项 37 项通过，打包/WSL 专项 113 项通过，Windows PowerShell 5.1 启动器契约测试通过。

归档摘要与最终运行回执记录在证据 JSON 的 fix_verification 中。构建验证复用了此前完整组装的科学运行时，并用产品修复后的代码重新执行构建器的源码复制、CLI 生成、字节码编译、完整 Linux 验证与 Windows 打包步骤。

这些证据覆盖 WSL2 x86_64，不代表已认证真实 macOS 执行、ARM、任意发行版/网络模式、真实供应商登录与推理、Windows 整机重启、Conda 环境准备或全部领域工作流。