NexusWindows

One engine, three profiles

✨ Why NexusWindows

🚀 Quick start

Windows 10 or 11, x64 or ARM64; nothing else to install (one self-contained native program, no Python, Node.js or .NET runtime needed).

[!TIP] Let your AI install it. NexusSystem detects your AI apps and sets up the right profile:

text

Install Nexus for me by following https://raw.githubusercontent.com/pironjulien/NexusSystem/main/INSTALL-AI.md

Or the NexusSystem app from the Microsoft Store (winget install --id 9NSH2P3QLWT1 --source msstore).

$r = 'https://github.com/pironjulien/NexusWindows/releases/latest/download'Invoke-WebRequest "$r/get.ps1" -OutFile get.ps1Invoke-WebRequest "$r/SHA256SUMS.txt" -OutFile SHA256SUMS.txt(Get-FileHash get.ps1 -Algorithm SHA256).Hash    # must equal the get.ps1 line of SHA256SUMS.txtgh attestation verify get.ps1 --repo pironjulien/NexusWindows --signer-repo pironjulien/NexusSystem   # optional: provenancepowershell -NoProfile -ExecutionPolicy Bypass -File .\get.ps1

⚙️ How it works

flowchart LR    A["Claude / Codex / Antigravity"] -- "stdio (MCP)" --> W["NexusWindows.exe --mcp --agent ..."]    W -- "UI Automation, Win32" --> D["Windows apps (in the background)"]

One repository, one common engine, three profiles:

For current MCP requests, native file dialogs, UTF-8 stdio and blank Chromium pages, use the shared MCP cookbook. How the engine compares with Cua Driver on the same bench is in the 3 November 2026 benchmark.

[!IMPORTANT] Outward actions (send, pay, publish, delete) are held for your explicit yes, and text read on screen is treated as data, never as instructions.

🛠️ Development

./test.ps1    # dotnet test (xUnit) of the engine, launcher and installers; offline, same command as the CI./test.ps1 -Full    # the same, plus the live tests: real Explorer launch, shared foreground token, capture session

Before a stable promotion (see NexusSystem's RELEASING.md), ./test.ps1 -Full must pass on a real interactive Windows session with a GPU, at a moment nobody is using the PC (the live tests take the shared foreground token and open real windows). The hosted CI skips those tests, so a green CI alone is not enough to promote. Releases ship the engine compiled ahead of time (Native AOT, commun/package.ps1): run the suite against that very binary, installed by get.ps1 from a local package in a throwaway profile:

./commun/package.ps1 -Version X.Y.Z -Out <dist> -Runtimes win-x64 -NoMcpb$env:NEXUS_WINDOWS_PROFILE = '<empty folder>'; $env:NEXUS_WINDOWS_SOURCE = '<dist>\NexusWindows-win-x64.zip'powershell -NoProfile -ExecutionPolicy Bypass -File ./get.ps1./test.ps1 -Full -Engine '<empty folder>\.nexus\nexus-windows\native\<sha-256>\NexusWindows.exe'

-Engine runs the process tests (MCP over stdio, helper children) against that executable. The installers accept both engine layouts:

• Native AOT single file (releases since 3.17.0): NexusWindows.exe alone holds the code;
• framework-dependent (the working-folder installation, commun/native-runtime.ps1, and releases up to 3.16.28): NexusWindows.exe with NexusWindows.dll, .deps.json and .runtimeconfig.json, all three recorded together; a partial set is refused.

These cases live in LauncherTests, NativeRuntimeInstallerTests and PublicMaintenanceTests (get.ps1, commun/native-runtime.ps1, the stable launcher); NexusSystem's WindowsRuntime/RuntimeObservation follow the same rule since NexusSystem 1.7.0.

Build and test outputs go to %USERPROFILE%\.nexus\build\nexuswindows. The three profiles were separate repositories until 30 October 2026; those repositories have since been removed (see CHANGELOG.md).

🔐 Privacy & security

Everything runs on your PC. Nothing is sent anywhere by NexusWindows; screenshots, logs and routines stay under %USERPROFILE%\.nexus. See SECURITY.md to report a vulnerability.

MIT © Julien Piron