Parcha-ai published AgentRun, an Apache-2.0 managed-agent platform that wraps Claude Code, Codex, OpenCode, and pi with durable runs, spend caps, tool approvals, remote sandboxes, and an optional git-based learning loop. The project surfaced on Hacker News on November 12, 2026 as a Show HN entry pointing at the README.
If your team already runs Claude Code or Codex locally, AgentRun is a different layer: it keeps run state in SQLite or Postgres, recovers after server restarts, and can park shell execution in third-party sandboxes while still driving the same harnesses. That split changes where secrets live, what persists between runs, and what you must approve before a tool fires.
TL;DR
| Question | Answer |
|---|---|
| What shipped? | Open-source @parcha/agentrun server, runners, console, workflows, triggers, and learning git folders |
| Am I affected? | Teams evaluating managed agents on top of Claude Code or Codex, or running npx @parcha/agentrun on a shared host |
| Is there a fix? | No CVE—this is architecture. Use approvals on dangerous tools, cap spend, isolate runners, and audit learned skills |
| Does data leave my machine? | Model calls use your configured keys; remote computers use your vendor accounts; Render deploy docs describe a public URL if you choose cloud hosting |
| What should I verify first? | Whether learning is on, whether Docker exposes a shell, and whether AGENTRUN_SEAL_KEY is backed up |
What AgentRun adds to an existing harness
The README frames the problem as repetition: agents rediscover the same APIs and documents on every run. AgentRun's answer is infrastructure around the harness:
- Durable execution. Runs, steps, and journals live in one store. Stopping the server mid-run and restarting resumes work; finished steps are not re-executed.
- Control plane. Mission Control lists waiting approvals, failures, active runs, and cost by harness and tool.
- Computers. Sandboxes (Docker by default when available), Linux desktops, Android phones, or browser sessions via providers such as Daytona, Modal, E2B, Browserbase, or Kernel.
- Workflows. JSON workflow graphs can call tools, models, typed decisions, and fall back to full agents when confidence is low.
- Learning. Optional end-of-run proposals commit notes, skills, or workflows into per-agent git folders on
main.
You bring the harness; AgentRun owns scheduling, recovery, caps, and the console. That is closer to cloud managed-agent patterns than to a single developer running claude in a terminal—but the README explicitly targets laptop, container, and self-hosted server deployments.
Quick start the README documents
Requirements: Node 24.22.3+ on macOS or Linux.
npx @parcha/agentrun
The command starts the server and a runner (port 7340 or the next free port), stores data under ~/.agentrun, and opens the console. You add model keys in Settings → Model keys. One OPENROUTER_API_KEY can feed every harness; Anthropic keys run pi and Claude Code; OpenAI keys run pi, Codex, and OpenCode.
Templates include a KYB due diligence agent. A documented alternative is to tell a coding agent: "Read agentrun.ai/SKILL.md and set up AgentRun for me."
Approvals, caps, and unattended runs
The README's control section is explicit about operator gates:
- Approvals. Each tool is allowed, asks first, or denied. Pending calls block on the run page until you answer.
"Never ask"permits unattended execution, but server-side deny lists still apply. - Spend caps.
max_cost_usdpauses a run at the cap instead of failing silently. - Questions. Agents can stop for human input;
runs waitexits 8 when waiting on a question, cap, or approval.
For security reviewers, the important detail is asymmetry: unattended mode is a product feature. Any deny rule you rely on must be configured on the server before you enable never-ask on powerful tools such as shell, web_fetch, or file writers.
Learning: what gets committed to git
Learning is opt-in via "learning": true on an agent definition. After a successful run, the harness gets one more turn to propose notes, skills, or workflows. AgentRun:
- Applies code checks (size, shape, naming).
- Drops the entire proposal if any item contains a secret, hidden character, out-of-folder path, deletion, or full index rewrite.
- Runs a grader model on what remains.
- Commits keepers to the agent's learning folder (
mainbranch).
Kept artifacts include:
- Notes — markdown in Claude Code memory format.
- Skills — only after a run that completed the job.
- Learned workflows — exposed as one tool call with dry-run validation before retention.
The next run loads active notes and learned skills automatically. That is convenient for throughput and dangerous if a grader misses a subtle instruction injection: learned content becomes persistent system prompt surface.
The README also states that risky rules can wait for operator OK, and that rules discovered in scraped pages or pasted email, or notes holding account numbers, are dropped. Those are heuristics, not proofs—similar in spirit to Beam's 11-pattern skill scan, but applied at commit time on the server rather than on a developer laptop before load.
Computers, keys, and where execution runs
| Kind | Capability | Providers (per README) |
|---|---|---|
| none | Files in run folder only | — |
| sandbox | Shell, packages, background processes | Docker, Daytona, Modal, E2B |
| desktop | Mouse/keyboard on Linux UI | Orgo, E2B, custom Docker image |
| phone | Android automation | phone harness |
| browser | Web automation, operator handoff | Browserbase, Kernel |
Vendor keys are added once under Settings → Computers, sealed with AGENTRUN_SEAL_KEY, and shown only as set or missing. Runs receive keys needed for their tools—not a blanket export of every secret.
Archil disk mode moves run folders off the server filesystem so Daytona, Modal, and E2B can mount the same workspace. Docker sandbox is refused when Archil is enabled for that path.
Compose deploy without a Docker socket gives agents file tools and web_fetch only—no shell. Root compose.yaml with Docker Engine 26+ is required for in-container sandboxes on servers.
Workflows and SECURITY.md warnings
AgentRun workflows are JSON graphs (version 2 schema) with tool calls, model steps, branches, and agent fallbacks. The separate SECURITY.md is blunt:
AgentRun executes trusted workflows. Code nodes and semantic validation probes can execute JavaScript with process privileges. A workflow is not safe merely because it is JSON or passes validation.
Treat workflow authorship like CI pipeline code: only trusted operators should publish graphs that run on shared runners. Adapters own credential handling and external effects; the core cannot undo a completed tool call.
Vulnerability reports go through GitHub private advisories on the repository.
MCP, tools, and the server API surface
The README lists AgentRun Server documentation for models, tools, MCP servers, triggers, spend caps, and learning safety. Architecturally, runs happen on runners that perform approval checks and model calls; the server exposes /v2 plus the console but can start with --no-runner when runners scale separately. State defaults to SQLite in the data directory or Postgres via AGENTRUN_STORE_URL for multi-runner layouts.
That split matters for threat modeling: anyone who can create agents or workflows on the server can schedule recurring execution. Combine triggers with web_fetch, browser computers, or MCP bridges and you have an unattended agent that polls external content on a timer—similar abuse patterns to MCP servers that weaken auth when operators assume "internal only."
The TypeScript and Python clients (@parcha/agentrun-client, parcha-agentrun) mirror CLI flows: start runs, wait with exit codes for pause states, and read run files. Installing npx @parcha/agentrun skill install --claude (or --codex) pushes CLI knowledge into a harness, which accelerates setup but also means a compromised developer machine could script high-volume runs against a shared server if tokens leak from ~/.agentrun/.token.
Triggers and production deployment
Triggers can start capped runs from schedules, signed webhooks, and GitHub pull request events. That turns AgentRun into an always-on agent surface tied to your VCS—overlap with supply-chain vigilance on dependencies and MCP configs.
Deployment options include:
- Render one-click (
render.yaml, ~$25/month instance cited in README). - Docker Compose with generated
AGENTRUN_SEAL_KEYand loopback-only port binding until you add TLS. - Postgres multi-runner layout with shared
AGENTRUN_SEAL_KEY.
The README warns: publish the console on loopback only until a TLS proxy sits in front.
What this means if you run AI coding agents
Concrete checks from the documentation:
- Inventory harnesses. Run
npx @parcha/agentrun server capabilitiesand note which of Claude Code, Codex, and OpenCode are enabled. - Default deny dangerous tools on shared agents; require approval for shell, arbitrary
web_fetch, and MCP bridges you have not reviewed. - Turn learning on only for vetted agents; periodically
learning retirestale notes and diff the git learning folder like any other config repo. - Separate model keys with vendor-side dollar caps (README recommends capped OpenRouter keys on Render).
- Backup
AGENTRUN_SEAL_KEY; losing it loses sealed credentials. - Compare unattended policy with your existing Codex or Claude hook policy—AgentRun caps and approvals are server-side; they do not automatically mirror laptop enforce rules.
If agents run in Docker sandboxes on a host that also holds production checkouts, assume compromise of the sandbox can read anything mounted into /workspace.
Template evals and supply chain
The README documents npx @parcha/agentrun template eval DIR, which runs a template's eval cases as real capped runs on a throwaway server. That is useful for regression testing agent behavior, but each eval still consumes model tokens and may exercise live tools if misconfigured. Treat templates like dependency packages: pin versions, review folder contents before Templates → Apply, and disable triggers until eval scores stabilize—parallel to how teams vet skills that paint shell commands before wide rollout.
Conformance suites for computer providers
AgentRun ships conformance tests per provider (npm run conformance -w @parcha/agentrun-computer). Security teams validating Daytona or E2B sandboxes should run them before trusting remote execution, because a misconfigured provider integration could expose the host filesystem or share one browser session across tenants.
How Beam handles this
Beam watches local Claude Code and Codex sessions: PreToolUse hook denies (when workspace policy is enforce), heuristic scans of skills and MCP configs before load, and on-device event history with redaction before storage. It does not orchestrate multi-tenant agent servers or approve AgentRun console prompts.
The practical split: use AgentRun (or any managed plane) for durable jobs and shared sandboxes; use Beam on developer laptops and CI bots still running harnesses directly, so you retain an independent audit trail even when production work moves to a central runner. Beam does not scan AgentRun's learned git folders unless you point beam scan at exported paths.
Limits: Beam's deny is hook-based, not a kernel sandbox; missing cached workspace policy is fail-open; Cursor and Gemini CLI get advisory messaging only per current docs.
What developers are saying
The Show HN thread had little technical debate at publication time. Commenter jstummbillig noted skepticism about AI-driven UI design maturity rather than AgentRun's security model—useful only as a reminder that managed-agent consoles are new surfaces teams will customize without security review.
Related reading
- Gemini Managed Agents self-hosted sandboxes — another split boundary between orchestration and execution
- KLAD AgentPaint and local command risk — skills that shell out on the host
- Wiz Cyber Model Arena — what harness plus tools can automate offensively
- OpenAI Codex security CLI — vendor tooling for agent security review
- Corelight uvx MCP dependency drift — transitive install risk near agent tooling
Primary sources: AgentRun README, SECURITY.md, GitHub repository.
Frequently asked questions
What is AgentRun?
AgentRun is Parcha-ai's open-source managed-agent server and console. It adds durable runs, approvals, spend caps, optional learning git folders, workflows, and remote computers on top of Claude Code, Codex, OpenCode, or pi.
Which harness should I start with?
The README defaults to pi. Use claude-agent or codex when you already standardized on those CLIs; OpenCode requires the opencode-ai package beside the server.
Can I run it without Docker?
Yes. Without Docker, agents get file tools but no shell sandbox. Docker (or a remote provider) is required for command execution inside an isolated environment.
Does AgentRun scan skills for malware?
It applies learning-time heuristics (secrets, path rules, grader review). That is not a substitute for reviewing templates, MCP servers, or third-party skills before agents load them.
Is the API token as powerful as the console?
The README states the API token cannot write secrets or approve tool calls—console session or loopback launcher handles those sensitive actions.
What Node version is required?
Node 24.22.3 or newer, per the README quickstart.
Version numbers, provider lists, and CLI flags reflect the AgentRun README and SECURITY.md as of November 12, 2026.

