WinYOLO

Run Codex safely on native Windows with isolated workspaces, reviewable diffs, checkpoints, rollback, and audit receipts.

Comment

Inspiration

Windows developers can already use Codex, but high-autonomy work is difficult to inspect and recover from. I wanted the speed of an AI coding agent without losing visibility into what ran, what changed, or how to undo a bad repair.

WinYOLO grew from a simple question: can Codex remain the primary interface while a Windows-native control plane adds clear safety boundaries, receipts, and rollback?

## What it does

WinYOLO is a Windows-native launcher, isolation runner, and localhost companion for the official Codex CLI.

It provides three workflows:

  • Safe: Codex runs with workspace-write access, approval prompts, and command networking denied.
  • Constrained YOLO: approvals are removed while workspace and policy boundaries remain.
  • Isolated: Codex runs under a dedicated Windows account inside a disposable Git clone. Users inspect the resulting diff and choose Accept or Rollback.

The browser companion displays Codex conversations, streaming turns, approvals, checkpoints, commands, and schema-2 audit receipts. It binds only to 127.0.0.1, and Codex remains the authority for conversation history.

WinYOLO also exposes strict Windows developer tools for .NET, MSBuild, NuGet, WinGet, services, registry operations, Event Log, filesystem paths, ACLs, and process inspection.

## How we built it

WinYOLO is written in TypeScript and runs with Bun. PowerShell handles installation and Windows-native setup.

Codex is the main interface and execution engine. WinYOLO launches the official native Codex CLI, uses Codex app-server for conversation history and browser turns, and invokes codex.exe exec for isolated repairs.

GPT-5.6 served as the reasoning model. It planned Windows-native actions, called strict-schema tools, diagnosed authentication and sandbox failures, and produced the isolated one-line repair used in the final BrokenBuild demonstration.

The isolation system combines:

  • A dedicated WinYOLORunner Windows account
  • File-backed runner authentication protected by NTFS ACLs
  • CreateProcessWithLogonW
  • A kill-on-close Windows Job Object
  • A sanitized environment and dedicated CODEX_HOME
  • Self-contained disposable Git clones
  • Source-state checks and Accept/Rollback checkpoints
  • Redacted schema-2 JSONL receipts

The companion is a lightweight HTML, CSS, and JavaScript interface served by a loopback-only Bun server.

## Challenges we ran into

Windows process isolation was the hardest part.

An early isolated run failed because a stale server still had the old Codex argument order in memory. After restarting it, Codex was reached correctly, but the restricted runner lacked renewable authentication and returned HTTP 401.

After adding a dedicated runner credential home, another problem appeared: linked Git worktrees pointed back into the installing user’s protected .git directory. The restricted account correctly could not access that metadata. We replaced linked worktrees with self-contained disposable clones.

Native Codex sandboxing also could not be nested reliably beneath the already restricted Windows logon. The final design treats the dedicated account, NTFS ACLs, Job Object, sanitized environment, disposable clone, and explicit Accept gate as the outer operating-system boundary.

These failures became useful evidence because every unsuccessful checkpoint was rolled back rather than accepted.

## Accomplishments that we're proud of

  • Preserved the official Codex terminal instead of building an inferior replacement
  • Implemented Windows-native restricted-account execution without WSL
  • Added reviewable Git checkpoints with Accept and Rollback
  • Protected runner authentication without displaying credentials
  • Added strict-schema Windows development and administration tools
  • Produced redacted, correlated schema-2 audit receipts
  • Kept the browser companion private on localhost
  • Completed 66 deterministic tests with zero failures
  • Passed SOURCE_SCAN_OK and WINYOLO_WINDOWS_SMOKE_OK
  • Demonstrated a deliberately wrong repair being rolled back
  • Accepted the correct one-file repair and produced BROKEN_BUILD_TESTS_PASS

## What we learned

Approval policy and resource authority are different things. Removing confirmation prompts does not require removing filesystem, identity, network, or recovery boundaries.

We also learned that alternate Windows identities need deliberately designed authentication, profile, ACL, and Git behavior. Simply launching the same command under another user is not enough.

Most importantly, auditability is most useful when it leads directly to recovery. A receipt explains what happened; a checkpoint lets the user do something about it.

## What's next for WinYOLO

Next steps include a signed installer, expanded Windows compatibility testing, improved checkpoint diff filtering, more structured Windows tools, stronger automated browser acceptance, and easier packaging for teams.

The core direction will remain the same: Codex owns the coding experience, while WinYOLO provides transparent Windows-native boundaries, evidence, and recovery.

Built With

Share this project:

Updates