OpenAgentsControl: approval-gated agents for OpenCode
AI agent framework for plan-first development workflows with approval-based execution. Multi-language support (TypeScript, Python, Go, Rust) with automatic testing, code review, and validation built for OpenCode
At a glance
- What is it?
- OpenAgentsControl wraps the OpenCode CLI in markdown-defined agents that load your project's patterns and ask for approval before writing code. The trade-off is sequential execution and a hard dependency on OpenCode.
- Who is it for?
- Adopt OpenAgentsControl if your team already runs the OpenCode CLI and has written-down conventions worth encoding as context files. Skip it if you want parallel autonomous agents, or if you are not willing to maintain markdown agent definitions as your stack changes.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The rework problem OAC is aimed at
The README opens with a concrete complaint: agents write generic code, and the developer spends the session rewriting it. The example given is a Next.js route handler. The generic version parses the request body and returns a success object. The version the project argues you actually want parses the body, runs it through a Zod schema, writes through Drizzle, and returns a 201 with the created record. Both compile. Only one matches the conventions of the repository it lands in.
The stated fix is to load those conventions before generation rather than correcting after. OAC calls this a context system, and describes the agent as loading your patterns first so that generated code matches the project from the start. The audience is teams with established conventions: the README's own use-case list says OAC fits when you have established coding patterns and want code that ships without refactoring. That is a narrower audience than "anyone using AI to code". A solo developer with no settled conventions has nothing to encode, and the framework's main selling point has nothing to attach to.
Agents as markdown files, not compiled plugins
OAC sits on top of OpenCode, an open-source AI coding framework, and extends it with agents, context management and team workflows. The design decision that separates it from most agent tooling is that agent behaviour lives in markdown files you edit directly. There is no compilation step and, in the project's framing, no vendor lock-in. Changing a workflow means editing a file.
That choice has a second-order cost the README does not discuss. Markdown agent definitions are not type-checked. If you rename a tool, change a prompt variable, or restructure a workflow, nothing fails at build time. The failure shows up as an agent that quietly stops delegating to a specialist, or ignores a constraint you thought was still in place. Compiled or schema-validated agent configs catch that class of error earlier. Markdown buys editability and pays for it in silent drift.
The context files follow a related principle the README calls MVI, Minimal Viable Information. The stated rules are context files under 200 lines and lazy loading, so only what is needed is loaded when it is needed. The README claims an 80 percent token reduction from this. I cannot verify that number from the repository material, and it depends entirely on what your context files would otherwise contain. Treat it as a design goal, not a measured result.
The propose, approve, execute loop
Execution in OAC is gated. The README states that agents always request approval before execution, summarised as propose, approve, execute. The documented flow for a request is: the agent analyses the request, proposes a plan, waits for your approval, then executes step by step with validation, delegating to specialists when needed.
This is the most defensible part of the design. The project's own comparison table lists execution speed as a weakness, marked with a warning, because sequential execution with approval is slower than the alternatives. That is an honest entry. Approval gates are a cost, not a feature you get for free, and the framework is explicit that it trades throughput for reviewability.
The same table lists error recovery as human-guided validation. When a step fails, a person decides what happens next rather than an automatic retry loop. The README contrasts this with tools whose auto-retry can loop. Whether human-guided recovery is better depends on how available you are. For a long unattended run, it is a stop condition, not a safety net.
Installing it, and what the installer touches
The documented install is a single curl to a shell script. The non-interactive form passes a role argument:
curl -fsSL https://raw.githubusercontent.com/darrenhinde/OpenAgentsControl/main/install.sh | bash -s developer
The interactive form downloads the script first and runs it:
curl -fsSL https://raw.githubusercontent.com/darrenhinde/OpenAgentsControl/main/install.sh -o install.sh bash install.sh
Updates use a separate script from the same branch:
curl -fsSL https://raw.githubusercontent.com/darrenhinde/OpenAgentsControl/main/update.sh | bash
Both scripts are fetched from main rather than from a tagged release, so what you get is whatever is on the branch at that moment. If you installed to a non-default location, the README notes the --install-dir flag, giving ~/.config/opencode as an example. Prerequisites are listed as the OpenCode CLI, Bash 3.2 or later, and Git. The README also says the installer will set up OpenCode CLI if it is missing, which means the script reaches beyond the project's own directory.
Once installed, the documented entry point is:
opencode --agent OpenAgent
followed by a prompt such as "Create a user authentication system". The README states it works immediately with your default model and needs no configuration. A Claude Code plugin is mentioned as an alternative, but the README excerpt does not describe it further, so I cannot say what it does differently.
Where the model-agnostic claim gets thin
The README lists Claude, GPT, Gemini, MiniMax and local models under model agnostic, and the comparison table claims any model, any provider. The mechanism behind that claim is not described in the supplied material. Nothing explains how a single set of markdown agent definitions produces consistent behaviour across models with different tool-calling formats, context limits and instruction-following characteristics.
In practice, agent frameworks that accept many backends tend to work best on the model the author develops against, and degrade elsewhere. That is not a claim about this project specifically. It is a reason to test your intended model rather than assume parity. The README gives no per-model notes, no compatibility matrix, and no statement about which models were used to develop or verify the agent definitions. If you plan to run OAC against a local model, that is the first thing to check yourself, because the documentation will not tell you.
The same gap applies to the multi-language claim. TypeScript, Python, Go, Rust and C# are listed, with "any language" marked by an asterisk. The asterisk is not explained in the excerpt. Given the MVI design, language support likely comes from context files you or the installer write, not from language-specific tooling in the framework. That would make the claim accurate but self-service: the framework does not know Go, your context file does.
How it differs from Aider and Cursor
The README's comparison table places OAC against Cursor and Copilot, Aider, and Oh My OpenCode. Two of those differences are worth taking seriously.
Aider is described as auto-executing with no approval gate and no pattern learning, aimed at solo developers doing simple file edits. The difference in approach is structural: Aider applies edits and you review the diff afterwards, while OAC refuses to write until you approve a plan. If your workflow is already diff-review-based and you are comfortable with it, OAC's gate is an extra step in a process you have solved.
Oh My OpenCode is the more interesting contrast. It is described as fully autonomous with parallel agents, and the table credits it with self-correcting error recovery and faster execution. OAC's stated advantage against it is control and token efficiency. These are opposite bets on the same problem. Parallel autonomous agents finish faster when they are right and cost more to unwind when they are wrong. OAC finishes slower and keeps a person in the loop at each step. The README's own guidance is to pick Oh My OpenCode for autonomous execution with parallel agents, speed over control. That is a fair way to frame the choice, and it means OAC is the wrong tool for anyone whose main goal is throughput on well-specified mechanical work.
Maintenance burden and the MIT licence
Two maintenance surfaces exist. The first is the framework itself, updated by re-running update.sh. The releases listed in the repository move quickly: v0.5.5 on 27 January 2026, v0.7.0 on 29 January, v0.7.1 on 30 January. Three releases in four days, and a jump from 0.5.x to 0.7.x in that window. Frequent releases at a 0.x version number mean you should expect breaking changes between minor versions. Pinning to a tag and updating deliberately is safer than running the update script on a schedule.
The second surface is your own context and agent files. These are the part OAC cannot maintain for you. Every time your stack changes, a schema library is swapped, a directory layout moves, the context files describing those patterns go stale, and stale context is worse than none because the agent will follow it confidently. Budget for that upkeep before adopting.
The licence is MIT, which permits commercial use, modification and redistribution with the licence and copyright notice retained. That is the whole of what I can say from the repository metadata. If your organisation has rules about agent tooling that executes shell commands or reaches out to model providers, the licence is not the question you need answered; your security review is.
What to check before you commit
The install and update scripts run from main via curl piped to bash, and the installer will set up OpenCode CLI if it is absent. Read both scripts at a pinned commit before running them, particularly if your environment restricts what can be installed outside your project directory. The --install-dir flag exists precisely so you can control where files land; use it rather than accepting the default.
Second, check the context files the installer writes. The documented target is under 200 lines each. If yours come out longer, the lazy-loading premise weakens and the token-efficiency argument with it.
Third, run one real task end to end on the model you actually intend to use, and watch whether the agent delegates to specialists as the README describes. The delegation behaviour is the part most likely to differ between models, and it is the part the documentation says least about. If you are evaluating OAC against an autonomous alternative, the deciding question is not which produces better code in a single run. It is whether you would rather review a plan before execution or a diff after it.
Editorial conclusion
Adopt OpenAgentsControl if your team already runs the OpenCode CLI and has written-down conventions worth encoding as context files. Skip it if you want parallel autonomous agents, or if you are not willing to maintain markdown agent definitions as your stack changes. Before installing, verify two things: that the install.sh script at the pinned commit does what the README claims, and that the context files it generates are small enough to stay under the documented 200-line limit.
Community notes