OpenAgents Workspace
A shared workspace for coordinating AI coding agents running across machines and tools.
- Source repo
- openagents-org/openagents
- Stars
- ★ 4.1k
- Last updated
- 1d ago
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 50/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformCodex · Claude CodeOpenAI API · Claude API (Partial support)
- You'll need
- Typical use
- A developer maintaining several repositories can connect local Codex CLI, Claude Code, and Cursor instances to one Workspace and coordinate work in a shared thread.
- Main limitation
- Adoption requires installing supported runtimes and managing their separate model or provider credentials.
- Source review
- 50/100 · Major gaps
What does this agent do, and when should you use it?
OpenAgents combines a browser-based Workspace, a Launcher for managing agent runtimes, and a Network SDK for custom integrations. The Workspace gives connected agents and people persistent URLs, conversation threads, shared files, and a shared browser. The Launcher is available as a CLI and desktop app for installing runtimes, configuring credentials, creating instances, running a background daemon, and connecting agents to workspaces. The documented supported clients include Claude Code, Codex CLI, Cursor, OpenClaw, Gemini CLI, and GitHub Copilot CLI. It fits teams that need several local or remote agents to work in one visible context, provided they are prepared to manage runtime-specific credentials and permissions.
A user installs a runtime with agn install <type>, creates an instance with agn create, sets runtime configuration through agn env, starts the background daemon with agn up, and joins the instance to a workspace with agn connect <agent> <workspace-token>. Connected agents collaborate in shared threads and can use the workspace's shared-file and browser features. The README describes those features as reading, editing, uploading, and downloading files, plus opening pages, clicking elements, taking screenshots, and filling forms in a shared browser. The Launcher also manages runtimes, API-key configuration, and running agents. For custom systems, the Network SDK documents an event-native architecture, a mod system, and MCP and A2A protocol support.
- A developer maintaining several repositories can connect local Codex CLI, Claude Code, and Cursor instances to one Workspace and coordinate work in a shared thread.
- An operations engineer can connect an agent running on a server with an agent handling user reports so both can work from the same issue context.
- A solo developer who needs to check long-running agents from a phone or browser can use the workspace's persistent URL.
- A team reviewing a web task or deliverable can let connected agents work against the same shared browser and files.
- A developer building a custom collaboration system can use the Network SDK's events, mods, MCP support, and A2A support as integration surfaces.
How do you install or deploy this agent?
On macOS or Linux, run: curl -fsSL https://openagents.org/install.sh | bash. Then install and configure a supported runtime, for example: agn install openclaw; agn create my-agent --type openclaw; agn env openclaw --set LLM_API_KEY=sk-...; agn up; agn connect my-agent <workspace-token>. The workspace token comes from the workspace being joined, and the documented OpenClaw example requires a working LLM_API_KEY.
How do you use this agent?
Run agn to open the interactive management dashboard. Install a runtime with agn install <type>, then create an instance with agn create <name> --type <type>; creation only writes the agent configuration unless --install is supplied. Set credentials required by that runtime with agn env <type> --set <KEY>=<VALUE>, start the daemon with agn up, and use agn connect <name> <workspace-token> to join a Workspace. Coordinate the connected agents through workspace threads and @mentions.
What are this agent's strengths and limitations?
- Coordinates multiple supported coding-agent clients in one workspace instead of requiring a single vendor-specific client.
- Combines shared threads, files, and a shared browser so people and agents can work from the same visible context.
- The Launcher offers both a CLI and desktop app for runtime installation, credentials, instance management, and a background daemon.
- The Network SDK explicitly documents an event-native extension model plus MCP, A2A, and self-hosted-network support.
- Adoption requires installing supported runtimes and managing their separate model or provider credentials.
- Aider and Goose are documented as Beta, with real end-to-end verification against live model providers still pending.
- Goose headless mode defaults to automatic tool execution and has no directory sandbox; its project directory is only a convention.
- Runtime adapters such as Aider and Goose have different configuration models and environment variables, so existing workflows need runtime-specific setup.
How does this agent compare with similar options?
OpenAgents Workspace is not presented as a replacement for Claude Code, Codex CLI, Cursor, or OpenClaw. Its documented role is to install, connect, and coordinate these supported clients; availability still depends on each runtime and its configuration.
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| OpenAgents Workspace This agent | 50 · Major gaps | ★ 4.1k | 1d ago | TypeScript | Codex · Claude Code |
| MateClaw | 56 · Major gaps | ★ 1.1k | 2d ago | Java | Codex · Claude Code · OpenAI API · Claude API |
| holaOS | 52 · Major gaps | ★ 11k | 1mo ago | TypeScript | Codex · Claude Code · OpenAI API · Claude API |
| Memmy — Personal AI Agent & Local Memory Hub | 42 · Major gaps | ★ 2k | today | TypeScript | Codex · Claude Code · OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: Aider adapter passes API keys only via environment variables, never on command line or logs; Goose adapter stores keys as passwords, not plaintext; Aider disables auto-commit by default to avoid unintended Git history changes; Goose enables only the built-in developer extension by default, not loading third-party MCP servers. However, no explicit user confirmation mechanism (e.g., approval mode) is found; Goose forces auto mode without human approval; data flow transparency is limited, not detailing how data is transmitted to the workspace; dependency security is weak as pyproject.toml does not pin dependency versions, posing supply chain risk; external effects: Aider modifies working directory files but does not commit by default; rollback: no file change rollback mechanism provided; source attribution: publisher unverified, but code has clear author info. Deductions: lack of user confirmation, insufficient data flow transparency, unpinned dependencies, no rollback.
Evidence shows: Tests cover adapter lifecycle status reporting, Aider install verification, Aider adapter command construction and error classification; test logic is clear and self-consistent. However, dependency availability: no lock file provided, dependency version ranges are broad, may introduce incompatibilities; failure messages: tests verify error classification and status reporting, but not all failure scenarios. Deductions: unpinned dependencies, incomplete failure message coverage.
Evidence shows: README details integration for multiple agents (Claude Code, Codex CLI, Aider, Goose, etc.), covering a wide range of scenarios; capability boundaries: clearly states Aider's Git safety measures and Goose's permission modes; trigger precision: commands and configuration are detailed, but trigger conditions are not explicit; environment fit: supports macOS, Linux, Windows with cross-platform install scripts. Deductions: insufficient trigger precision, unclear when agents are triggered.
Evidence shows: README structure is clear, including quick start, feature descriptions, agent support list, configuration examples; install notes are detailed, providing CLI and desktop app installation methods; naming stability: project name and package name are consistent, but version numbers change frequently; examples and FAQ: multiple configuration examples and troubleshooting provided; known limitations: Aider and Goose explicitly marked as Beta; license: Apache-2.0; versioning changelog: not provided; maintenance responsibility: no clear maintainer or contribution guidelines. Deductions: missing version changelog, unclear maintenance responsibility.
Evidence shows: Output usability: detailed configuration examples and troubleshooting enable quick start; marginal value: provides unique features like multi-agent collaboration, shared browser and files; cost-benefit: open source and free, but requires users to configure API keys and runtime environment, which is costly. Deductions: insufficient cost-benefit assessment, no performance or resource consumption data.
Evidence shows: Claims in README (e.g., supported agent list, features) are supported by corresponding documentation and tests; cross-source corroboration: no third-party verification or independent test results; fact-inference separation: clearly distinguishes Beta status from verified features. Deductions: insufficient cross-source corroboration.
- API key management: Although keys are passed via environment variables, users must ensure key security to avoid leakage in logs or command line.
- Dependency security: Dependency versions in pyproject.toml are not pinned; consider using lock files or fixed versions to reduce supply chain risk.
- User confirmation: Goose forces auto mode without human approval, which may execute dangerous operations; use with caution.
- Rollback mechanism: No file change rollback provided; back up important files before use.