OpenRoom: A Browser Desktop Where an AI Agent Drives the Apps
A browser-based desktop where AI Agent operates every app through natural language.
At a glance
- What is it?
- OpenRoom (VibeApps) is an MIT-licensed TypeScript project that puts a windowed desktop in the browser and lets an LLM call structured actions inside each app. It is a good fit for people building agent-operable front ends, and a poor fit for anyone who wants a hosted product rather than a local dev setup.
- Who is it for?
- Adopt OpenRoom if you want a local, no-backend desktop shell whose apps expose a typed Action contract an LLM can call, and you are willing to run Claude Code CLI for app generation and supply your own LLM API key for the chat panel. Do not adopt it if you need a hosted multi-user product, a stable released artifact, or a production iframe sandbox, since the repository ships no releases and replaces the real vibe-container SDK with a local mock.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 104 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem OpenRoom Picks: Agents That Can Talk but Not Click
Most agent demos stop at conversation. The agent can describe a playlist, draft an email, or explain a chess opening, but it cannot press the button. OpenRoom targets that gap directly. It ships a browser-based desktop with draggable, resizable windows and a set of built-in apps, then gives the AI Agent a structured Action system each app speaks. The README's framing is explicit: the Agent does not just launch apps, it operates them, reading data, triggering actions, and updating state.
The intended audience is narrow and identifiable. It is front-end engineers who want a working reference for agent-operable UI, and developers experimenting with what the repository calls vibe coding. The built-in apps (Music, Chess, Gomoku, FreeCell, Email, Diary, Twitter, Album, CyberNews) exist as demonstrations of the pattern rather than as products. Nothing here runs on a server. Data lives in IndexedDB, and the README states there is no backend and no accounts.
How the Action Contract Ties the Agent to Each App
The mechanism is a per-app actions directory. Looking at the documented app anatomy, every app has an actions/ folder containing constants.ts, which defines the APP_ID plus the action type definitions for that app. The Agent resolves a natural-language request to an app, picks an action from that app's declared set, and dispatches it. State lives in each app's store/, described as Context plus Reducer, so an action mutates app state through the same path a user click would.
That is the whole architecture in miniature, and it is the part worth copying. The Agent is not given a screenshot and asked to guess coordinates. It is given a vocabulary. The trade-off is that an app is only as agent-operable as its constants.ts is complete. If a capability is not expressed as an action, the Agent cannot reach it, no matter how well the LLM understands the request.
The shell itself lives in apps/webuiapps/src, split into components/ (shell, window manager, chat panel), lib/ (the core SDK covering the file API, actions, and app registry), pages/, and routers/. The iframe boundary is handled by packages/vibe-container, which the README describes as a stub in open-source mode. In the standalone version, the real SDK is replaced by src/lib/vibeContainerMock.ts, which uses IndexedDB for storage and a local event bus for Agent communication. The package still ships type definitions and the client-side SDK interface.
Running It Locally: Node 18, pnpm 9, and an API Key You Supply
The prerequisites are Node.js 18 or later and pnpm 9 or later. The README gives the install path for pnpm as npm install -g pnpm@9. From a clone, the sequence is pnpm install, an optional cp apps/webuiapps/.env.example apps/webuiapps/.env, then pnpm dev. The dev server answers on http://localhost:3000, where double-clicking an icon opens an app. There is a note that users in China can uncomment mirror lines in .npmrc.
The chat panel is the in-browser entry point. Clicking the chat icon in the bottom-right corner opens it, and the README notes you will need an LLM API key configured in the Chat Panel settings. It does not name a provider or a key format, so that is something to confirm against the .env.example file before assuming your provider works.
The second surface is separate and easy to confuse with the first. The Vibe Workflow does not run in the browser chat panel. It runs in Claude Code CLI, from the .claude/ directory, with commands/vibe.md as the entry point and workflow/ and rules/ holding stage definitions and code generation constraints. Creating apps and operating apps are two different tools in two different places.
The Vibe Workflow: Six Stages to Generate, Four to Change
App generation is driven by a slash command. The README's example is /vibe WeatherApp Create a weather dashboard with 5-day forecasts and temperature charts. The workflow then runs through six named stages: Requirement Analysis, Architecture Design, Task Planning, Code Generation, Asset Generation, and Project Integration. The last stage is what registers the app so it appears on the desktop, which is why the generated app arrives with Agent integration rather than as an orphaned component tree.
Modifying an existing app uses a shorter path. /vibe MusicApp Add a lyrics panel that shows synced lyrics during playback triggers a four-stage change workflow: Impact Analysis, Planning, Implementation, Verification. There are also resume and replay options. Running /vibe MyApp picks up where you left off, and /vibe MyApp --from=04-codegen jumps to a specific stage. That stage-jumping is the most practically interesting part of the design, because code generation is the expensive step and re-running requirement analysis to fix a styling bug is wasted effort.
The generated output follows the same app anatomy as the built-ins: components/, data/ for seed JSON, store/, actions/, i18n/ with en.ts and zh.ts, meta/ with meta_cn and meta_en subfolders each holding guide.md and meta.yaml, plus index.tsx, types.ts, and index.module.scss. The meta files are what the workflow reads to understand an app, so a generated app that skips them will be harder to evolve later.
Where OpenRoom Is the Wrong Tool
The mock is the first real limitation. In open-source standalone mode, packages/vibe-container/ is not the production iframe SDK. It is type definitions and a client interface sitting in front of src/lib/vibeContainerMock.ts, which stores to IndexedDB and communicates over a local event bus. If your goal is to evaluate how OpenRoom isolates untrusted app code in a real deployment, this repository does not show you that. It shows you the shape of the interface the real implementation satisfies.
Persistence is the second. IndexedDB is per-browser and local. There is no backend and no accounts, which the README presents as a feature, and for a demo it is. For anything involving multiple users, shared state, or data that must survive a browser profile reset, it is a dead end by construction.
The third is the split toolchain. A developer who wants to both operate and create apps has to run a browser dev server and Claude Code CLI, and the app-creation path depends on Claude Code specifically. Nothing in the README suggests an alternative driver for the Vibe Workflow.
Finally, there are no retrieved releases. The repository is not archived and the last push is dated 2026-06-03, but anyone expecting a tagged version to pin against will not find one in the supplied material.
How This Differs from a General Browser Automation Stack
The obvious alternative is driving a real browser with an automation framework such as Playwright, where the agent perceives rendered pages and manipulates DOM elements or coordinates. That approach works against any site without cooperation from the site's authors. OpenRoom makes the opposite bet. It requires every app to declare its actions in constants.ts and route them through a store, and in exchange the Agent gets a typed, deterministic interface instead of a pixel target that shifts when a layout changes.
The practical difference shows up in failure modes. A Playwright-style agent fails when a selector changes or an element is occluded. An OpenRoom agent fails when the requested capability was never declared as an action. The first failure is brittle and environmental; the second is a design gap you can close by editing one file. It also means OpenRoom cannot operate arbitrary third-party sites at all. It operates its own desktop, and the nine built-in apps are the demonstration of that boundary.
A second comparison point is the micro-frontend pattern the repository lists as a topic. OpenRoom's pages/ and routers/ structure, plus the iframe SDK boundary, resembles module federation or a runtime app registry. The difference is that OpenRoom's registry entries carry an action vocabulary for an LLM, not just a mount point.
Maintenance Burden and What the MIT Licence Leaves Open
The upgrade surface is mostly ordinary. pnpm install, pnpm dev, and a lockfile govern the JS side. The .claude/ directory is the unusual part: commands/vibe.md, workflow/, and rules/ are content that shapes generated code, so changes there affect output quality without touching application source. A team adopting OpenRoom should treat .claude/rules/ as reviewed configuration rather than as documentation.
The dependency on Claude Code CLI for app generation is a maintenance consideration in itself. The chat panel needs an LLM API key, and the README does not enumerate supported providers, so key handling and provider compatibility are things to verify in the code rather than assume.
The licence is MIT, which permits commercial use and modification, and the repository carries an MIT badge in the README. That is the extent of what the supplied material supports. It says nothing about the licences of the bundled seed data, the app icons, or any assets the Vibe Workflow's Asset Generation stage produces, and those are separate questions a legal reviewer would need to answer from the repository contents. Nothing here should be read as legal advice.
Editorial conclusion
Adopt OpenRoom if you want a local, no-backend desktop shell whose apps expose a typed Action contract an LLM can call, and you are willing to run Claude Code CLI for app generation and supply your own LLM API key for the chat panel. Do not adopt it if you need a hosted multi-user product, a stable released artifact, or a production iframe sandbox, since the repository ships no releases and replaces the real vibe-container SDK with a local mock. Before committing, read packages/vibe-container/README.md, confirm the .env.example keys match your LLM provider, and check whether the mock's IndexedDB storage and local event bus meet your persistence needs.
Community notes