最近在 Windows 上用 install.ps1 装了个源码环境，worker 一启动就崩，顺着查了两个地方。
一是 io.py 里 fsync 前是用 O_RDONLY 重新打开临时文件的，Windows 的 fsync 不接受只读句柄，直接 EBADF。Linux 上没这个限制所以一直没暴露。我改成了 O_RDWR，应该不影响 POSIX 语义。
二是还有几处裸的 import fcntl（session_store.py 的 _head_file_lock、checkpoint store 里三处），仓库其他地方都走 _compat 了，猜是漏掉的，就照现有惯例换成了 _compat。另外 _next_mutation_sequence 里那个目录 fsync 在 Windows 上也会炸，照同文件 _fsync_directory 的写法包了层 try。
补了两个回归测试（还原旧代码会红）。同一组测试在 main 上是 33 failed / 5 passed，打上补丁后 29 / 9，剩下的失败看起来是本来就在 Windows 上挂的，跟这次改动无关。ruff 是干净的。
分支在 GithungDang/OpenProgram/tree/fix/windows-compat，就三个文件加两个测试。你看这样改行不行，不行的话按你说的来。
另外还碰到两个疑似问题：bypass 档位没有真的解除沙箱（文案说"沙箱限制也不生效"，但实际没生效）；模型 thinking_levels 为空时还是会发 reasoning_effort，上游直接 400。这俩我不确定是不是有意设计，需要的话再单独开帖。
最近在 Windows 上用 install.ps1 装了个源码环境，worker 一启动就崩，顺着查了两个地方。
一是 io.py 里 fsync 前是用 O_RDONLY 重新打开临时文件的，Windows 的 fsync 不接受只读句柄，直接 EBADF。Linux 上没这个限制所以一直没暴露。我改成了 O_RDWR，应该不影响 POSIX 语义。
二是还有几处裸的 import fcntl（session_store.py 的 _head_file_lock、checkpoint store 里三处），仓库其他地方都走 _compat 了，猜是漏掉的，就照现有惯例换成了 _compat。另外 _next_mutation_sequence 里那个目录 fsync 在 Windows 上也会炸，照同文件 _fsync_directory 的写法包了层 try。
补了两个回归测试（还原旧代码会红）。同一组测试在 main 上是 33 failed / 5 passed，打上补丁后 29 / 9，剩下的失败看起来是本来就在 Windows 上挂的，跟这次改动无关。ruff 是干净的。
分支在 GithungDang/OpenProgram/tree/fix/windows-compat，就三个文件加两个测试。你看这样改行不行，不行的话按你说的来。
另外还碰到两个疑似问题：bypass 档位没有真的解除沙箱（文案说"沙箱限制也不生效"，但实际没生效）；模型 thinking_levels 为空时还是会发 reasoning_effort，上游直接 400。这俩我不确定是不是有意设计，需要的话再单独开帖。