feat(ego-windows-host): run the ego-browser runtime on stock Edge/Chrome (Windows preview) - #228
feat(ego-windows-host): run the ego-browser runtime on stock Edge/Chrome (Windows preview)#228Hotragn wants to merge 2 commits into
Conversation
…ome (Windows preview)
…nches, add per-space windows
|
Pushed three hardening changes found by actually living on this host for a couple of weeks. All are additive; nothing in the original review scope changed. 1. Launch at a desktop window size ( 2. Diagnose a launch that never comes up. The bare 3. Opt-in per-space windows ( Verification on Windows 11 / Node 24: That |
|
Flagging a change in premise rather than leaving this sitting in the queue. On #203, @nukochow says a Windows version of ego lite is launching soon. I cannot verify that as official — the account has no commits or PRs here, and the association is So: say the word and I will close this. No explanation needed, and no hard feelings — a stopgap that arrives after the real thing is just review burden. I would rather retire it myself than have it linger. If it is still useful in the meantime, it is current: rebased, 60/60 tests, and re-verified live against Edge 151 ( Two things from this work that stay useful either way, independent of whether a host ships:
Whichever way you go on the package itself, #312 is the one I would actually prioritise ahead of a Windows launch — that one blocks Windows contributors on the active branch today. |
Summary
Windows users cannot run ego-browser at all while native Windows support (#203) is under evaluation. This PR adds
package/ego-windows-host, a preview host that implements theglobalThis.egocontract against stock Microsoft Edge or Chrome over loopback CDP and delegates execution to the unmodifiedego-browserruntime. Everything the runtime offers — task spaces,page/locators, snapshots, screenshots, control handoff — works on Windows today, and scripts stay byte-identical when the native app ships. Additive only: no existing file is touched except one new, path-scoped workflow.Related issue
Closes #227 (proposal). Addresses the Windows-user half of #203 as a stopgap. Follows the host-contract prior art of #134/#202 (credit to @iagogfe and @olenanikita1980-cell); deliberately a sibling package rather than an extension of #202, whose daemon/Unix-socket design doesn't map to Windows and whose review shouldn't be bloated from the side.
Changes
package/ego-windows-host/src/ego-bridge.ts— theegocontract: verbatim CDP passthrough (sendCDPMessage/onCDPMessage/onSendCDPMessageError),listTabs/createTabscoped to the selected task space, the full task-space method set resolving the documented{ error, error_code }shapes,snapshot()(rejects withEGO_TASK_SPACE_USER_IN_CONTROLduring handoff — the contractprobeAgentControl/waitForAgentControlrely on), andgetBrowserVersion()reporting no update so the notice stays silent. RawTarget.createTarget/activateTarget/closeTargetthrough the passthrough are sniffed so tab bookkeeping stays consistent however the runtime opens tabs.src/task-spaces.ts— spaces as persisted tab sets with ownership (agent/agentDelegatedToUser/user), atomic JSON state under%LOCALAPPDATA%\ego-windows-host. No daemon: the detached browser is the persistent process.src/ax-snapshot.ts—{ content, refs }fromAccessibility.getFullAXTree, with[@backendNodeId]marks that resolve through the runtime's existingbrowserSnapshotRefsToRefMap/parseRefpath. Honestly weaker than the app's kernel-level snapshot; documented as such.src/browser-locator.ts,src/chrome-launcher.ts— Edge-first detection across standard Windows install roots (EGO_HOST_BROWSER_PATHoverride), reuse-or-launch against a fixed loopback CDP port with a dedicated profile; never touches the user's daily browser profile.src/cdp-connection.ts— minimal CDP client over Node ≥ 22's global WebSocket (zero new runtime dependencies, matching the repo's no-Puppeteer/Playwright rule). Two connections per run: host-internal and agent passthrough, so flattened sessions never mix.src/cli.ts,bin/ego-windows-host.mjs— script file /-e/ stdin input (PowerShell has no heredocs; same rationale as [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), a leadingnodejsaccepted for compatibility,--doctorstate report..github/workflows/windows-host.yml— path-scoped test job on windows-latest + ubuntu-latest (npm ci --ignore-scriptsuntil fix(ego-browser): make the repo build, test, and commit on Windows #148 makes the sibling prepare script Windows-safe). A new file so it cannot conflict with feat(ego-linux-host): add persistent Linux browser host #202's CI edits.Verification
Unit/typecheck, run from
package/ego-windows-host(Windows 11, Node 24):Real end-to-end against stock Edge 151 headless on Windows 11 (transcript):
The handoff transcript is worth a look: the bridge only supplies the stable
error_code, and the runtime's own output sink produces the identical hard-stop collapse it produces against the real app — which is the point of implementing the contract instead of forking the runtime.Impact
Nothing existing changes: no
package/ego-browserfile is modified, no skill text changes, and the new workflow is path-scoped to the new package. The host is opt-in (its own bin, never on PATH unless installed). Known limitations are stated in the package README: plainer snapshot than the app, dedicated profile rather than Chrome import, no Spaces UI, loopback CDP port exposure. If the team prefers a different direction (e.g. converging with #202 into one cross-platform host, or waiting for the native app), closing this costs nothing — the contract knowledge is in #227 either way.Checklist
devfor normal changes; onlydevmay targetmain).feat).