SafetyCard Request a review

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

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.

Safest setup

OmO keeps its sub-agents bounded in depth, concurrency and tool calls, but as shipped nothing asks before shell commands run, web fetches and out-of-project access are set to allowed, and a repository's hooks and MCP servers load on open. The safest setup adds ask rules and trims tools in config, and puts the real boundary outside the tool: a low-privilege account, reviewed repositories and a container or VM.

SetupHowWhat it gives you
A low-privilege accountRun OpenCode from an account or environment holding only the model provider key and the scoped credentials the task needsShell and hook commands reach only what that account holds, not every login on your machine C1
Ask rules for consequential toolsSet bash, edit, webfetch and external_directory to ask in OpenCode's permission block, or per agent under agentsA person sees each shell command, edit and web request before it runs C2
Only the tools neededList interactive_bash and look_at in disabled_toolsOne shell path instead of two, and file reads that go through OpenCode's own tools C3
Reviewed repositoriesRead a repository's .claude/settings.json, .claude/settings.local.json, .mcp.json and .omo/omo.jsonc before opening it with the pluginHook commands and MCP servers that load on open are ones you have chosen C6
A fixed plugin versionSet auto_update: false and pin the plugin to a release in OpenCode's plugin listPlugin code changes only when you decide to upgrade C7
Its own container or VMRun OpenCode in a container or VM holding only the workspace, with outbound access limited to the model provider and the hosts the task needsAn outer boundary around shell, hook and MCP processes, and a narrow path for data to leave C4

Approving with confidence

  • Read each prompt and approve calls one at a time; the task-list continuation hook keeps the agent working without a new request from you.
  • The main session has no step or spend limit, so stay with long runs; /stop-continuation cancels running descendant tasks.

Handling data

  • The plugin's debug log is written unmasked to the system temp directory; on shared machines treat it like other sensitive logs.
  • Anonymous usage pings are on by default; telemetry: false in the plugin config or OMO_DISABLE_POSTHOG=1 turns them off.

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

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

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

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

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

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

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

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

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

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

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.