Repository navigation
Windows: "secure control-bus path opening is unavailable" blocks all runs (POSIX-only dir_fd/O_NOFOLLOW) #63
Description
Environment
- OS: Windows 10 19045, Python 3.11.15 (cp311)
- lh-harness: 0.1.7 (pip) — also confirmed present in
mainbranch source - Backend tried:
deepseek_harness(dsh 0.1.1-rc.2, Node 24.14) with a SiliconFlow-compatible base_url; same failure with any backend because it happens during run bootstrap
Symptom
Any lh-harness run fails immediately at startup:
Cannot start run: safe run-control path opening is unavailable
Using config: ...\.lh-harness\config.toml
with task passed inline (--task "...") it becomes:
Cannot start run: unsafe run directory layout: secure control-bus directory creation is unavailable
Root cause
src/lh_harness/supervisor/control_bus.py (and dashboard/state.py) rely on POSIX-only primitives:
os.open(..., dir_fd=...)/os.mkdir(..., dir_fd=...)—dir_fdis not supported on Windows;os.supports_dir_fdexcludesos.open/os.mkdiron win32os.O_NOFOLLOW/os.O_DIRECTORY— no Windows equivalents
_open_nofollow() and _ensure_dir_fd_nofollow() raise OSError("secure control-bus path opening is unavailable") on win32, so run bootstrap (reserving the run directory, writing owner metadata, task file read) can never succeed. README states "Windows 已支持，但尚未经过详细测试" — in practice the control-bus layer makes the CLI unusable on Windows.
Suggested direction
- Add a win32 fallback in
_open_nofollow/_ensure_dir_fd_nofollow(e.g.os.open(path, os.O_RDONLY | os.O_BINARY | getattr(os,'O_NOINHERIT',0))— WindowsCreateFileWsemantics; symlink protection via(stat.FILE_ATTRIBUTE_REPARSE_POINT)check onos.lstatof each component) or - Gate the secure path walk behind a capability flag so win32 uses plain (bounded) path reads until a native implementation lands.
Happy to help test a fix on this machine.
Activity
Art-Off-Man commentedon Aug 29, 2026
Independent confirmation (second environment): Windows 11 x86_64, Python 3.12 (uv-managed), lh-harness 0.1.7 from PyPI via
uv tool install, backend dsh 0.1.1-rc.2. Same unconditional bootstrap failure, with or without dashboard.Additional failure observed once past the guards:
os.open(run_dir, O_RDONLY|O_DIRECTORY)→PermissionError [WinError 5]— Windows requiresFILE_FLAG_BACKUP_SEMANTICSto open a directory handle. So a fix must cover thedir_fdflow (fd→anchored-path registry), not just flag/fcntlavailability.Full failure matrix and candidate fixes: see #70, #66, #57. We will test the PR branches on this machine and report back.
liyangbing commentedon Aug 30, 2026
Useful second confirmation. The DSH backend is not the first failing boundary here: lh-harness reaches run bootstrap, then the Windows control-bus capability check fails before model or provider traffic is relevant.
For a cross-platform fix, keep these gates independent:
That decomposition makes the 402-pass result in #70/#66 easier to trust: the regression matrix should show each boundary’s failure evidence, not only end-to-end success. Related independent runbook: https://sandbaseai.github.io/deepseek-harness-handbook/windows-shell-capability.html
Disclosure: I maintain the independent DeepSeek Harness Handbook. It is not an official DeepSeek AI project. The guide links official DSH source and keeps permission and sandbox claims separate from host-process and shell claims.
Upper9527 commentedon Oct 21, 2026
Confirmed, and thanks for the additional boundary analysis. This is now consolidated in #70 together with #77/#81/#88. I reviewed #66/#86/#87 and requested concrete changes rather than merging a flag substitution or best-effort path check as equivalent filesystem isolation.
Closing this report as a duplicate, not as fixed. Native Windows remains blocked in v0.1.7; the README is corrected in #92. WSL2 with the harness and agent CLI installed inside Linux is the current workaround. Please continue platform test evidence in #70.
fix: Add Windows support for control-bus secure path operations