Answer in brief
This OneCLI v2 review is a source and documentation review of the repository metadata, README, release notes, and open issues as of August 24-25, 2026. OneCLI v2 is an open-source platform for running sandboxed AI agents per employee. A central gateway holds credentials and enforces policy, so agents never get the keys directly. It is most useful for teams that already run autonomous agents and need shared secret management, per-agent access control, and a dashboard or Slack surface. It is not a turnkey production product yet. The core is Apache-2.0, but enterprise features under ee/ require a subscription in production. Open issues describe an allow-by-default egress model and credential-scope gaps for sub-agents, and common connectors such as GitHub Apps and multi-account Google are still open requests. No part of this review is based on a local installation or runtime test.
Key facts
| Item | Snapshot |
|---|---|
| Review date | 2026-08-25; repository data collected 2026-08-24 |
| License | Apache-2.0 core, with the OneCLI Enterprise License for ee/ paths (free for development, testing, and evaluation; subscription required for production use, per the README) |
| Stars | 3,396 at review time (snapshot) |
| Language | TypeScript, with a Rust gateway and PostgreSQL-backed control plane per the maintainers |
| Latest release | v2.2.1, published 2026-08-24 |
| Verification level | Observed: source and documentation review only, with no runtime test |
What OneCLI v2 is
According to the README, OneCLI started as a Rust credential vault for AI agents and grew into “the agent harness built for teams.” The maintainers position it as a way to give every employee a secured, sandboxed personal agent. Each agent gets an isolated sandbox with its own filesystem and shell, a conversation surface in the web dashboard or Slack, platform-managed memory, skills, a schedule, and credentials it never sees directly. A Rust gateway intercepts outbound requests, including HTTPS via MITM, and injects the credentials the team granted, matched by host and path pattern. The secret store encrypts with AES-256-GCM at rest and decrypts only at request time.
The architecture splits into several services: a Next.js web dashboard, an API server that owns the database, conversations, and work queue, the Rust gateway, an outbound-only runner that starts and reaps agent sandboxes, an in-sandbox supervisor with a vendor-neutral harness interface, and a Slack channel adapter that gives each agent its own Slack app. The maintainers state that agents run on your own infrastructure and the runner holds no inbound ports, so a laptop, homelab, or VPC behind NAT works without ingress or tunnels. Bitwarden or 1Password can be connected for on-demand credential injection, with nothing stored on the server, per the README.
What changed in the latest releases
The v2 line shipped quickly. v2.0.0 (2026-08-18) introduced workspaces, split services, and hosted agents. v2.0.1 (2026-08-18) fixed chat-native approval cards, cross-surface sync, and channel seams, and restored the GitHub-detectable Apache-2.0 license file. v2.1.0 (2026-08-24) added an SSH front door, registered keys, durable sandbox homes, and hosted-agent fan-out, plus fixes for model-provider refusals, stale approval cards, and a pinned-connection path fallback. v2.2.0 (2026-08-24) added a one-hour turn ceiling with a wrap-up warning, and v2.2.1 (2026-08-24) fixed user-chosen Slack transport, removable org workspaces, and agent-image upgrades on self-hosted installs.
Watch the cadence: the maintainers published v2.0.0 through v2.2.1 within about six days. That signals active maintenance, and it also means the project is a moving target. Plan for frequent upgrades and re-tests, and do not treat any current v2.x as a long-term stable line.
Who should consider it
Teams that already run personal autonomous agents are the intended audience. The README names Hermes, OpenClaw, and NanoClaw as agent runtimes that users brought to OneCLI, and says the missing pieces were secret and permission management plus multiplayer management across a team. If your situation matches, several agents each with different API keys or service accounts and no one able to answer “whose agent did that?”, OneCLI’s model is aimed directly at you.
It is also relevant if you want IdP-provisioned agents per employee, Slack-native agent access under each agent’s own identity, or a single place to define policy and require human approval for high-risk actions such as sending email, deleting a Linear ticket, or emptying an S3 bucket, the README’s examples. The outbound-only runner also suits teams that cannot expose inbound ports.
The converse also follows from the maintainers’ own framing: if you need one assistant for one person, or only API-key management for a single agent, this is heavier than the problem requires. OneCLI’s value is the team layer.
Where maintenance risk shows up
This is a young project, created 2026-03-08, with the v2 rewrite landing in August 2026. The snapshot at review time shows 3,396 stars, 203 forks, and 126 open issues, with the repository last pushed 2026-08-24. Popularity is not proof of quality, and the open issues matter more than the count. Several are directly relevant before production:
- Default egress is not deny-all. Issue #177 asks for a clean deny-by-default mode. The reporter describes adding a block rule with host-pattern
*and manual approval and finding that nothing gets through, and notes that the default egress appears to be “allow anywhere.” The same issue reports no manual-approval path in the CLI or web UI, only through the SDK. Verify your own rules and approval workflow against your threat model before connecting real accounts. - Sub-agents can inherit a wider credential scope. Issue #297 reports that when a parent agent with selective credential access spawns a sub-agent, the sub-agent is created with the “All credentials” default instead of the parent’s restricted scope; the reporter describes a PR authored under a different agent’s GitHub PAT as a result. Treat credential-isolation inheritance as a must-check item, and re-check the issue status, which may change after this review.
- Connector gaps. Issue #192 says the GitHub connection implements only the classic OAuth App flow, with GitHub App semantics mixed in a way the reporter calls confusing and half-working. Issue #180 requests multi-account Google OAuth, issue #334 requests an Obsidian connector, and issue #414 proposes a Google service-account secret type with a community PR. Expect integration work for providers beyond the defaults.
Licensing also needs attention. The repository is Apache-2.0 “with one exception”: the ee/ directories hold enterprise features under the OneCLI Enterprise License, which per the README is free for development, testing, and evaluation but requires a subscription for production use. The README points to LICENSE-ENTERPRISE as the authoritative list of licensed paths; that file was not part of this review, so check exactly which features you need and whether they sit in the enterprise tier before planning a production deployment.
Deployment concerns before production
Self-hosting is not a single binary. The README quick start is git clone, pnpm install, and pnpm run setup, then opening http://localhost:10254. Local development uses mise install, pnpm install, and pnpm dev, which the maintainers say generates a .env with required secrets, starts PostgreSQL, applies migrations, and runs the full stack. The production shape includes a database, a control-plane API server, the dashboard, the Rust gateway, runners, sandbox supervision, and the Slack daemon. This is a multi-service system with a PostgreSQL dependency.
Items to review before connecting anything real:
- Gateway design. The gateway MITM-intercepts outbound HTTPS to inject credentials matched by host and path patterns, and the README notes injection can be via headers or query parameters. If your tooling logs URLs, query-parameter injection is worth examining during your own testing; this review did not verify behavior.
- Credential defaults. Between issue #177, where egress appears to allow anywhere by default, and issue #297, where new agents default to “All credentials”, assume permissive defaults and plan to configure restrictive policy explicitly.
- Upgrade path. With the v2 rewrite only days old at the review date, expect breaking changes. Budget for migrations and re-verification, and keep backups of the database and secret configuration.
- Enterprise boundary. Read LICENSE-ENTERPRISE before committing; confirm which planned features are Apache-2.0 and which require a subscription.
- What was not verified. No local installation or runtime test evidence was attached to this review. Setup steps, performance, reliability, and the behavior of approvals, scheduling, memory, and Slack apps are maintainer claims from the README and release notes, not observed results.
Evaluation questions
- Which agent runtime do you already run, and which integrations does it need, such as GitHub, Google, Slack, or internal tools? Does OneCLI’s current connector set cover them, or are you prepared to build the missing ones?
- Which team features are on your critical path, including IdP provisioning, hosted agents, SSH access, and enterprise licensing, and where do they fall in the Apache-2.0 versus enterprise tier?
- What is your threat model for egress and credentials? Can you define host and path allowlists that match how your agents actually work, and can you live with approval workflows that may currently be SDK-only?
- Who will run the infrastructure? PostgreSQL, the control plane, the gateway, and runners are more than a weekend project; you need someone comfortable upgrading a fast-moving multi-service stack.
- Is the managed cloud at onecli.sh a better fit than self-hosting? Its terms and behavior were not part of this review, but the comparison is worth making before you invest in operations.
Verdict
OneCLI v2 is a serious attempt at the hard problem of team-wide agent operations: per-agent sandboxes, central credential injection, policy, and human approval. As of this observed review, treat it as a pilot candidate for teams that already run autonomous agents and feel the pain of per-agent secrets and access control, not as a settled production platform. The open security and credential-scope issues, the enterprise-license split, and the fast v2 release burst all point to the same approach: evaluate it in a sandboxed environment with throwaway credentials, verify the egress and grant defaults yourself, and only then connect real accounts.
What I can do next
If this review matches your situation, the next step is a scoped pilot: map the agents you already run, check the enterprise-license boundary, and lock down egress and credential defaults before any real data flows. That also means building the connectors your stack is missing, such as GitHub Apps, Google service accounts, or internal tools, and putting upgrade and monitoring processes in place for a platform that changes this quickly. I can run that evaluation, implement the custom integrations, and handle the ongoing maintenance, so you get a defensible go/no-go decision instead of a surprise.