The only write confinement for Omnigent's unsandboxed workers did not bind on Windows
worktree_guard reasoned in POSIX terms but normalised with os.path, which is ntpath on Windows and rewrites forward slashes to backslashes. On a Windows runner normalized.startswith("/") was therefore never true and the absolute-path arm was inert: /etc/passwd carried no backslash, cleared the backslash guard, became \etc\passwd and returned ALLOW -- including paths into another worker's tree. The .. and ~ arms survived by coincidence. The project describes worktree_guard as the only write confinement for the unsandboxed implementer worker specs. Filed 2026-08-01, fixed 2026-08-03 with posixpath normalisation, a drive-letter arm, and four ALLOW-to-DENY cases pinned on Windows 11.
What this changes for operators
- The fix is on main and in no tag: v0.7.0 was published 2026-07-27, six days before the fix merged, and is still the newest release. An operator running the tagged release with unsandboxed implementer workers on a Windows runner does not have absolute-path confinement. Run main, or do not run those worker specs on Windows until the next tag.
Run: 2026-08-03-weekly-digest-2026-07-27_2026-08-03-frontier-v0
Schema: bitter.frontier_signals.v0 / ID: 2026-08-03-omnigent-worktree-guard-inert-on-windows
Research evidence and publication history are open in the repository.