English · 简体中文 · 日本語 · Español · 한국어

Wanta

An open-source foundation for building desktop AI agents with OpenCode.

Start with a working product—not a chat UI demo. Wanta brings together an Agent runtime, local tools,
permission controls, connected services, artifacts, and a polished cross-platform desktop interface.

Website · OpenConnector ·
Documentation · Development Guide

From a connected-service task to a reusable, interactive artifact in one workspace.

Wanta is built by OOMOL for developers who want to create useful desktop Agents
without rebuilding the product infrastructure around the Agent loop. Fork it, replace the model,
prompt, tools, connectors, interface, and brand, then ship an Agent for your own product or workflow.

You can also use Wanta as it is: run locally with your own OpenAI-compatible model, or sign in to use
OOMOL-hosted models, connectors, OAuth authorization, and team workspaces.

Why We Open-Sourced Wanta

A convincing Agent demo can begin with a model and a chat input. A desktop Agent people can rely on
needs much more: runtime lifecycle management, streaming events, local access controls, secure model
credentials, sessions and projects, tool activity, file artifacts, recovery, packaging, and a UI that
makes autonomous work understandable.

Developers should not have to rebuild all of that before working on the capability that makes their
Agent unique. Wanta opens up the complete desktop foundation so you can:

• use OpenCode as the runtime for Agents beyond software development;
• build domain-specific tools, Skills, prompts, and workflows;
• combine local computer work with authenticated SaaS actions;
• distribute a branded desktop product instead of a developer-only prototype;
• choose how much infrastructure to operate yourself.

What You Can Build

Wanta is a general work Agent today, but the architecture is intended to be adapted. It can become an
operations Agent, research Agent, support Agent, ecommerce Agent, enterprise knowledge Agent, internal
tool, or another vertical desktop product.

See Wanta in Action

Wanta can reason directly, inspect projects and files, run commands and scripts, access the web, and
use authenticated SaaS Actions when a task needs private account data. Tool execution streams into the
conversation so the user can see what the Agent is doing.

High-risk local actions pass through an explicit permission flow. The Agent can also pause for missing
task information using structured question prompts. Build and Plan modes provide separate execution
contracts, and users can select the model, reasoning level, project, and access mode for the task.

Generated files remain attached to the task instead of disappearing into the conversation. Wanta can
open and review code, text, images, PDFs, Word documents, and full interactive spreadsheet workbooks in
the Artifacts panel.

The optional hosted experience adds managed account connections and team workspaces without putting
stored Provider credentials into the Agent. Teams can share connections and Skills, control Provider
access, and manage usage without operating identity, OAuth credential, and governance infrastructure.

Choose Your Path

Wanta separates the open-source desktop foundation from optional hosted services. Pick the path that
matches what you want to operate.

Runtime modes

Local sessions, projects, and model settings remain available after signing out or when an OOMOL
session expires. Wanta does not silently upload local sessions into an OOMOL team workspace.

The current WANTA_ENDPOINT option is a build-time distribution setting, not an end-user runtime
switch. It derives the complete compatible service environment, not only a Connector Base URL. The
application-level Base URL and optional Runtime Token flow for self-hosted OpenConnector is visible as
a coming-soon product surface and is not complete yet.

Build Your Own Agent

Wanta uses OpenCode as a pinned local runtime and customizes it without maintaining an OpenCode source
fork. The desktop main process controls the sidecar over HTTP and SSE; Wanta supplies the Agent
contract, models, permissions, tools, sessions, product UI, and desktop integration.

Agent Engine: OpenCode

The application starts the pinned [email protected] binary as a loopback-only opencode serve
sidecar and drives it through @opencode-ai/[email protected]. The OpenCode packages are MIT-licensed and
acknowledged in THIRD_PARTY_NOTICES.md. Wanta pins the runtime, SDK, and
plugin to the same exact version because their APIs are not treated as stable.

The most important extension points are:

Agent capability is one product contract expressed in three places: enabled tools, permission rules,
and the system prompt. Change them together so runtime behavior, safety, and UI expectations stay
aligned. Read the architecture guide and
code conventions before changing these boundaries.

How It Works

flowchart TB
  User["User request"] --> UI["Wanta desktop experience"]
  UI --> Agent["OpenCode Agent runtime"]
  Agent --> Local["Local files, shell, scripts, and web"]
  Agent --> Link["Connector meta-tools"]
  Link --> Hosted["OOMOL-hosted Connector"]
  Link -.-> SelfHosted["Self-hosted OpenConnector<br/>in-app setup planned"]
  Local --> Result["Task results and artifacts"]
  Hosted --> Result
  SelfHosted -.-> Result
  Result --> UI

Wanta avoids registering hundreds of Provider-specific tools in the model context. Its Connector
integration uses progressive discovery instead:

list connected apps → search for an Action → inspect its schema → call it with validated parameters

This keeps the tool surface small, makes the action contract explicit, and lets authorization failures
return as structured product states instead of free-form model text.

OpenCode, OpenConnector, Wanta, and OOMOL

• OpenCode is the local Agent runtime. Wanta manages its lifecycle and supplies the Agent
  configuration, permissions, prompts, and custom tools.
• OpenConnector is the open-source sibling for building and running Providers in the shared
  connector ecosystem.
• Wanta is the desktop Agent product and the reusable application foundation in this repository.
• OOMOL provides the optional hosted layer for sign-in, models, Connector credentials, OAuth,
  teams, Skills, usage, billing, and distribution.

The Local BYOK core does not require an OOMOL account. Signing in enables the hosted Connector and team
layer; it is not required to inspect, fork, or develop the desktop application.

For the complete process, trust-boundary, IPC, streaming, authentication, and storage design, read the
architecture guide.

Run from Source

Requirements: Node.js 22.22.2 or newer and pnpm through Corepack.

git clone https://github.com/oomol-lab/wanta.git
cd wanta
corepack pnpm install
corepack pnpm run dev

That is the short path for trying the repository. Environment configuration, test commands, runtime
verification, packaging, signing, and release workflows live in the
Development Guide.

Security and Data Boundaries

• OpenCode listens only on loopback and uses a random per-process server password.
• OOMOL session tokens and custom model API keys have separate storage and lifecycles.
• Custom model keys are encrypted with Electron safeStorage and are never returned to the renderer.
• Connector credentials remain in the selected hosted or self-operated Connector environment; the
  Agent receives action results, not stored provider credentials.
• High-risk local operations are connected to Wanta's explicit approval UI.
• Local sessions are not silently uploaded into an OOMOL team workspace.

See SECURITY.md for private vulnerability reporting and the
architecture guide for complete trust boundaries.

Project Map

The stack is Electron 42, Vite 8, React 19, Tailwind CSS 4, OpenCode, TypeScript, Vitest, oxlint, and
oxfmt. Wanta packages for macOS, Windows, and Linux.

Documentation

• Project overview — product scope and ecosystem relationships
• Architecture — processes, Agent runtime, IPC, streaming, auth, and data flow
• Development guide — install, run, test, package, sign, and release
• Code conventions — implementation rules and security boundaries
• Key technical decisions — why the architecture is shaped this way
• Contributing guide — branches, pull requests, verification, and contribution rules
• Security policy — private vulnerability reporting
• Trademark policy and third-party notices

Contributing

Issues and pull requests are welcome. Before making a substantial behavior or UI change, open an issue
so the product direction and scope can be agreed first. Read CONTRIBUTING.md before
opening a pull request; it contains the repository workflow, required verification, and the security
boundaries that contributions must preserve.

By submitting a contribution, you agree that it is provided under the Apache License, Version 2.0,
unless you clearly state otherwise in writing.

License Scope

Unless otherwise noted, source code, scripts, tests, and documentation authored for this repository
are licensed under the Apache License, Version 2.0.

This license does not grant rights to third-party products, services, APIs, trademarks, trade names,
logos, icons, screenshots, or other materials owned by their respective holders. Third-party names and
assets are used only for identification and interoperability; their inclusion does not imply
endorsement, sponsorship, or partnership.