OpenCode

Why it's ranked here

The case here is breadth and discipline, not novelty. Permission rules that allow, deny, or ask per tool and per pattern are enforced in the same module that ships built-in auth plugins for a dozen-plus providers, not left to documentation. Internal style and terminology guides read like one team maintaining a single architecture over years, not a demo wrapped around a chat loop. MIT licensing and installers spanning every major platform round out a genuinely mature project, though it openly refuses to sandbox anything it executes.

What's good

Permission handling is genuinely granular: rules match by wildcard pattern and by tool, remember an always choice, and cascade to reject or approve other pending requests in the same session automatically. The plugin system ships built-in authentication for over a dozen providers out of the box, and the MCP client supports three transport types with OAuth handling built in, not bolted on. The SDK can embed the whole server in-process, skipping the network round trip for tooling that runs alongside it.

Tradeoffs

There is no sandbox: the maintainers say plainly that permission prompts are a user-experience aid, not isolation, so anyone running it against untrusted repositories should wrap it in a container or VM themselves. The internal architecture leans hard on a functional effect runtime with generator-based control flow throughout the server and plugin layers, a style that raises the learning curve for anyone used to plainer TypeScript. A long list of patched third-party dependencies also signals real friction under the hood, even if each patch is deliberate.

How to use it well

This suits developers who want a single agent they can point at real shell and file access under supervision, then flip to a read-only planning mode when exploring unfamiliar code before committing to a change. Turn on the general search subagent for broad codebase questions instead of burning the primary agent's context. If you expose the server beyond your own machine, set a server password yourself: it ships unauthenticated by default. It is not a sandboxed execution environment, so pair it with a container when running against code you do not trust.

Observed

License

Licensed under MIT.

Language

TypeScript codebase organized as a Bun-managed workspace monorepo across many internal packages.

Interfaces

Ships as a command-line tool, an HTTP server with a generated API client, an embeddable SDK, and an MCP client supporting stdio, SSE, and StreamableHTTP transports.

Distribution

Distributed through npm, Homebrew, Scoop, Chocolatey, pacman, the AUR, mise, and Nix, plus a separate desktop application packaged as dmg, exe, deb, rpm, and AppImage builds.

Security posture

Server mode requires an explicit password environment variable to enable authentication; it runs unauthenticated by default otherwise.

Isolation model

The project's own security documentation states the permission system is a user-experience feature, not a sandbox or isolation boundary.

Test tooling

The root package.json test script intentionally fails, forcing tests to be run from individual package directories rather than the repository root.