[Feature]: Add Windows support for ego lite

[pcwmax-poyu]

Component

ego lite browser app

Problem to solve

I use Windows 11 as my primary development environment and use Codex for AI-assisted development and automation.

ego lite and the ego-browser skill appear especially useful for reducing browser-automation tool calls, reusing authenticated browser sessions, and allowing agents to work in isolated Spaces. However, the browser currently supports only macOS, so Windows users cannot run the ego-browser runtime even if the skill is installed.

This prevents Windows-based Codex, Claude Code, and other agent users from evaluating or adopting ego lite.

Proposed solution

Please provide a Windows version of ego lite.

The smallest useful first release could be:

Windows 11 x64 support
A standard installer or portable preview build
The ego-browser command available on PATH
Compatibility with Codex and Claude Code
Basic Task Space and Snapshot functionality

Automatic Chrome profile migration and automatic skill installation could be added later if they would delay an initial Windows preview.

A public Windows beta, waitlist, or approximate roadmap would also be helpful.

Alternatives considered

I currently have to use alternatives such as Playwright, Chrome-based agent control, or other browser automation tools.

These approaches can perform browser operations, but they do not provide the same combination of isolated agent Spaces, integrated browser runtime, reusable login state, and compressed semantic Snapshots described by ego lite.

Running ego lite through macOS is not practical because my main development and automation environment is Windows.

Examples or references

My intended use cases include:

Codex browser automation
Research across authenticated websites
Collecting structured information from dynamic pages
Long-running browser tasks without interfering with my own tabs
Reducing repeated screenshots, full-page HTML transfers, and tool-call overhead

I would be willing to test an early Windows 11 x64 build and provide installation and compatibility feedback.

Before submitting

• I searched existing issues and discussions for a similar request.
• This request describes one focused problem.

[wuning159]

I just opened it and let my GPT-5.6 take a look at this project, and the conclusion was that it doesn't support Windows. Then I thought about raising an issue, and after that, I saw that you already did. Pretty nice.

[yarin-zhang]

Sorry, Close was an incorrect operation.

We are actively evaluating support for the Windows version.

[Cohawv]

how long support for the Windows version

[humbertcleopatr-hash]

I thought about raising an issue about windows support , I saw that you already did. Pretty nice.

[Hotragn]

Since the team is evaluating a Windows version: the app binary is the closed-source half, but a Windows build can only be as usable as the open runtime + skill it dispatches to, and that repo-side surface has concrete, separable gaps. Mapping what exists so the pieces are visible in one place:

• Toolchain — fix(ego-browser): make the repo build, test, and commit on Windows #148 makes the repo build, test, and commit on Windows. I verified it independently on a second Windows 11 machine (details on the PR): stock npm ci through npm test (309 pass) with no workarounds, where current dev fails at step 1 of CONTRIBUTING §4.
• Invocation — every documented way to drive the CLI is a POSIX heredoc, which PowerShell/cmd cannot express, and piping through Windows PowerShell 5.1 mangles non-ASCII scripts ($OutputEncoding defaults to ASCII). [Feature]: Accept a script file or inline -e code as CLI input (heredoc-free invocation for Windows shells) #225 / feat(ego-browser): align runtime CLI input with the nodejs dispatcher and add a script-file form #226 add the Node-conventional ego-browser <script.js> and -e <code> forms through the same execution path, so agent CLIs on Windows have a lossless input channel the day a Windows build exists.
• Path correctness inside the runtime — fix(ego-browser): name downloads by guid and confine the reported path #224 switches download.path() to guid naming (Playwright's scheme); the sharpest failure case of the current suggestedFilename-derived path is Windows filename sanitization (:?"<>|*, reserved device names, trailing dots), where the reported path can name a file the browser never wrote. fix(ego-browser): probe the installed skill location for the agent workspace #223 makes the agent-workspace fallback resolve the installed skill location instead of a nonexistent root-relative path ([Bug]: Site learnings unreachable — agent workspace falls back to /skills/ego-browser (filesystem root) in the bundled CLI #215) — the same resolution a Windows bundle layout will need, anchored on HOME/USERPROFILE.
• Host prior art — feat(ego-linux-host): add persistent Linux browser host #202 already demonstrates the globalThis.ego contract running against stock Chromium on Linux. If the team wants a stopgap for Windows users before a native build (stock Chrome/Edge is on effectively every Windows machine, and CDP transport is identical), extending that host contract is likely a smaller step than the native app — but that's a product call, and feat(ego-linux-host): add persistent Linux browser host #202's review seems like the right place for it to start.

Happy to test early Windows builds — Windows 11 Home, Node 24, both Claude Code and Codex CLIs on PowerShell — and to keep knocking out repo-side pieces if the team flags what would help most.