OpenAgents Workspace
A shared workspace for coordinating AI coding agents running across machines and tools.
- Source repo
- openagents-org/openagents
- Stars
- ★ 4.4k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 65/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude CodeOpenAI API · Claude API (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- 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.
- Not a fit if
- Users who want a single agent and no per-runtime credential management
- Teams needing production-stable adapters: Aider and Goose are Beta with real E2E pending
- Source review
- 65/100 · Some 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 | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| OpenAgents Workspace This agent | 65 · Some gaps | CLIFree + model costs | ★ 4.4k | today | TypeScript | Codex · Claude Code |
| MateClaw | 69 · Some gaps | Self-hosted serviceFree + model costs | ★ 1.2k | 3d ago | Java | Codex · Claude Code · OpenAI API · Claude API |
| Memmy — Personal AI Agent & Local Memory Hub | 71 · Some gaps | Desktop appFreemium | ★ 2.2k | 2d ago | TypeScript | Codex · Claude Code · OpenAI API |
| AI Team OS | 69 · Some gaps | Agent plugin / skillFree + model costs | ★ 374 | 12d ago | Python | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The NanoClaw skill describes socket and secret permissions, the local trust boundary, keeping the workspace token out of NanoClaw, and installer input validation. Goose documents automatic tool execution and the lack of a directory sandbox; Aider documents passing keys through the environment. Per-agent configuration, explicit wiring, and approval gates support least privilege and user control, but shared workspace credentials, automatic execution capabilities, and the lack of a general rollback path limit the scores. Several data flows and sensitive-data storage choices are described. Dependency security is supported mainly by version bounds and CI, with little evidence of auditing or vulnerability mitigation. Repository, package, and private reporting channels provide attribution; publisher identity is unverified, so it neither adds nor subtracts points.
The docs describe install-status reporting, errors, retries, session isolation, and process stopping; the CI workflow shows a connector test matrix. However, the README and installation guide say Python 3.10+, while pyproject.toml declares requires-python >=3.8 and still lists 3.8/3.9 classifiers. Product descriptions also span the SDK, Launcher, and Workspace, leaving consistency gaps. External CLIs, databases, Redis, network access, and model providers are runtime dependencies; the materials give install and troubleshooting paths but do not establish availability in a target environment.
The README names varied coding agents, individual users, and mixed human-agent teams, and shows local/hosted workspaces and multiple providers. The docs disclose boundaries such as Goose's lack of a directory sandbox, headless automatic mode, NanoClaw's limited tool traces, and Codex skill support being an adapter path. Skill-use triggers include concrete scenarios, but the Workspace skill's scope is broad and its applicability could be more precise. Python, Node, operating systems, CLIs, and self-hosting are addressed; multi-component and external-service configuration keep environment fit from being fully handled.
The README, tutorials, installation guide, security policy, and component docs form a navigable documentation set, though multiple product areas and long explanations reduce focus. Installation, platform requirements, examples, and troubleshooting are substantial; examples and FAQs are not equally complete across components. The NanoClaw, Goose, Aider, and skill-install docs state limitations. Apache-2.0 metadata matches the LICENSE. The README provides a v1.1 note and migration guide, and the security policy defines supported-version policy, but the supplied material does not provide a comprehensive unified change history. A team email, vulnerability-reporting path, and latest-release policy indicate maintenance responsibility; the publisher remains unverified by the curated registry.
The Workspace combines agents, people, threads, files, and browser collaboration, with approvals, issue tracking, and Launcher management. This can reduce manual context copying across terminals and has clear value. Chat, files, and status outputs support collaboration, but result quality, trace completeness, and end-to-end behavior cannot be established from static material. Installing multiple runtimes and configuring credentials, hosted services, or self-hosted databases/Redis carry costs; the docs explain choices but do not quantify deployment, operations, or model-call costs.
The skill-install document traces control events through local installation and status reporting, with concrete details for some security claims such as validation, file permissions, and invocation methods. The README, CI, and security policy provide some cross-source support. The packet is a sample rather than a complete repository, and no execution was performed, so not all implementation claims can be verified. The docs clearly distinguish pending real end-to-end verification, feature status, and manual verification steps for Aider and Goose; this supports separation of fact from inference. Other capability statements remain partly promotional, and static evidence cannot confirm actual behavior.
- The installation docs recommend Python 3.10+, while package metadata declares Python >=3.8; check the target version against actual dependencies before deployment.
- Goose runs in automatic tool mode without a directory sandbox. NanoClaw Stop rotates the session rather than cancelling the running task, and already-written files are not rolled back.
- The workspace token is shared across the workspace; separate workspaces by trust boundary and carefully configure agents that can take actions.
Maintain this project? Add the FARS badge to your README
[](https://followagents.com/en/agents/openagents)<a href="https://followagents.com/en/agents/openagents"><img src="https://followagents.com/badge/openagents.svg" alt="FARS review"></a>Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
launcher-v1.1.12 OpenAgents launcher-v1.1.12
Release notes excerpt
What's Changed * Polish the sidebar Connect Agent action by @zomux in https://github.com/openagents-org/openagents/pull/939 * Make the Connect Agent action match compact sidebar rows by @zomux in https://github.com/openagents-org/openagents/pull/940 * Soften the compact Connect Agent action to light blue by @zomux in https://github.com/openagents-org/openagents/pull/941 * test(workspace): keep background sessions on the test DB, update stale auth tests by @zomux in https://github.com/openagents-org/openagents/pull/923 …View on GitHub ↗ -
launcher-v1.1.11 OpenAgents launcher-v1.1.11
Release notes excerpt
What's Changed * fix(workspace): restore cached startup state after credential changes by @zomux in https://github.com/openagents-org/openagents/pull/920 * fix(workspace): verify identities once per request by @zomux in https://github.com/openagents-org/openagents/pull/918 * Clarify first-agent onboarding and simplify computer setup by @zomux in https://github.com/openagents-org/openagents/pull/925 * Make command-line onboarding the default, with equal desktop access by @zomux in https://github.com/openagents-org/openagents/pull/926 …View on GitHub ↗ -
launcher-v1.1.10 OpenAgents launcher-v1.1.10
Release notes excerpt
What's Changed * feat(workspace): route completion handoffs through dedicated model by @zomux in https://github.com/openagents-org/openagents/pull/906 * fix(workspace): keep dismissed browser previews closed by @zomux in https://github.com/openagents-org/openagents/pull/909 * fix(launcher-e2e): make the nightly launcher E2E pass again by @zomux in https://github.com/openagents-org/openagents/pull/910 * fix(deepseek): dsh 0.2.1-rc.5 + working workspace access on Linux and Windows by @zomux in https://github.com/openagents-org/openagents/pull/911 …View on GitHub ↗
FAQ
Is an account mandatory?
What credentials do I need?
Can I use Codex CLI and Claude Code together?
What shared resources can agents use?
Does Goose have a filesystem sandbox?
Thanks — we use this to improve the page.