Open-source sandboxed agent harness that gives each employee a governed AI worker
Koda Score = weighted blend: capability 35, ease 20, value 25, momentum 20.
Your team is already running an agent with a real shell and real credentials; OneCLI's whole pitch is putting walls around that before someone rm -rf's production.
OneCLI is not the most capable general software agent; it is the governance layer around one. It is aimed at platform and security leads who have already lost the argument about whether staff will use AI agents and now need those agents boxed in: per-person sandboxes, human-in-the-loop approvals, and a credential layer where the agent never sees the keys. So if you are self-hosting anyway and want an open-source harness rather than a black-box SaaS, it is worth a pilot this quarter.
Every employee gets their own agent and isolated sandbox rather than sharing one privileged runtime.
Agents execute inside isolated environments described in the docs as VMs with logging and identity trails.
Service connections run through a vault so, per the project docs, agents never see the keys.
Defined actions pause for a human approval, which can happen in chat rather than in a separate console.
Policy is set centrally for the team instead of trusting each person to configure their own guardrails.
Agents retain memory and can be given reusable skills, so recurring internal tasks do not start from zero.
Time scheduling lets agent tasks run on a cadence instead of only on demand.
Runs on your own infrastructure via Docker or self-host, with the code published on GitHub.
Concrete setups pulled from the research, not feature-list hand-waving.
Security lead at a company where staff paste production data into consumer chatbots
Stand up OneCLI self-hosted, wire the Slack integration, and give each employee a sandboxed agent with a written list of allowed actions before you announce access.
Employees get an approved agent inside your perimeter, and you get logging and identity trails instead of guesswork.
Platform engineer fielding routine AWS and GitHub requests
Connect AWS and GitHub through the credential layer, define which operations require human approval, and expose them as agent skills.
Routine ops requests get handled without handing out long-lived keys or standing admin access.
Ops or data lead who owns recurring pulls
Build a skill for the recurring pull, attach the relevant service connection, and put it on the built-in scheduler.
The report lands on time from a sandbox you control, with an approval gate on anything that writes.
Isolated sandbox computer, deterministic human-in-the-loop approvals, memory retention, agent skills, time scheduling.
Own infrastructure support, Slack integration, credentials management, global connections.
A free tier that includes real sandboxing and approvals is a fair deal, though the fact that Slack and credentials management sit behind an unpublished Pro price means the tier most teams actually need has no number on it yet.
Pricing as captured on 2026-08-24. Check the live site before you commit.
Real reactions surfaced during research. Paraphrased faithfully, linked to source.
Too new for a street read: the only public traces are a Show HN launch post, a Reddit mirror of it, and a Product Hunt reviews page with no user-written reviews, so there is no meaningful praise or complaint corpus yet.
Open-source general AI software agent that executes broad development tasks.
PICK IT WHENYour bottleneck is agent capability on real engineering work, not org policy or credential isolation.
Enterprise AI assistant platform for internal knowledge and workflows.
PICK IT WHENYou want a managed internal assistant over company knowledge rather than a per-employee sandboxed execution layer.
Hosted browser-driving agent for employee task automation.
PICK IT WHENYou need fast task automation and are comfortable without self-hosted credential isolation or org policy enforcement.
Time to first value: an afternoon for a Docker pilot, longer for a full self-hosted rollout
Follow the docs quickstart to run OneCLI via Docker or self-host on your own infrastructure.
Add service connections such as GitHub, Google, or AWS through the credential layer so the agent never handles raw keys.
Write down and configure the allowed actions plus approval gates, then hand a sandboxed agent to one pilot user.
Per the project docs, no: connections route through a vault and the agents never see the keys. The Show HN framing describes it as a credential gateway with a built-in vault so agents can reach services without key exposure. Verify this yourself against your own threat model before rollout.
The Basic tier is free and includes an isolated sandbox computer, deterministic human-in-the-loop approvals, memory retention, agent skills, and time scheduling. That is enough to run a real pilot. Slack, credentials management, own-infrastructure support, and global connections are Pro features on custom pricing.
Not really. OneCLI is positioned as the governance and sandbox layer around agent execution, with per-user sandboxes, central policy, and approvals. If your primary need is raw agent capability on software tasks, a general agent platform is the closer fit.
The security model is sound in shape, but the public evidence base is thin: a Hacker News launch post, a Reddit mirror, and a Product Hunt page with no written reviews. Since it is open source and self-hostable, do your own code and deployment review rather than leaning on community consensus that does not exist yet.
Treat OneCLI as the seatbelt for agent rollouts you cannot stop, pilot it on the free self-hosted tier, and only talk to them about Pro once you know which actions you are willing to approve.
Field research: 1 pages scraped · 3 search passes · 13 community sources. Reviewed by the Koda desk on 2026-08-24.
The Lab lands in the morning brief. Unsubscribe anytime.