OneCLI v2: a sandboxed agent harness where credentials stay behind the gateway

The problem is not the agent, it is the second through two-hundredth agent

The README is unusually candid about the origin story. OneCLI began as a credential vault for AI agents written in Rust, and the maintainers say most demand came from individuals and teams running autonomous agents such as Hermes, OpenClaw and NanoClaw. Those tools work well for one person. The stated gap is what happens when you replicate that setup across a team: spinning up each agent, deciding what each one can and cannot do, hosting them, and keeping track of whose agent is whose. That is a provisioning and permissions problem, not a model problem, and it is the problem OneCLI v2 is aimed at. The intended user is an engineering or platform team at a company that has already decided employees should have agents and now needs identity, policy and secret handling around them. The README frames the product as "The agent harness built for teams" and describes the unit of work as one agent per person, reachable from a dashboard or Slack. If you are an individual running a single agent on your laptop, the team features are overhead you are paying for and not using.

Six processes, one gateway, and a sandbox whose only exit is credential injection

The architecture section names the components and they are worth reading in order. The Web Dashboard is a Next.js app for creating agents, chatting, editing memory and skills, and managing connections, secrets and grants. The API Server is the control plane: it owns the database, the conversation plane, and the work queue the runner polls. The Rust Gateway intercepts outbound requests, HTTPS included via MITM, and injects credentials; agents authenticate to it with access tokens in a Proxy-Authorization header. The Runner starts, parks and reaps agent sandboxes, is outbound-only, and per the README never touches the database. The Sandbox Supervisor runs inside each sandbox and speaks what the README calls a vendor-neutral harness interface, so the agent runtime is swappable. An SSH Terminator terminates ssh connections with short-lived certificates and bridges them into sandboxes through a pluggable substrate backend. A Channel Adapter is the Slack daemon, one app per agent. The data flow that matters: an agent inside its sandbox makes a request, the gateway intercepts it, matches the destination by host and path pattern against the secret store, decrypts the matching secret (AES-256-GCM at rest, decrypted only at request time) and injects it as a header or query parameter. The agent never holds the credential. That is the design claim, and it is the one worth verifying against your own threat model, because MITM interception is also the component most likely to break with pinned certificates or certificate-pinning clients.

Getting it running locally is three commands, and that is deliberate

The self-hosted path in the README is short: git clone https://github.com/onecli/onecli.git && cd onecli, then pnpm install, then pnpm run setup, then open http://localhost:10254. The development path differs slightly and is documented separately: clone the same repository, run mise install, pnpm install, pnpm dev. The README states that pnpm dev generates .env with every required secret, starts PostgreSQL, applies migrations, and runs the full stack. Prerequisites, the command reference, project structure and configuration are pointed at docs/development.md rather than reproduced in the README, so that file is the one to read before you assume a config key exists. What the README does not give you is a list of the individual environment variables, the migration tool, or the Postgres version. If you are evaluating this for a locked-down environment, the missing pieces (which secrets are generated, what the setup script writes, whether migrations are reversible) are exactly the questions to bring to the repository rather than to a blog post. The cloud-hosted option at onecli.sh exists as an alternative to all of the above.

The vault integration is the escape hatch from server-side secret storage

Most of the secret story is server-side: AES-256-GCM at rest, decrypted at request time, matched by host and path. The README also documents a second mode, linking to docs/vault-integration.md, where you connect Bitwarden or 1Password for what it calls on-demand injection, with nothing stored on the server. That distinction matters more than it first appears. The default mode means the OneCLI deployment is a system that can, at request time, produce plaintext credentials for every connected service, and its security is therefore the security of the API server, the gateway and the database together. The vault mode moves the plaintext out of your infrastructure and into a vault you already run, at the cost of an additional dependency in the request path. The README does not state the latency or failure behaviour when the vault is unreachable, and it does not describe how on-demand injection interacts with the host and path matching rules. Those are the questions I would ask before choosing between the two modes. The README also mentions global connections shared at the team level, such as LLM keys or service accounts, granted per agent without ever being handed to one, which is the same principle applied to shared rather than personal credentials.

Deterministic approvals are the feature that decides whether this is usable

The README lists deterministic human-in-the-loop approvals, in the chat itself, for actions that need full control: sending an email, deleting a Linear ticket, emptying an S3 bucket. The word deterministic is doing real work there. An approval that is best-effort is worse than no approval, because it produces a false sense of a checkpoint. What the README does not explain is the mechanism: how a tool call is classified as requiring approval, whether the classification is per-tool or per-argument, what happens when the approver is offline, and whether the agent's sandbox is frozen while it waits. Those are the details that determine whether the feature is a control or a notification. My read of the architecture is that the API Server owns the conversation plane and the work queue, so the approval state most likely lives there, but the README does not say so and I will not assert it. The related design choice, that a message sent while the agent is working redirects it immediately instead of queueing behind the current task, is a deliberate bet on interruptibility over ordering. It is the right default for chat, and it is the wrong one if you wanted an auditable queue of instructions.

Where OneCLI is the wrong tool, and what to use instead

Two cases stand out. The first is a single user. If you are one person running one agent, the team machinery (IdP provisioning, per-employee sandboxing, the runner's lifecycle management, the Slack app per agent) buys you nothing, and a local agent runner with a local secrets file is simpler to reason about. The README itself says the single-person tools it names are great for one person. The second case is an environment that forbids TLS interception. The gateway is explicitly described as intercepting HTTPS via MITM, and that is the mechanism by which credentials are injected. If your policy or your client stack rejects MITM, the central design does not apply to you, and the vault integration does not change that, because the gateway is still the injection point. As for alternatives, the honest comparison the README hands you is against the single-user agents themselves: Hermes, OpenClaw and NanoClaw. The difference in approach is not capability, it is topology. Those tools assume the agent runs for the person who installed it and the credentials live with that person. OneCLI assumes the agent runs for an employee, the credentials live in a store the employee cannot read, and a gateway mediates every request. If your problem is capability, a single-user agent is the shorter path. If your problem is that you now have thirty of them and no idea who can reach what, the topology difference is the whole point.

Licence, the ee/ carve-out, and the cost of running six services

The licence is Apache-2.0 with one stated exception: the ee/ directories hold enterprise features under terms the README truncates. That sentence is incomplete in the material I have, and it is the single most important thing to resolve before a commercial deployment, because Apache-2.0 plus a directory-scoped carve-out means the licence of the code you actually run depends on which directories you build. Read LICENSE and the referenced enterprise terms directly; I am not in a position to interpret them. On maintenance, the repository is active, with v2.6.0 released 2026-09-08, v2.5.0 on 2026-09-03 and v2.4.0 on 2026-09-01, and the last push to main dated 2026-09-10. Three minor releases in eight days is a fast cadence for a stack this size, and fast cadences on a self-hosted control plane mean you own the upgrade path: database migrations, gateway and runner version skew, and the sandbox supervisor's harness interface all move together. The operational surface is six named components plus PostgreSQL, and the runner being outbound-only removes inbound firewall work but not the need to keep runners current. Budget for someone who owns Postgres migrations and gateway upgrades, not just someone who clicks deploy.

Who should take this on

The fit is narrow and specific: a platform team that has already validated autonomous agents at the individual level and is now being asked to give every employee one, with an IdP to provision from and a policy that has to be enforced in one place. The gateway model is the reason to choose it, because matching secrets by host and path and injecting them at request time means a compromised sandbox yields access tokens, not the credentials behind them. The mismatch is equally specific: a single user, or a team whose network stack will not tolerate HTTPS interception. Verify three things before you spend a sprint on it. First, the full text of LICENSE and the enterprise terms covering ee/, since the README's sentence is cut off. Second, the actual contents of docs/vault-integration.md, specifically what happens to in-flight requests when Bitwarden or 1Password is unreachable. Third, the approval mechanism, because a human-in-the-loop control that is not deterministic is a liability rather than a safeguard. If those three check out against your requirements, the architecture is coherent and the self-hosted path is three commands deep.

Editorial conclusion

Adopt OneCLI if you already run autonomous agents for individuals and the pain is provisioning, permissioning and hosting them per employee; the gateway model means secrets are matched by host and path and injected at request time, so an agent never holds a key. Do not adopt it if you need one agent for one person, or if your compliance posture forbids TLS interception. Before committing, read the full LICENSE and the enterprise terms governing the ee/ directories, confirm the IdP and Slack integration paths in docs/, and check that the runner's outbound-only design fits your network.

Official sources

1. License: Apache-2.0
2. onecli/onecli on GitHub
3. Project website
4. README
5. Releases