OpenCow: one task, one agent, and no plugin layer

Everything ships as a surface, not a plugin

The platform claims no plugins and no integrations to configure, and the capability list is grouped into four areas that read like a product inventory rather than an extension marketplace.

Task and agent core covers the task tracker, the agent dashboard, live monitoring and multi-project support. Intelligence covers an intelligence hub, a marketplace, a built-in browser and artifacts. Automation covers scheduling, webhooks, notifications and live preview. Command and control covers IM command, a terminal, a command palette and themes.

The distinction matters when you compare agents. Where most coding assistants reach for an ecosystem, the browser here is a feature of the app, the terminal is a feature of the app, and the marketplace is a feature of the app. The trade-off is the mirror image: nothing arrives as a small package you can swap, so a capability that is missing is missing until the project ships it.

That is the whole architectural bet, and it is consistent from the marketing line to the dependency list.

The one-to-one mapping is the model

Everything else follows from a single rule: one task, one agent, with full context and full traceability.

The workflow is three steps. You create by writing a task rather than a prompt, describing the deliverable, and the platform links full context including project files, prior work and related tasks. You dispatch, and each task gets a dedicated agent carrying project knowledge, team playbooks and organizational standards, so fifteen tasks means fifteen agents running in parallel. Then delivery, where agents research, draft, build and publish autonomously, with real-time progress, instant notifications and approval gates at every step.

Context is layered four deep, and the layers are named: organizational knowledge, project context, team standards and task-specific instructions. That is what makes a sub-task agent behave like a colleague rather than a stranger with a prompt.

The task tracker is where the model becomes concrete. Projects break into sub-tasks, each with its own agent, and the claim is blunt: your task list is your delivery plan. Agents can also be suspended and resumed without losing context, which matters when a long research task outlives a session.

Local and private, until you reach the model

The stated principle is local and private: everything runs on your machine, zero telemetry, zero cloud, your data never leaves. The stack supports the claim. Storage is SQLite through Kysely with a type-safe schema and more than 35 migrations, held in a local database, and the application keeps separate data directories for development and production, at ~/.opencow-dev and ~/.opencow respectively.

What the claim does not cover is the model call. The AI layer names the Claude Agent SDK and the Codex SDK with Model Context Protocol, and the project describes itself as multi-engine, letting you choose Claude or Codex as your engine. Task content therefore travels to whichever provider you configured, even though the application data stays put.

For most self-hosted tools that is the expected shape and not a contradiction. It matters when the tasks themselves are sensitive, and the README's privacy line does not address that case.

The desktop framing does help: work happens on your machine, the artefacts land in a local database, and there is no hosted component in the dependency story to audit.

Process isolation, written down as configuration

The architecture section describes a hardened Electron application with strict process isolation, and it names the settings rather than gesturing at security.

Context isolation is on, which is stated as the renderer being unable to access Node.js. Node integration is off, so there is no direct module loading from the page. The bridge is typed, exposed through contextBridge.exposeInMainWorld, and file access is sandboxed behind explicit path allowlists. Development and production data directories are separate, so a development build cannot scribble on real state.

The renderer is the heavier side, with the diagram counting 271 components and 68 hooks over React 19 and Zustand. TypeScript is declared strict with zero uses of any, and the state layer is described as lightweight reactive stores with row-level subscriptions, which is the reason Zustand sits under React 19 rather than a heavier store.

The main process holds the services: 47 or more backend modules including a capability centre for AI capability management, a cron automation engine, multi-channel messaging and a git integration layer, plus the database schema, the data sources and the IPC directory.

For a local tool that touches your files and talks to model providers, having the boundary written this explicitly is worth more than the component count.

Two native modules decide your first ten minutes

The manifest is where the cost of an Electron app with a database and a terminal becomes visible.

Two dependencies are native: better-sqlite3 for the database and node-pty for the terminal. The dev script is preceded by a rebuild step that recompiles both against Electron's ABI, and a separate shell script rebuilds better-sqlite3 before tests and before watch mode. So a first run needs a working compiler toolchain, and every fresh dependency change on those two packages costs a rebuild.

That rebuild is the one step the README quick start does not show you, because it lives in the manifest rather than in the documented commands:

# Clone the repository
git clone https://github.com/OpenCowAI/opencow.git
cd opencow

# Install dependencies
pnpm install

# Launch in development mode (HMR enabled)
pnpm dev

The dev script also raises the file descriptor limit to 10240 before starting, which is the sort of line that appears because the terminal or the watcher ran out otherwise.

Packaging is macOS-targeted. There is a directory-only package, then disk image targets for arm64, x64, universal, and all three architectures in one run, plus a postinstall step that patches the Electron name. The build itself is electron-vite, described as a triple-target build with sub-second hot module replacement.

None of this is unusual for the stack. It does mean the README's prerequisites list, Node 18 and pnpm 9, is not the whole list.

Five assistant instruction files at the repository root

The root of the repository is arranged for coding agents as much as for people. AGENTS.md, CLAUDE.md and GEMINI.md sit side by side, with .cursorrules and .windsurfrules alongside them, which is a project that expects to be worked on by any of several assistants.

There is also a plans/ directory for roadmap documents, a patches/ directory for patched dependencies, resources/ for bundled assets, a components.json, prettier through a .prettierrc, an eslint flat config, and two TypeScript projects split into node and web configurations with a third base config. The typecheck script runs the node project and the web project separately and then combines them, which is the correct split for an Electron app where the main process and the renderer have different type environments.

Testing is Vitest with React Testing Library, configured in its own file with a tests/ directory behind it.

The scripts table in the documentation covers the everyday commands, with dev starting the development server with hot reload and build compiling all targets.

What is missing from the visible documentation is the rest of that table, so the release and packaging commands beyond the ones named in the manifest are not written down here.

Three releases in three weeks, then quiet

The release pattern is short bursts. v0.4.2 was published on 2026-04-20, then v0.5.0 and v0.5.1 both on 2026-05-11, two releases the same day.

The manifest version is 0.5.1 and matches the newest tag, which is a good sign about the release process. The last push to main carries that same date, 2026-05-11, and the repository is not archived.

That date is the fact to plan around. The recorded work on the branch stops there, so anyone considering this for a production workflow is choosing a codebase whose most recent recorded state is from that day, and the honest next step is to read the changelog and decide whether the gap matters for the features you actually need.

Licensing is Apache-2.0, declared in the manifest with a LICENSE file at the root, alongside a security policy, a code of conduct, contributing guidelines, a changelog and a Chinese README. The manifest also carries a brand-check script, which suggests brand assets are verified somewhere in the workflow rather than left to review.

Editorial conclusion

OpenCow fits someone who thinks in task lists and wants each unit of work reviewed as a deliverable rather than a chat transcript, and who is willing to run an Electron app with a compiled native build. It does not fit anyone who needs an agent to stay on their machine end to end, since the engine is a hosted model. Before you build on it, confirm your platform, since the packaging scripts target macOS disk images, and read the last commit date against your own plans.

Frequently asked questions

Official sources

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