HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
onecli
onecli
TypeScript2026–2026
onecli / onecli

onecli

Open-source sandboxed agent harness for teams. Giving every employee a secured personal agent.

6Distinct people
8Mentions
0Explicit recommenders
3.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Open-source sandboxed agent harness for teams. Giving every employee a secured personal agent.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week8 dated mentions

Observed mentions: 2026-03-12 16:41:06 UTC to 2026-08-19 16:29:02 UTC. Weeks start Monday, UTC.

0122026-03-09 00:00:00 UTC to 2026-03-16 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 commentsMar 92026-03-16 00:00:00 UTC to 2026-03-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-03-23 00:00:00 UTC to 2026-03-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-03-30 00:00:00 UTC to 2026-04-06 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-04-06 00:00:00 UTC to 2026-04-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-13 00:00:00 UTC to 2026-04-20 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-04-20 00:00:00 UTC to 2026-04-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-27 00:00:00 UTC to 2026-05-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-04 00:00:00 UTC to 2026-05-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-11 00:00:00 UTC to 2026-05-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-18 00:00:00 UTC to 2026-05-25 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-05-25 00:00:00 UTC to 2026-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsMay 252026-06-01 00:00:00 UTC to 2026-06-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-08 00:00:00 UTC to 2026-06-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-15 00:00:00 UTC to 2026-06-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-22 00:00:00 UTC to 2026-06-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-29 00:00:00 UTC to 2026-07-06 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-07-06 00:00:00 UTC to 2026-07-13 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-07-13 00:00:00 UTC to 2026-07-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-07-20 00:00:00 UTC to 2026-07-27 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2026-07-27 00:00:00 UTC to 2026-08-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-08-03 00:00:00 UTC to 2026-08-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-08-10 00:00:00 UTC to 2026-08-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-08-17 00:00:00 UTC to 2026-08-24 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsAug 17

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Mar 92026-03-09 00:00:00 UTC2026-03-16 00:00:00 UTC211
Mar 162026-03-16 00:00:00 UTC2026-03-23 00:00:00 UTC000
Mar 232026-03-23 00:00:00 UTC2026-03-30 00:00:00 UTC000
Mar 302026-03-30 00:00:00 UTC2026-04-06 00:00:00 UTC101
Apr 62026-04-06 00:00:00 UTC2026-04-13 00:00:00 UTC000
Apr 132026-04-13 00:00:00 UTC2026-04-20 00:00:00 UTC101
Apr 202026-04-20 00:00:00 UTC2026-04-27 00:00:00 UTC000
Apr 272026-04-27 00:00:00 UTC2026-05-04 00:00:00 UTC000
May 42026-05-04 00:00:00 UTC2026-05-11 00:00:00 UTC000
May 112026-05-11 00:00:00 UTC2026-05-18 00:00:00 UTC000
May 182026-05-18 00:00:00 UTC2026-05-25 00:00:00 UTC101
May 252026-05-25 00:00:00 UTC2026-06-01 00:00:00 UTC000
Jun 12026-06-01 00:00:00 UTC2026-06-08 00:00:00 UTC000
Jun 82026-06-08 00:00:00 UTC2026-06-15 00:00:00 UTC000
Jun 152026-06-15 00:00:00 UTC2026-06-22 00:00:00 UTC000
Jun 222026-06-22 00:00:00 UTC2026-06-29 00:00:00 UTC000
Jun 292026-06-29 00:00:00 UTC2026-07-06 00:00:00 UTC000
Jul 62026-07-06 00:00:00 UTC2026-07-13 00:00:00 UTC101
Jul 132026-07-13 00:00:00 UTC2026-07-20 00:00:00 UTC000
Jul 202026-07-20 00:00:00 UTC2026-07-27 00:00:00 UTC110
Jul 272026-07-27 00:00:00 UTC2026-08-03 00:00:00 UTC000
Aug 32026-08-03 00:00:00 UTC2026-08-10 00:00:00 UTC000
Aug 102026-08-10 00:00:00 UTC2026-08-17 00:00:00 UTC000
Aug 172026-08-17 00:00:00 UTC2026-08-24 00:00:00 UTC110

What Hacker News says

8 sources
guyb3·Aug 19, 2026Submission

Launch HN: OneCLI (YC S26) – OSS sandboxed agent harness for teams

Hi HN, Jonathan & Guy here from OneCLI, an agent harness built for teams, giving every employee a secured, sandboxed personal agent. Here’s what you can do with it: 1. get a sandboxed agent, with all the OneCLI capabilities in place like connect your GitHub account, Gmail, Notion, or Dropbox simply from the chat. 2. deterministic human in the loop approval in the chat itself for things that you need 100% control like sending an email or deleting the Linear ticket. 3. manage team policy in one place, enforced across every agent in the workspace 4. enjoy global connections at the team level, like shared LLM keys or service accounts Here’s a demo: https://www.youtube.com/watch?v=dlW-44ntpbE We started working on this by accident, even though our careers were in the security space. We were working on a devtool called ChartDB, an open-source D
Read the rest
B tool. When OpenClaw took off back in January, we started using it to orchestrate agents on top of ChartDB. We quickly understood there is a big issue around auth. Agents need credentials to do real work, but to give them those secrets would not be the best idea. They keep them in their memory and also write them down to local files and their sessions as plain text. And we knew that agents can easily be fooled into giving up those API keys/secrets. So we needed some way to control the agent and stop prompt injections from tricking it into using its services for an attacker's benefit. We created OneCLI that started as a vault for AI Agents built in Rust. We found out that most of our demand for OneCLI came from autonomous agents like Hermes, OpenClaw and NanoClaw for individuals and teams. Users looked for useful agents that do things for the person who runs them with two missing parts: 1) managing secrets and permissions. 2) and for teams - multiplayer management. We decided to pivot and provide the agent itself as a harness for teams, to give each employee an agent. We saw that teams had to deal with setting up their own harness again and again, and basically as we already had the vault as a gateway. We got the idea to provide the missing piece of the agent management out of the box and open source it (Apache-2.0, with a small enterprise exception). We're open source first - the entire platform, not just a small portion of it like other agents, so companies can actually see the code, evaluate it, and trust it instead of taking our word for it. They run it isolated, in their own environment, fully under their control, at production quality, not a locked black box hosted somewhere else. That means the safety isn't just a promise, it's something they can verify themselves. Combined with real autonomy and least-privilege access, that's what makes it something a company can fully own and trust, not just adopt. We also approach this from a company perspective rather than an individual one. Our solution manages agents on behalf of each employee, wrapped in deterministic guardrails that company admins configure through centralized policies. For the agent engine itself we’re using jcode which is the core of the agent-loop. We found out that it improves the experience and makes the agent smarter and faster. Here’s how it works: It runs on infra you control. Fully open-source, self-host or cloud in minutes. The agent never holds a real secret. It gets a placeholder. The real credential is injected at the gateway, per request, after the call is authorized. It never enters the agent's context, memory, or logs. Enforcement outside the model. Prompts are suggestions. Policies defined by the org admin run at the network layer, outside the agent and the LLM. Block endpoints, rate limit per agent, require approval, scope per employee. The gateway decides. The agent can't bypass it. Isolated VM per agent. Own memory, own keys, own permissions. Blast radius is one agent. Speed of the Harness: Rust engine under the agent loop. Full identity trail. Every agent is bound to an employee. Every call logged with who it acted for and which policy allowed it. Some things people are doing with the platform include: - Managing their company life cycle entirely from the sales calls, to the product side automatically open tickets to the engineering teams, that would kick the development agents to deliver and ship to production. - Operational side, like automatically hygiene the CRM after calls, sourcing leads, book meetings and manage follow ups emails. - Some of our customers also doing their entire grocery shopping using those agents and send them to take care of their chores like ordering things online. About the team: Both founders come from cybersecurity backgrounds. Jonathan spent years at Axis Security building zero trust network access. The core idea is that you never trust the client. You decide exactly what a person can reach, and you enforce it outside of them, at the network layer, so it doesn't matter what the client tries to do. That's how every serious company gives access to humans today. Guy was the 1st employee in Argon security doing AppSec. We would love to hear your thoughts on the move, happy to get issues open to improve and get your agent to be powerful and secure - designed for teams, not just individuals.
88 points · Open discussion

Show HN: OneCLI – OSS credential gateway that keeps secrets out of AI agents

hey HN, Jonathan and Guy here, creators of OneCLI (https://onecli.sh/). OneCLI is an open source vault for AI Agents. Traditional vaults are used to store your secrets and, on demand, provide them to you all in a secure way, trusting the person to keep them safe. We figured that in the agent's world, this is not the case, as you don't know what happens with the secret after it's delivered to the agent, or where it was saved. Or maybe someone even manipulated them to hand them over... From that understanding, we decided to build a network gateway that sits between your AI agents and the services they call. OneCLI matches the request by host/path, verifies the agent should have access, swaps the placeholder for the real credential, and forwards the request. the secrets set inside the OneCLI vault, encrypted on rest, or could fetch in realt
Read the rest
ime from your bitwarden / 1password wallets. Demo - https://www.youtube.com/watch?v=5e5pbPEzZfY. We started working on this by accident, even though our careers were in the security space. We were working on a devtool called ChartDB, an open-source DB tool. When OpenClaw took off back in January, we started using it to orchestrate agents on top of ChartDB. We quickly understood there is a big issue around auth. Agents need credentials to do real work, but to give them those secrets would not be the best idea. they keep them in their memory and also write them down to local files and their sessions as plain text. And we knew that agents can easily be fooled into giving up those API keys/secrets. So we needed some way to control the agent and stop prompt injections from tricking it into using its services for an attacker's benefit. Not providing the keys to the agent + adding alerts or human-in-the-loop for sensitive operations, in case someone manipulates the agent, and access logs are being audited. We use it ourselves daily. My OpenClaw runs my day across Attio, Gmail, and my calendar, with human-in-the-loop approval on sensitive actions. The approval is enforced at the network layer, so it holds whether the agent goes through MCP, CLI, curl, or code it wrote on the fly. Guy uses it to review PRs but can't merge without his approval. Companies mostly use it for coding agents currently, which get creative about finding ways to elevate their permissions to reach the goal. With OneCLI, it doesn't matter what the agent finds: if the request isn't in policy, it will not go through. The proxy is written in Rust, the dashboard is Next.js, and secrets are AES-256-GCM encrypted at rest. Everything runs in a Docker container. It works with any agent framework (Claude Code, Codex, Cursor, OpenClaw, Hermes or anything that can set an HTTPS_PROXY). It won't stop an agent from misusing access it legitimately has, so scope policies tightly! happy to answer anything. We believe we can't trust the model to behave and have to set deterministic rules to stay in control. Comments welcome!
110 points · Open discussion
Most developers I know don't seem to care about the "right way" to run agents. They either yolo it on their primary dev machine, or setup a separate box (VM, VPS, Rpi, Mac mini) and let it run there with minimal protection. You could simply do the same, running Hermes or Pi on a VPS (e.g. Digital Ocean). Note that Pi has no protections so you probably ought to take extra steps. Hermes uses a container. My setup took a long time to build and I don't know any devs personally who go thru the trouble. * I use a custom harness in a podman container run by a non-sudoer system account. File access is limited to specific ZFS datasets. I don't use Anthropic models for agentic work. * You can find an open-source network proxy that injects credentials into the network requests, I made a custom one. https://github.com/onecli/onecli https://gith
Read the rest
ub.com/smart-mcp-proxy/mcpproxy-go https://github.com/mcpharbour/mcpharbour https://github.com/bglusman/calciforge * I made a custom shell (nearly posix-compliant) and don't give it access to regular bash, thus no need to filter its shell commands. You could use an open-source one if you care about this: `https://github.com/search?q=agent+bash+shell&type=repositori...` * Same story for agent memory, context management and token reduction/compression, but this requires a lot of constant tweaking. Again, there are a lot of open-source repos addressing these aspects. Just search github, hn.algolia.com, and/or look at subreddits like /r/agentsofai /r/ai_agents * Also the agent must be able to run/test the generated code, so if you're targeting another platform you need a MCP or deployment tool that'll allow testing.
In Ask HN: Opinionated Agent Setup?
There are worse things to mention about OneCLI as it looks like a completely vibe-coded mess, seeing that CLAUDE.md and Claude itself being one of the contributors [0] Perhaps the most damning discovery is that they don't even do basic dependency pinning [1] [2] which just risks another supply chain attack. As soon as I saw that, that was everything I needed to know about the project. No security audit whatsoever and Bitwarden believes this is something worth integrating. [0] https://github.com/onecli/onecli/graphs/contributors [1] https://github.com/onecli/onecli/blob/main/packages/ui/packa... [2] https://github.com/onecli/onecli/blob/main/packages/db/packa...
In Bitwarden integrates with OneCLI agent vault
guyb3·Mar 12, 2026Submission

Show HN: OneCLI – Vault for AI Agents in Rust

We built OneCLI because AI agents are being given raw API keys. And it's going about as well as you'd expect. We figured the answer isn't "don't give agents access," it's "give them access without giving them secrets." OneCLI is an open-source gateway that sits between your AI agents and the services they call. You store your real credentials once in OneCLI's encrypted vault, and give your agents placeholder keys. When an agent makes an HTTP call through the proxy, OneCLI matches the request by host/path, verifies the agent should have access, swaps the placeholder for the real credential, and forwards the request. The agent never touches the actual secret. It just uses CLI or MCP tools as normal. Try it in one line: docker run --pull always -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli The proxy is written
Read the rest
in Rust, the dashboard is Next.js, and secrets are AES-256-GCM encrypted at rest. Everything runs in a single Docker container with an embedded Postgres (PGlite), no external dependencies. Works with any agent framework (OpenClaw, NanoClaw, IronClaw, or anything that can set an HTTPS_PROXY). We started with what felt most urgent: agents shouldn't be holding raw credentials. The next layer is access policies and audit, defining what each agent can call, logging everything, and requiring human approval before sensitive actions go through. It's Apache-2.0 licensed. We'd love feedback on the approach, and we're especially curious how people are handling agent auth today. GitHub: https://github.com/onecli/onecli Site: https://onecli.sh
161 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.