mco - Moses Yebei

Abstract

Orchestrate AI coding agents. Any prompt. Any agent. Any IDE. Neutral orchestration layer for Claude Code, Codex CLI, Gemini CLI, OpenCode, Qwen Code — works from Cursor, Trae, Copilot, Windsurf, or plain shell.

The Problem

One AI coding agent gives one perspective. Teams that rely on a single agent inherit its blind spots, and running several agents manually means duplicating prompts, collating outputs, and reconciling conflicting results. MCO solves this by acting as a neutral orchestration layer: one prompt in, parallel execution across multiple agents, one synthesized consensus out.

What This Does

MCO dispatches the same task to Claude Code, Codex CLI, Gemini CLI, OpenCode, and Qwen Code simultaneously, then reviews and merges their outputs. It runs from any IDE or plain shell, making it a provider-agnostic tool rather than another agent to learn.

The core logic lives in runtime/cli.py (entry point, 1,566 lines), runtime/review_engine.py (consensus and review orchestration), and runtime/contracts.py (shared data types). The runtime/adapters/ directory handles per-provider communication, while runtime/bridge/ connects to external tools like evermemos. A substantial tests/ suite (77 files) and docs/ (135 files) cover the adapter contract and design decisions.

How It Is Wired

Execution starts at main in runtime/cli.py:1412, which reaches 311 functions. From there, control flows through run_review (called from 57 places) into the review engine, which coordinates the provider adapters. The system touches the outside world through three main paths: spawning provider subprocesses (subprocess.Popen from runtime/acp/adapter.py), reading/writing files for configuration and state, and one outbound network call.

The most-connected modules are runtime/cli.py and runtime/contracts.py, each imported by 25 other modules. runtime/cli.py is also in a circular import cycle with runtime/session/client.py and runtime/session/manager.py, which makes changes to those files higher-risk than their line counts suggest. runtime/review_engine.py is the functional hub: 63 functions, called from 15 files, and it performs secret generation and file I/O.

The runtime/bridge/evermemos_client.py handles memory persistence via MCP, runtime/formatters.py renders output for different channels, and runtime/config.py manages YAML-based configuration with fallback parsing for edge cases.

How To Use It

Setup: The repo has both pyproject.toml (Python) and package.json (npm). Install with either pip install . or npm install, depending on your preferred toolchain.

Configuration: No environment variables are documented in the repo. Provider credentials are handled by the individual CLIs (e.g., claude, codex), which MCO shells out to.

Running it:

# From the repo root
python runtime/cli.py "your prompt here"
# Or via the npm/bin wrapper
./bin/mco.js "your prompt here"

The README shows mco -h for help and mco "prompt" for execution.

Real-World Use

A team running a security review on a codebase can invoke MCO with a single command:

mco "Review this repo for OWASP Top 10 vulnerabilities, focusing on injection and auth flaws"

MCO dispatches the prompt to Claude, Codex, and Gemini in parallel, collects their findings, runs them through the review engine for consensus, and outputs a merged report. The team gets three perspectives without managing three sessions.

Code Health & Issues

Static analysis (not opinion) found 60 issues: 15 high, 44 medium, 1 low.

High - runtime/cli.py and runtime/review_engine.py are oversized (1,566 and 1,000+ lines), making them hard to modify safely.
High - Circular import cycle involving runtime/cli.py, runtime/session/client.py, and runtime/session/manager.py.
High - Duplicated code: 109 repeated 6-line blocks across 42 files, concentrated in runtime/acp/adapter.py and runtime/adapters/shim.py.
High - GitHub Actions pinned to mutable tags (pypa/gh-action-pypi-publish@release/v1) instead of commit SHAs, a known supply-chain risk.
Medium - 11 instances of broad exception handling that swallow errors; 5 files open without context managers.
Medium - No lockfile for package.json, so builds are not reproducible.
Medium - GITHUB_TOKEN permissions not declared in 2 workflows; no Dependabot configured.

The Bottom Line

MCO is a well-documented, tested orchestration tool for teams already using multiple AI coding agents. The architecture is sound but the core files carry too much responsibility, and the CI pipeline needs supply-chain hardening before production use. Worth adopting if you want multi-agent consensus without building the plumbing yourself.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

568 files

JSON144
Python130
Markdown67
YAML10
Shell5
JavaScript1

React

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["tests<br/>70 modules"] g1["runtime<br/>51 modules"] g2["docs<br/>6 modules"] g3["scripts<br/>3 modules"] g0 -->|163| g1 g3 -->|2| g1

Module dependencies

The 10 most depended-upon modules of 131, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_runtime_cli["cli"] n1_runtime_contracts["contracts"] n2_time_bridge_evermemos_client["evermemos_client"] n3_runtime_config["config"] n4_runtime_review_engine["review_engine"] n5_runtime_adapters_parsing["parsing"] n6_runtime_session_state["state"] n7_runtime_types["types"] n8_runtime_adapters___init__["__init__"] n9_runtime_adapters_shim["shim"] n5_runtime_adapters_parsing --> n1_runtime_contracts n9_runtime_adapters_shim --> n1_runtime_contracts n9_runtime_adapters_shim --> n7_runtime_types n0_runtime_cli --> n8_runtime_adapters___init__ n0_runtime_cli --> n3_runtime_config n0_runtime_cli --> n1_runtime_contracts n0_runtime_cli --> n4_runtime_review_engine n0_runtime_cli --> n2_time_bridge_evermemos_client n0_runtime_cli --> n6_runtime_session_state n1_runtime_contracts --> n7_runtime_types n4_runtime_review_engine --> n8_runtime_adapters___init__ n4_runtime_review_engine --> n5_runtime_adapters_parsing n4_runtime_review_engine --> n3_runtime_config n4_runtime_review_engine --> n1_runtime_contracts n4_runtime_review_engine --> n7_runtime_types classDef cyc stroke:#ef4444,stroke-width:2px; class n0_runtime_cli cyc;

Findings

LowDependencies declared without a lockfile - non-reproducible builds package.json

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium4

low1

Pin third-party GitHub Actions to a commit SHAhigh

.github/workflows

pypa/gh-action-pypi-publish@release/v1

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Commit a lockfile beside the manifesthigh

package.json

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Declare least-privilege permissions for GITHUB_TOKENmedium2 occurrences

.github/workflows/benchmark.yml

2 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/publish-pypi.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/benchmark.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.