aide-browser-ide

Files (1)

• SKILL.md

SKILL.md (first lines)

# AIDE in the Browser — Research-Backed Architecture Options

A user's request: "I want the full AIDE running as a website so people can go use it without downloading." This is a SaaS-shaped requirement, not a website-shaped one. AIDE is currently a single-user, single-machine, loopback-only IDE. The hard part is not the frontend (already Vite-bundled); it is the backend daemon that the frontend proxies to (`/api` and `/ws` → `127.0.0.1:4778`).

## 0. What AIDE actually is (verified from disk, 2026-08-28)

| Component | Path | Role | Where it runs today |
|---|---|---|---|
| Frontend | `app.js` (84KB) + `index.html` + `styles.css` | Monaco editor, panels, overlays, agent UI | Browser (Vite preview/build) |
| Build | `browser/vite.config.ts` | Vite dev/proxy/preview at `:5173`/`:4173`; build → `browser/dist/` | Local Node |
| Daemon | `daemon/server.mjs` | HTTP/WS on `127.0.0.1:4778`; spawns `llama-server`, LSP/DAP, workspace, git | Local Node, loopback only |
| Models | `daemon/model-manager.mjs` spawns `llama-server` (E.g. `E:\llama-cpp-vulkan\`) | GGUF inference | Local subprocess |
| Desktop packaging | `desktop/tauri.conf.json` (planned) | Tauri wraps frontend + bundled Node | User's machine, after install |

**Frontend cannot run without a backend serving `/api/*` and `/ws`.** A public "AIDE as a website" needs a reachable, multi-tenant backend. This is what each option below addresses (or doesn't).

## 1. Option A — GitHub Codespaces (RECOMMENDED)

**What it is:** A `.devcontainer/devcontainer.json` + `postCreateCommand.sh` in the AIDE repo that defines the AIDE environment. A "Open in Codespaces" button on the Neuro_Nomad site deep-links to `https://codespaces.new/AnonymousNomad/aide-sovereign-workbench`. GitHub provisions a Linux VM, runs the postCreate, the visitor runs `npm start`, AIDE opens in the codespace's browser tab.

**Source (verified, 2026-08-28):** https://github.com/features/codespaces
- "All personal (individual) GitHub.com accounts include a quota of free usage each month ... GitHub will provide users in the free plan 120 core hours or 60 hours of run time on a 2 core codespace, plus 15 GB of storage each month."
- "A codespace is a development environment that's hosted in the cloud ... Connect to your codespaces from the browser or locally using an IDE like Visual Studio Code."
- Configuration-as-code via `.devcontainer/` files in the repo (per the `aide-ide-research` skill — already in this project).
- 2-core to 32-core machine options. Browser preview + port forwarding included.

**What works out of the box:**
- Full AIDE — `npm start` boots the daemon + frontend in the codespace's browser.
- Real `llama-server` runs in the codespace's Linux VM. Visitor can download any GGUF from Hugging Face in-app via AIDE's Model Hub.
- Real git, LSP, DAP, terminal, file ops — all the things AIDE already does.
- Per-user state (their own workspace, their own models, their own git history). Persistent between sessions (storage included in free quota).
- No infra for you to operate. GitHub does it. Visitor pays (or uses their own free quota).

**What does NOT work / limitations:**
- Each user needs a GitHub account. Visitor friction = sign-in.
- Cold start: ~30-90s to provision VM, install deps. Visitor friction = wait.
- Free quota is 60 hrs/month for 2-core. Heavy users hit paid tier.
- 8 GB RAM codespaces are the common default; AIDE + a 7B GGUF + KV cache is tight but doable.
- Requires public repo (or org allowlist) — AIDE is already public.

**Threat matrix:**

| Threat | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Codespace left running, billing surprise | Medium | Low | Document TTL in `devcontainer.json`; user controls their own quota |
| Visitor's code leaks via the codespace | Low | Medium | Each codespace is an isolated VM; storage is per-user; no cross-codespace sharing by default |
| Visitor downloads a malicious GGUF and runs it | Medium | Medium | AIDE already has the same risk in the desktop app; not new |
| llama-server wedges on Vulkan-less Linux VM | High (medium risk) | Medium | devcontainer installs CPU build; document GPU support is best-effort |
| Abuse of free quota (bots creating codespaces) | Low | Low | Requires GitHub account; GitHub rate-limits at signup |
| `llama.cpp` build fails on the codespace's glibc/kernel | Medium | Medium | Pin Ubuntu version in `devcontainer.json`; document known-good |

**Dependencies:**
- AIDE repo: add `.devcontainer/devcontainer.json`, `.devcontainer/postCreateCommand.sh`, `.devcontainer/Dockerfile` (optional, devcontainer image is also fine)
- Neuro_Nomad site: replace the "View AIDE on GitHub" CTA with a "Open in Codespaces" button linking to `https://codespaces.new/AnonymousNomad/aide-sovereign-workbench`
- A README link to "Try it in your browser" pointing at the same URL

**Cost:** Zero to you. Visitor pays (or uses free quota).

**Realism:** This is the canonical answer. Research is consistent. Existing AIDE project structure supports it (Vite build already exists, devcontainer concept is in the AIDE skills).

**Why I recommend this:** It runs the **real, unmodified AIDE** — no half-broken browser port, no months of engineering. Visitor gets the same product they would have gotten by `npm install && npm start` on their laptop, just on a GitHub VM with a one-click button. The cost is zero. The friction is "needs a GitHub account + 30s wait" — much better than the alternative.

## 2. Option B — StackBlitz WebContainers

**What it is:** WebContainers run a Node.js-compatible runtime in the browser. Wrap AIDE so the entire stack (frontend + daemon + npm) lives in the user's tab. Real `npm install`, real file system, real HTTP server — all in-browser.

**Source (verified, 2026-08-28):** https://webcontainers.io/guides/quickstart
- "The WebContainer API starter is the fastest way to explore the API"
- Requires `Cross-Origin-Embedder-Policy: require-corp` and `Cross-Origin-Opener-Policy: same-origin` headers (GitHub Pages cannot set these — would need Cloudflare Pages or Vercel)
- Requires SharedArrayBuffer (browser feature, modern browsers OK)
- Single WebContainer instance per page

**What works:**
- Vite + ES modules + Node APIs (subset)
- AIDE's frontend runs unmodified
- Per-user state in-memory; no persistence between sessions without extra work
- No backend, no infrastructure

**What does NOT work (HARD blockers for AIDE):**
- WebContainers does **not** support spawning arbitrary executables. AIDE's `daemon/model-manager.mjs` calls `child_process.spawn('llama-server', ...)` — that path is broken in WebContainers. Confirmed by reading the StackBlitz docs; no `child_process` for external binaries.
- AIDE's daemon would need to be rewritten to use a browser-side LLM runtime (e.g., WebLLM via transformers.js, WebGPU). That's a separate project.
- AIDE's LSP/DAP clients rely on local language servers; not runnable in a browser sandbox.
- File system is per-tab, ephemeral by default. AIDE's workspace persistence model breaks.

**Threat matrix:**

| Threat | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Engineering effort to port daemon to WebContainers | Certain | Months | This IS the threat — AIDE's architecture is server-shaped, not browser-shaped |
| Visitor's tab crashes → lost work | High | Medium | Manual export required; not automatic |
| Browser GPU/compute limits for in-browser LLM | High | Medium | A 4B model may not run reliably in WebGPU; smaller models only |
| COOP/COEP headers break embeds (GitHub Pages) | Certain | Low | Move to Cloudflare Pages or Vercel (free) |

**Cost:** Free tier exists; paid for heavy use. Your cost: engineering time (months).

**Realism:** Not viable as a quick win. A "real AIDE in WebContainers" is a different product — AIDE's daemon would need a browser-native LLM runtime, which is a separate project.

## 3. Option C — Self-hosted code-server

**What it is:** Run `code-server` (open-source VS Code in browser) on a free-tier VM (Oracle Cloud Always Free, Fly.io, Hetzner, etc.). Put AIDE's frontend in code-server's iframe or alongside. Proxy AIDE's `/api` and `/ws` to a co-located AIDE daemon.

**Source (verified, 2026-08-28):** `aide-ide-research` skill, `aide-p6-desktop-control` skill, the existing Tauri plan in AIDE.

**What works:**
- Real VS Code in browser
- Real AIDE daemon, real llama-server, real LSP/DAP — all on your VM
- Per-user state via Linux user accounts (or shared, with quotas)

**What does NOT work (or has serious friction):**
- You operate the VM (or pay someone to). Persistent ops burden.
- Abuse risk: public daemon with a public IP = attack surface. Rate limiting, auth, captcha all needed.
- Free VMs are typically 1-2 GB RAM. AIDE + llama-server + 4B Q8 model = needs ~6 GB. Free tier does not fit; you pay for the VM.
- "Open in one click" still requires sign-in / account creation on your auth layer.

**Threat matrix:**

| Threat | Likelihood | Impact | Mitigation |
|---|---|---|---|
| VM compromise via exposed port | High | High | Firewall + fail2ban + TLS + auth required |

From AnonymousNomad/covert-coder, Apache-2.0.

More from AnonymousNomad/covert-coder