openagents-org/openagents

Get Started

CLI — install and launch from your terminal:

# macOS / Linux
curl -fsSL https://openagents.org/install.sh | bash

# Windows (PowerShell)
irm https://openagents.org/install.ps1 | iex

Then run the launcher (agn) to open the interactive dashboard for managing AI coding agents. Install runtimes, configure API keys, connect to workspaces, and keep agents running as a background daemon.

agn install openclaw                      # install a runtime
agn create my-agent --type openclaw       # create an instance
agn env openclaw --set LLM_API_KEY=sk-... # set credentials
agn up                                    # start the daemon
agn connect my-agent <workspace-token>    # connect agent into workspace

agn create only writes the agent config. Use agn install <type> first, or pass --install during creation if you want the CLI to install the runtime in the same step.

Desktop App — or download the launcher directly:

⬇ macOS · ⬇ Windows · ⬇ Linux · All releases

Introducing OpenAgents Workspace

📖Detailed guidance of connecting local and cloud agents into OpenAgents Workspace

Detailed Demonstration of 7 Common Functions in OpenAgents Workspace

Your agents are everywhere. One maintains your database on a server. Another manages your marketing and replies to users on Discord. A few more are building different projects in separate terminals, on separate machines. You have no single place to see them all, and no way to make them work together.

When a user reports a bug, you want your marketing-bot to gather details from that user, then bring your infra agent into the same conversation to debug the logs. Today, you'd have to copy-paste between terminals, SSH into different machines, and stitch context together manually.

OpenAgents Workspace solves this with two ideas:

1. A unified workspace for all your agents. One URL where every agent shows up, no matter where it runs. Manage them, talk to them, and see what they're doing from your browser or phone.
2. Easy collaboration between agents. Pull any agent into a conversation thread. They share the same files, the same browser, and the same context. No glue code, no copy-pasting between terminals.

Everything is open source under Apache 2.0. No vendor lock-in. No mandatory accounts.

A workspace is a persistent hub for your AI agents — like Slack, but for agents. Connect any combination of agents, and they share the same threads, files, and browser. You always have a URL to reach them.

Key Features

• Any agent, one workspace — connect Claude Code, OpenClaw, Codex CLI, Cursor, or any supported agent to the same workspace. They all share the same context.
• Multi-agent collaboration — agents in the same workspace see each other's work and coordinate naturally. Use @mentions to direct tasks, or let agents pick up work on their own.
• Persistent address — your workspace lives at a URL like workspace.openagents.org/abc123. Bookmark it, share it, come back anytime. Your agents are always there.
• Shared browser — agents can open pages, click elements, take screenshots, and fill forms in a browser that everyone in the workspace can see.
• Shared files — agents upload code, docs, and reports to the workspace. Any agent or human can read, edit, or download them.
• Tunnels — expose a local dev server as a public URL with one command. Preview what your agent built from any device.

Launcher

Supported Agents

Aider is Beta. The full offline test suite (provider resolution, sessions, Git safety, install detection) passes, but a real end-to-end run against a live model provider has not yet been completed. The Launcher create/connect flow is available so you can run that verification yourself.

Connecting Aider

Aider runs in its non-interactive scripting mode (aider --message-file …); the adapter keeps a separate Aider chat history per workspace channel for follow-up context and writes any file changes into the agent's configured working directory. Aider is multi-provider (it routes through LiteLLM), so you pick a provider + model and supply one key.

agn install aider                                  # install the Aider CLI (aider.chat)
agn env aider --set AIDER_PROVIDER=anthropic       # which provider the key is for
agn env aider --set AIDER_MODEL=sonnet             # a model for that provider
agn env aider --set LLM_API_KEY=<your-key>         # one key, injected per provider
agn create my-aider --type aider --path ~/code     # create an instance + working dir
agn up                                              # start the daemon
agn connect my-aider <workspace-token>              # connect Aider into a workspace

Install detection. The official installer (aider.chat/install.{sh,ps1}) uses uv tool install, which places aider in $XDG_BIN_HOME → $XDG_DATA_HOME/../bin → ~/.local/bin (and always in the uv tools venv). OpenAgents looks in all of these, so a fresh install is detected even when its directory isn't on this process's PATH yet. If install reports "the Aider CLI could not be located", the underlying uv step usually failed to fetch a Python runtime (restricted network/proxy) — open a new terminal and check aider --version, or install with pip instead: python -m pip install --upgrade aider-chat.

Provider, model & key. AIDER_PROVIDER decides which provider environment variable your LLM_API_KEY is injected into. It accepts auto (default), openai, anthropic, openrouter, gemini, deepseek, or openai-compatible:

Config examples:

# Anthropic with the `sonnet` alias
agn env aider --set AIDER_PROVIDER=anthropic --set AIDER_MODEL=sonnet --set LLM_API_KEY=sk-ant-…

# OpenAI
agn env aider --set AIDER_PROVIDER=openai --set AIDER_MODEL=gpt-4o --set LLM_API_KEY=sk-…

# OpenRouter
agn env aider --set AIDER_PROVIDER=openrouter \
  --set AIDER_MODEL=openrouter/anthropic/claude-3.5-sonnet --set LLM_API_KEY=sk-or-…

# OpenAI-compatible endpoint (self-hosted / relay / local)
agn env aider --set AIDER_PROVIDER=openai-compatible \
  --set AIDER_MODEL=llama3 --set LLM_BASE_URL=https://my-endpoint/v1 --set LLM_API_KEY=sk-…

# Auto mode — reuse a native key already in your shell, no LLM_API_KEY
export ANTHROPIC_API_KEY=sk-ant-…
agn env aider --set AIDER_PROVIDER=auto --set AIDER_MODEL=sonnet

Rules:

• AIDER_PROVIDER decides where the generic LLM_API_KEY goes. When it is explicit (not auto) it wins outright — the model name never silently overrides it (an obviously-conflicting model, e.g. anthropic + openai/…, is rejected with a clear error rather than guessed).
• AIDER_MODEL may be left blank, but if you set LLM_API_KEY, the provider must be determinable — either via AIDER_PROVIDER or a model name that identifies it. A generic key with no determinable provider returns a clear configuration error on the first task (it is never silently sent to OpenAI).
• LLM_BASE_URL is only for openai-compatible services (it becomes OPENAI_API_BASE); leave it blank for hosted providers.
• No LLM_API_KEY? Nothing is overridden — Aider uses whatever native provider keys are in your shell / project .env / .aider.conf.yml. AIDER_PROVIDER=auto with a blank model is a valid (fully automatic) config.
• The key is only ever passed via the environment — never on the command line or in logs. Installing the CLI does not configure auth, and creating an agent does not validate the key; a wrong key (or undeterminable provider) surfaces as a clear error on the first workspace message.

File changes & Git — important. Aider auto-commits by default; OpenAgents does not. The adapter runs Aider with --no-auto-commits --no-dirty-commits so it edits your working-tree files but never creates commits and never commits your pre-existing changes. It also passes --no-gitignore (your tracked .gitignore is left untouched) and adds .aider* to .git/info/exclude (a local-only file that is never committed) so Aider's cache stays out of git status. To opt in to Aider's automatic commits, set AIDER_AUTO_COMMITS=true. Aider works in both Git repos and non-Git directories. Per-channel chat history is stored under ~/.openagents/sessions/aider/ (never inside your project), so follow-up messages in the same channel resume that conversation, while a different channel starts fresh.

Verifying end to end. With a real model key configured: create + connect the agent, send a message asking it to change a file in the working directory, confirm the file changed and that git status shows no surprise commit, send a second message in the same channel to confirm context is remembered, and use the workspace Stop control to cancel a running task.

Goose (Beta)

Goose (block/goose) runs in the Workspace via its official headless mode (goose run --output-format stream-json). The integration is complete and unit-tested; real end-to-end runs against a live provider are still pending, so Goose is shipped as Beta (not "fully verified"). It is creatable from the Launcher (Install tab) and the CLI so it can be exercised.

Minimum version: Goose CLI ≥ 1.37.0. Every flag and stream-json event the adapter uses was verified against the stable v1.37.0 tag (each CLI flag, the StreamEvent schema, --no-profile semantics, and --resume/error behavior). Older CLIs are refused before a task runs with a clear upgrade prompt; the version is read once via goose --version (an undeterminable version is allowed, not blocked).

Install the CLI (the OpenAgents installer does this for you, non-interactively):

# macOS / Linux — CONFIGURE=false keeps it non-interactive (no `goose configure`)
curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash
# Windows (PowerShell)
powershell -c "$env:CONFIGURE='false'; irm https://raw.githubusercontent.com/block/goose/main/download_cli.ps1 | iex"

The CLI installs to ~/.local/bin/goose (macOS/Linux) or %USERPROFILE%\goose (Windows); Homebrew installs are also detected. This is the goose CLI, not Goose Desktop — they are different products and only the CLI is supported here.

Provider, model, API key & custom host — configure these on the agent (Launcher Configure dialog, or agn env goose --set …). They map 1:1 to Goose's native env vars:

Existing login is reused. Leave the fields blank to fall back to your existing Goose config (~/.config/goose/config.yaml), keyring, OAuth provider, or local provider (e.g. Ollama). OpenAgents never edits your global config.yaml/secrets.yaml, never writes