Track native Windows controller and artifact portability

[adithya-s-k]

The CLI startup regression in #128 is being fixed in #129, with real Windows process locks and fresh-wheel checks on Python 3.12–3.14. Full native Windows controller support needs separate work.

The contributor reported 249 failures and 97 errors in the all-extras Windows suite. Those counts are their report, not independently reproduced here. Local code inspection identified these concrete gaps:

• Bundle identities require POSIX 0644/0755 modes. Windows chmod cannot represent those modes; preserve meaningful, stable permissions in manifests and exported archives without weakening identity checks.
• Tasksmith controller snapshots use POSIX permissions, and local author cleanup uses process groups / killpg. The OpenCode adapter explicitly requires Linux or macOS for cleanup. Add a supported Windows lifecycle or fail before allocating paid work.
• Audit host-side text I/O and subprocess encodings for UTF-8 and line endings. Keep Linux sandbox behavior separate from host portability.

For now, use Linux, macOS or WSL for Tasksmith, research-recipe generation and quality-loop execution. A remote Daytona/Modal worker does not remove host-side requirements. Basic installed CLI, discovery, native emission and static validation have a dedicated Windows CI gate.

Acceptance: reproducible categorized Windows failures; targeted fixes with native Windows tests; unchanged bundle identity, controller exclusivity and budget protections; a documented supported-command matrix. This is not a reason to skip or relax artifact integrity checks.

[KNambiarDJsc]

Independently reproduced, on a separate machine from where I first reported the counts, on the current main tip (022d1bd, repo2rlenv 0.9.1 — after #129, so unrelated to the startup crash):

uv sync --group dev --all-extras
uv run --all-extras pytest -q

	Linux (WSL Ubuntu)	Windows 11
Result	1866 passed, 0 failed	1525 passed, 249 failed, 97 errors, 7 skipped

Same 249/97 as before — nothing excluded, and I confirmed neither number is an artifact of my earlier --group dev-only (non---all-extras) setup.

I traced the actual error text behind every failure/error rather than just counting test names, so here's the categorized, reproducible breakdown your acceptance criteria asks for:

1. The 0o644/0o755 bundle-mode check — the large majority of both counts.

src/repo2rlenv/emitter/bundle.py:158

mode = item.stat().st_mode & 0o7777
if mode not in {0o644, 0o755}:
    raise ValueError(f"Unexpected task asset mode: {relative}: {oct(mode)}")

This matches your own "Bundle identities require POSIX 0644/0755 modes" note exactly. os.stat().st_mode & 0o7777 on Windows is 0o666 (or 0o444 read-only) for every file, never 0o644/0o755, so this one check — called from a shared bundle-inspection helper many fixtures rely on — accounts for the bulk of everything. Isolated per-file runs: tests/test_quality_loop.py is 67 of its 70 failures, byte-identical message. Same story in test_quality_probe_recovery.py, test_quality_probe_behavior.py, test_quality_rollout_consistency.py, test_task_labels.py, test_release.py, and most of the rest.

2. os.killpg — matches your "local author cleanup uses process groups / killpg" note. 5 sites, all unconditional:

src/repo2rlenv/execution/job.py:95
src/repo2rlenv/pipelines/recipes/swe_smith/grade.py:162
src/repo2rlenv/pipelines/recipes/terminal/grade.py:51
src/repo2rlenv/tasksmith/author/external_agent.py:121
src/repo2rlenv/tasksmith/author/external_agent.py:126

Doesn't show up prominently in my error-message dedup — likely because it manifests as a hang/timeout on Windows (blocking on a subprocess that never gets killed) rather than a clean exception, so it wouldn't necessarily be in my failed-test count at all; worth someone checking test_tasksmith_native_stages.py / test_tasksmith_worker_release.py specifically, since those are the ones exercising author-cleanup paths. Flagging honestly that I haven't pinned this one down myself.

3. os.chown — real usage plus test fixtures that can't neutralize it.

src/repo2rlenv/pipelines/recipes/swe_smith/grade.py:98   os.chown(path, 0, 0)
src/repo2rlenv/pipelines/recipes/swe_smith/grade.py:129  os.chown(working, 1001, 1001)

os.chown isn't just "raises when called" on Windows — the name isn't on the os module at all. Several test files do monkeypatch.setattr("os.chown", lambda *args: None) (test_repository_source_collection.py, test_tasksmith_added_source.py, test_tasksmith_verifier_selection.py, test_verifier_editor_backups.py, and a few more), and monkeypatch.setattr with a string target has to resolve the attribute to override it — so it raises AttributeError before the test body runs. Accounts for most of the 97 setup-time errors.

4. Symlink creation needs elevated privilege on a default Windows account (WinError 1314).

One real product site — src/repo2rlenv/execution/hub_asset_alias.py:100 (HF model-cache aliasing) — would fail for real users on a non-elevated machine, not just tests. Much more commonly it's test fixtures constructing a symlink to verify the product correctly rejects one (test_snapshot_document_links.py, test_task_bundle.py, test_tasksmith_readiness_preflight.py, test_quality_probe_audit.py, test_hub_asset_aliases.py, test_native_verifier_recovery.py, test_repository_source_collection.py) — Path.symlink_to() needs admin or Developer Mode on Windows by default. Worth separating "product mishandles symlinks" from "test suite needs an OS capability a default account doesn't have" when triaging these.

5. CRLF vs LF breaks byte-exact patch application in tasksmith/worker.py.

tests/test_tasksmith_source_patch.py → repo2rlenv.tasksmith.worker.reverse_source: 9 of 13 fail. git apply rejects patches (trailing whitespace / patch does not apply), and a separate assertion shows a written file with \r\n where \n was expected. Nothing in tasksmith/worker.py sets core.autocrlf=false (or equivalent) around its git calls, so Windows Git's usual core.autocrlf=true default silently rewrites line endings and the downstream byte-exact comparisons stop matching. Matches your "audit host-side text I/O ... for line endings" note.

6. (Minor, 1 occurrence) one more instance of the locale-encoding class fixed in #115 — UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d, same shape (a read without encoding="utf-8") but in code outside that PR's scope (which was subprocess(text=True, ...) calls specifically). Didn't pin the exact call site; can if useful.

Happy to send a PR for #1 — it's the highest-impact and most mechanical of these — if that's useful, otherwise leaving this here as the categorized starting point your acceptance criteria wants.

[KNambiarDJsc]

Correcting something I said above. I called #1 (the file-mode check) "the highest-impact, most mechanical" fix and offered to send a PR for it — after actually reading emitter/bundle.py rather than just the failure text, that's wrong, and I want to flag why before anyone (including me) reaches for a quick platform-guard patch on it.

The mode isn't just being validated — it's an input to the bundle's identity hash:

# write_bundle(): the author's intent (0o644/0o755) is chmod'd onto disk...
path.chmod(asset.mode)

# ...and that same intent is embedded in bundle_hash() at emission time:
"files": {name: {"sha256": ..., "mode": asset.mode}, ...}

# inspect_bundle() later has no access to the author's original intent — it
# can only reconstruct "was this executable?" from what the filesystem
# reports back:
mode = item.stat().st_mode & 0o7777
files[relative] = TaskFile(item.read_bytes(), mode == 0o755)

On POSIX, chmod → stat round-trips, so this is a real tamper/corruption check: if the hash inspect_bundle recomputes doesn't match claimed_hash, something changed. On Windows, NTFS doesn't track a POSIX-style owner-execute bit for regular files at all — stat().st_mode reports 0o666 after chmod(0o755) exactly the same as after chmod(0o644), unconditionally. That's not a wrong API call to swap out; it's the OS itself not persisting the information this scheme needs to round-trip.

So a same-shape fix to my fcntl/#129 patch — skip the check, or widen the accepted set on Windows — would either (a) make inspect_bundle unable to tell solution/solve.sh was meant to be executable, which fails configuration()'s own "Task requires a nonempty executable {required}" check, or (b) silently produce a different hash than the one stamped at emission, so integrity_passed would read False for every bundle on Windows regardless of whether anything was actually tampered with. Given your note above ("this is not a reason to skip or relax artifact integrity checks"), I don't think either is acceptable, and I'm not going to open a PR pretending this is mechanical when it isn't.

The real fix, I think, is recording executable-intent out-of-band from the filesystem — e.g. an explicit list of executable paths carried in the bundle's own metadata (task.toml or a small sidecar), which inspect_bundle reads instead of inferring from stat(). That's a real, if small, protocol change to the bundle format everyone downstream consumes, so it's a design call for you to make, not something I should just ship. Happy to prototype it if that direction sounds right, but wanted to flag the actual shape of the problem rather than let "#1 is the easy one" stand uncorrected.

Picking up #2 (os.chown, genuinely a same-shape platform guard as #129) and the CRLF issue (#4) instead, since those don't touch anything security-relevant.

[KNambiarDJsc]

Opened #136 for #2 (os.chown) and #4 (CRLF) — turned out #4 was really "git apply isn't hermetic against the caller's global git config" (core.autocrlf=true, the Git-for-Windows installer default, was silently corrupting patch application outside of any repo-local override). Full before/after numbers and root-cause detail are in the PR description.

Also found one adjacent thing while in there: test_verifier_editor_backups.py's "fifo" parametrize case uses os.mkfifo, which has no Windows equivalent at all — skipped that one case on win32 in the same PR since it's the same "API doesn't exist" shape as os.chown, not the symlink-privilege issue.

[adithya-s-k]

Thanks for the detailed investigation and #136, now merged. I recommend WSL for full generation and quality workflows for now. We'll keep the basic Windows CLI supported and leave this issue open for native Windows support. Let's preserve the artifact-integrity checks and handle file modes, symlinks and process cleanup properly before expanding support.

[KNambiarDJsc]

Following up on the file-mode item now that #136/#140/#141 are through, and on the ask to handle it properly rather than skip/relax it.

Root cause, precisely: the asymmetry isn't "Windows can't do os.stat/chmod" — it's that bundle_hash() (write side, emitter/bundle.py) already gets mode from the in-memory, always-correct TaskFile.executable flag, while inspect_bundle() (verify/resume side) instead re-derives mode from item.stat().st_mode & 0o7777. That's a real round-trip on POSIX (chmod → stat), but NTFS has no POSIX owner-execute bit for regular files at all, so stat() reports 0o666 unconditionally on Windows — not "sometimes wrong," structurally incapable of carrying this information.

Proposal: stop inferring executable-intent from the filesystem on the read side. Record it explicitly, out-of-band, in task.toml's existing [metadata.repo2env] extension:

# write_bundle() / bundle_hash():
configuration["metadata"]["repo2env"]["executable_files"] = sorted(
    name for name, asset in files.items() if asset.executable
)
# ...this is now part of what _identity() hashes, same as any other config field.

# inspect_bundle():
configuration = tomllib.loads((path / "task.toml").read_text(encoding="utf-8"))
executable = set(configuration.get("metadata", {}).get("repo2env", {}).get("executable_files", []))
...
if sys.platform != "win32":
    # Real chmod-tamper detection, exactly as strict as today — NTFS can't
    # persist this bit at all, so there's nothing meaningful to cross-check
    # on Windows; the hash itself still covers executable-intent via the
    # (content-hashed) manifest above regardless of platform.
    mode = item.stat().st_mode & 0o7777
    expected = 0o755 if relative in executable else 0o644
    if mode != expected:
        raise ValueError(f"Unexpected task asset mode: {relative}: {oct(mode)}")
files[relative] = TaskFile(item.read_bytes(), relative in executable)

Net effect: integrity_passed becomes meaningful on Windows (currently it's unconditionally False for every bundle there, tamper or not) without weakening anything on POSIX — a real chmod tamper is still caught exactly as today, and the hash's coverage of "was this meant to be executable" is unchanged since it was always config-level information, just now made explicit instead of round-tripped through a lossy read.

Why I'm posting this instead of a PR: this changes what _identity() hashes, so bundle_hash itself changes shape. That breaks claimed_hash verification for every already-published dataset unless it's versioned. My suggestion: treat absence of executable_files in task.toml as a legacy bundle and fall back to exactly today's stat-based check for those — new emissions get the fixed behavior, every existing published dataset keeps verifying exactly as it does now, nothing retroactively breaks. But that's a call on the bundle format everyone downstream consumes, so flagging the shape of it here before writing code, same as I did for this same check back in my first comment on this issue.

Happy to build this (with tests covering both the legacy fallback and the new path, on both platforms) if the direction looks right to you.