[Bug]: native Windows: the recommended --write-worktree code-edit lease always fails - no Windows host-identity source in verified machine discovery #6640

Preflight

• I searched existing issues and discussions for this behavior.

• This report is not an unpatched security vulnerability.

• The report and attachments contain no credentials or private/internal material.

• Issue origin: Observed or reproduced in a real environment (native Windows 11, PowerShell)

• LoopX version or commit: dda6f7ef7 (current main); the released 1.4.2 wheel ships the same module and fails identically

• Host or runtime surface: native Windows 11 host running the repository CLI (loopx task-lease acquire) and the public smoke examples/control_plane/task-lease-runtime-smoke.py

• LoopX area: Control plane (goals, todos, quota, scheduler, registry, runtime)

Problem

Verified worktree lease observation has no machine-identity source on Windows, so the documented and product-recommended independent-worktree code-edit lease can never be acquired there.

observeLeaseWorktree (loopx/control_plane/work_items/task_lease_workspace.ts:135-138) derives the host identity from ioreg's IOPlatformUUID on macOS and /etc/machine-id on Linux, leaves machine as null on every other platform, and then fails closed:

const machine = platform() === "darwin"
  ? /"IOPlatformUUID"\s*=\s*"([^"]+)"/u.exec((await run("ioreg", ["-rd1", "-c", "IOPlatformExpertDevice"], {timeout: 5000})).stdout)?.[1]
  : platform() === "linux" ? (await readFile("/etc/machine-id", "utf8")).trim() : null;
if (!machine) throw new LeaseWorktreeObservationError("host identity unavailable for worktree isolation");

On native Windows, every loopx task-lease acquire --write-worktree <path> therefore rejects with error_code: invalid_worktree_lease_request at the durable_writeback settlement step, and no worktree lease (and no subsequent renew/replay flow) exists.

The flag is not exotic or optional paperwork:

• The CLI's own conflict advisory tells a blocked caller to use it: task-lease acquire's write_scope_conflict response carries recommended_action "For isolated code edits, use your own separate Git worktree and acquire with --write-worktree..." (loopx/control_plane/coordination/task_lease_acquire.ts:86-87). On Windows this recommendation always dead-ends.
• The flag help describes the capability with no platform caveat (loopx/cli_commands/task_lease.py:128).
• The code-edit worktree instructions in docs/reference/local-delegation.md:771 (English) and :787 (Chinese) tell the caller to run exactly this command.
• The only platform sentence, docs/reference/canonical-lease-renew.md:97-98, says "Verified machine discovery currently supports macOS and Linux; other hosts retain ordinary leases." A Windows caller who passes the flag does not retain an ordinary lease: the acquire fails outright, and the returned message does not name the platform limitation or the supported set.

Two further impact paths:

• The public smoke that guards this contract, examples/control_plane/task-lease-runtime-smoke.py, is a default-tier canary check for the state-write-correctness surface (loopx/canary/planner.py:641, trigger hints include lease), so on Windows the AGENTS.md-mandated loopx canary premerge --from-git-diff can go red on unrelated lease-surface changes.
• The gap is invisible to CI: the two real-observation tests in tests/control_plane_ts/task_lease_workspace.test.ts are skipped on non-darwin/linux (:16-18, :61-63), the Python twin carries skipif(sys.platform not in {"darwin", "linux"}) (tests/test_task_lease_worktree.py:13), and the windows-powershell lane runs neither this suite nor this smoke. The TypeScript file is green on Windows today (# pass 5 / # fail 0 / # skipped 3), which is why the defect survived.

Who is affected: contributors and agents on native Windows — a platform the project actively supports (dedicated windows-powershell CI lane, Windows install and junction tests, and many merged native Windows fixes) — including the released wheel's users.

Minimal reproduction

git clone https://github.com/loopx-project/loopx
cd loopx
uv sync --extra test
uv run --extra test python examples/control_plane/task-lease-runtime-smoke.py

The smoke aborts at its first worktree acquire (examples/control_plane/task-lease-runtime-smoke.py:136, --write-worktree <worker>). The standalone documented command fails the same way:

loopx --registry registry.json task-lease acquire `
  --goal-id example-goal --todo-id todo_work --owner agent-a `
  --idempotency-key worktree-edit-a --ttl-seconds 600 `
  --write-scope 'src/**' --write-worktree "$PWD"

Actual behavior

rc=1
{
  "ok": false,
  "schema_version": "task_lease_v0",
  "action": "acquire",
  "error": "host identity unavailable for worktree isolation",
  "error_code": "invalid_worktree_lease_request",
  "lease_path": "<runtime>/goals/task-lease-runtime-goal/task-leases/todo_taskleasea.json",
  "settlement": {
    "failure": {"step": "durable_writeback", "kind": "writeback_rejected", "code": "invalid_worktree_lease_request"}
  }
}

The same payload is produced by the installed 1.4.2 wheel (its loopx/control_plane/work_items/task_lease_workspace.ts contains the identical platform expression), driven against the same fixture.

Expected behavior

Verified machine discovery should have a Windows identity source so the documented capability works on a supported platform. The natural analog of /etc/machine-id is the registry value HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid (the OS installation identity), readable on this host:

$ reg query "HKLM\SOFTWARE\Microsoft\Cryptography" /v MachineGuid
    MachineGuid    REG_SZ    <redacted>

Recommended shape, if Windows support is in scope:

1. read that value on win32 with the same subprocess pattern as ioreg, and keep the existing fail-closed error when the identity cannot be read;
2. narrow the platform skips to the platforms whose identity source is implemented (the symlink-based link test needs a separate decision because Windows needs Developer Mode/administrator rights);
3. run the suite (or at least this file) on the windows-powershell lane so the identity source cannot silently regress; the lane already runs one control-plane TS file (tests/control_plane_ts/test_python_runtime.test.ts).

If the platform gap is intentional for now, then the CLI advisory, the flag help and the code-edit worktree instructions should stop recommending --write-worktree on Windows, and the failed acquire should say the host identity source is unsupported on this platform rather than only that it is unavailable.

Sanitized diagnostics

$ node --version
v26.11.1

$ uv run --extra test python examples/control_plane/task-lease-runtime-smoke.py
rc=1 (payload above; the smoke exits in its worktree acquire step)

$ node --no-warnings --experimental-sqlite --experimental-strip-types --test tests/control_plane_ts/task_lease_workspace.test.ts
# tests 8
# pass 5
# fail 0
# skipped 3

$ reg query "HKLM\SOFTWARE\Microsoft\Cryptography" /v MachineGuid
    MachineGuid    REG_SZ    <redacted>

Additional context

• The repository-identity codec in the same function was normalized recently (fix(leases): normalize observed worktree repository identities #5584); machine identity was not touched by that change. The advisory workflow itself landed with fix(coordination): allow isolated worktree edits with integration advisories #5364/fix(workspace): isolate edits and preserve complete current evidence #5587.
• [Bug]: native Windows: 34 control-plane TypeScript tests fail on POSIX-only path handling #6170 and [Bug]: native Windows: remaining 32 host-dependent control-plane TypeScript test failures after #6207 #6351 track the control-plane TypeScript suite's host-dependent failures; this path is not among them because its tests skip on Windows.
• This report was prepared with AI assistance and the reproduction was executed on the reporter's Windows host.