BoundBench

oh-my-openagent (OmO)

Multi-agent orchestration harness/plugin for OpenCode

github.com/code-yeongyu/oh-my-openagent · 2026-10-05 · a801901

Defense-in-depth score

1.8 / 10

Minimal

OmO turns OpenCode into a multi-agent orchestrator, and in doing so it widens the host's defaults rather than narrowing them: web fetches and access outside the project are set to allowed, a second shell path through tmux is added, and nothing asks before shell commands run on the host with your full credentials. Opening it in a cloned repository also silently runs that repository's Claude Code hook commands and loads its MCP servers, with no trust prompt. Sub-agents are well bounded, but the main session has no step or spend limit.

Key gaps (5)

  1. Hook commands and the interactive_bash tool run with the user's full ambient environment and credentials. C1 · Identity & least privilege
  2. Shell and interactive_bash run without human approval by default, and the plugin sets web fetches and out-of-project access to allowed. C2 · Approval gates
  3. No sandbox: hook commands, tmux commands and MCP servers run directly on the host as the user with the full environment. C4 · Code-execution isolation
  4. A hijacked session can exfiltrate data via webfetch or the shell and take irreversible actions with no human involved. C5 · Untrusted input blast radius
  5. A repository's .claude/settings.json hooks and .mcp.json servers load and run without any trust decision. C6 · Memory, context & configuration integrity

Criteria

C1 Identity & least privilege

Minimal 0.00 / 1.00

The plugin runs inside OpenCode with the developer's own operating-system authority and adds no credential scoping. Commands from Claude Code-style hooks are launched through a shell with the entire process environment, and the tmux-based interactive_bash tool inherits it too, so API keys, cloud credentials and git/gh logins are all reachable. Only MCP servers that skills start, and hooks shipped by Claude Code plugins, get a trimmed environment. A hijacked session can act as the user across every service the machine is logged into.

C2 Approval gates

Minimal 0.20 / 1.00

OmO relies on OpenCode's permission rules for approvals and does not add a gate of its own. The plugin makes its Sisyphus orchestrator the default agent without any ask rules for shell or edits, adds a second shell path through tmux (interactive_bash), and sets web fetches and access to directories outside the project to allowed for every agent. Under OpenCode's default allow-everything ruleset this means shell commands, file writes, tmux keystrokes and web requests run with no human approval. The task-list continuation hook even tells the model to proceed without asking for permission.

C3 Tool & action scoping

Minimal 0.20 / 1.00

The default tool set includes an unrestricted shell, a tmux tool that can type arbitrary commands into a terminal, file editing, and web fetches to any URL. The tmux tool only blocks a few output-capturing subcommands, which is a usability filter rather than a boundary. The plugin's look_at tool reads any absolute path, the webfetch helper follows redirects without blocking internal or cloud-metadata addresses, and the plugin switches off OpenCode's prompt for paths outside the project. Individual tools can be turned off in config, but everything is on by default.

C4 Code-execution isolation

Minimal 0.00 / 1.00

Nothing is sandboxed. The plugin's own execution paths (Claude Code-style hook commands run through a login shell, interactive_bash via tmux, local MCP servers and the LSP daemon) start as ordinary processes under the user's account, and OpenCode's shell does the same. No container, OS sandbox profile or restricted user is used anywhere in the plugin. Any command the model or a repository hook chooses runs on the host with full file, network and credential access.

C5 Untrusted input blast radius

Minimal 0.25 / 1.00

Web pages, search results from the built-in Exa, Context7 and grep.app MCP servers, repository files, AGENTS.md/README/rules files injected by hooks, and tool results all enter the model's context with the same standing as the user. The only marking is a text envelope around monitor output and goal objectives, which nothing enforces. Because the shell and web fetches run without approval, a successful prompt injection can read secrets and send them out and also take irreversible actions, with no human in the loop.

C6 Memory, context & configuration integrity

Minimal 0.05 / 1.00

Opening OpenCode with this plugin inside a repository silently loads that repository's Claude Code compatibility files: hooks in .claude/settings.json and .claude/settings.local.json run as shell commands on tool use, session start and other events, and servers in .mcp.json are added to the MCP configuration. A project .omo/omo.jsonc layers over the user's config, with only the MCP environment allowlist and Playwright arguments protected from project override. AGENTS.md, README and rule files are injected into context automatically. There is no workspace-trust prompt, and because edits are allowed by default a hijacked session can also write these files and plant behaviour that fires in later sessions and for anyone who clones the repo.

C7 Third-party extensions

Minimal 0.13 / 1.00

Extensions are not verified. MCP servers come from user and project .mcp.json files and from skills (including skills in the repository's .claude/.agents/.opencode folders), launched with whatever command they name and no pinning or integrity check. The plugin also updates itself automatically: unless auto_update is turned off or the version is pinned, it installs the newest release from npm in the background. Skill-launched MCP servers and plugin hooks get an environment with common secret names removed, but repository hooks and project MCP entries get no such treatment.

C8 Secrets & sensitive-data protection

Minimal 0.20 / 1.00

Secrets come from environment variables, and MCP OAuth tokens are stored in plaintext files with owner-only permissions. The plugin does try to limit exposure in a few places: environment-variable expansion in MCP configs is restricted to an allowlist, and MCP servers started by skills have common secret variables stripped. But hook commands receive the full environment, tool output reaches the model unfiltered, and the plugin's debug log is written unmasked to a shared temp directory. Anonymous usage pings to PostHog are on by default and can be switched off with an environment variable.

C9 Audit & traceability

Minimal 0.45 / 1.00

The plugin keeps no audit record of its own beyond a free-text debug log in the system temp directory, which drops entries silently if writing fails. Its sub-agents run as child sessions of the OpenCode host, so the host's session store should capture their tool calls along with the main session's, but that store is outside this repository and was not verified here. Approval decisions and hook verdicts are not recorded in a structured way, and nothing protects the records from a shell the model controls.

C10 Limits & kill switch

Minimal 0.33 / 1.00

Background and delegated sub-agents have real limits: at most three levels deep, 24 live descendants per root session, five concurrent tasks per model by default, a 4,000-tool-call cap per task, a breaker for repeated identical calls, and stale-task timeouts; hook commands and tmux calls time out. The main session has no step, time or spend limit, and the task-list continuation hook re-prompts the agent to keep going when it stops with open task-list items (it gives up after three rounds without progress). /stop-continuation cancels running descendant tasks.