oh-my-claudecode: A Teams-First Orchestration Layer for Claude Code

What OMC Solves and Who It Is For

oh-my-claudecode, or OMC, is a multi-agent orchestration layer built on top of Claude Code. The README's tagline is blunt: "Don't learn Claude Code. Just use OMC." That captures the core value proposition. Teams that already use Claude Code often struggle with coordinating multiple agents across tasks like planning, execution, and QA. OMC provides a structured pipeline so you can issue a single command like "/autopilot \"build a REST API for managing tasks\"" and let the tool handle the rest. It is aimed at teams, not individual tinkerers. The description says "Teams-first Multi-agent orchestration for Claude Code." The target user is someone who wants the power of Claude Code without investing time in its native workflow syntax. The project also offers a sibling for OpenAI Codex users, called oh-my-codex, which suggests the orchestration pattern is meant to be portable across coding agents.

How the Orchestration Works

OMC exposes two surfaces: a terminal CLI (omc) and in-session skills (slash commands like /autopilot). The orchestration is built around named autopilot stage profiles, which are defined in configuration files. A profile contains a version and a list of stages. The admitted stage sequences are limited to four combinations: [ralplan, execution], [ralplan, execution, ralph], [ralplan, execution, qa], and [ralplan, execution, ralph, qa]. So the pipeline always starts with planning (ralplan), then execution, and optionally adds a review step (ralph) or QA. This is a fixed pipeline, not a free-form workflow engine. Profiles are configured under autopilot.workflows in a JSONC file, either project-level (.claude/omc.jsonc) or user-level (~/.config/claude-omc/config.jsonc). A project profile of the same name wholly replaces the user profile. Environment variables cannot define profiles. The design deliberately excludes model fields, inline execution, dynamic commands, and arbitrary stages. That is a conscious trade-off: v1 keeps the system predictable and safe, at the cost of flexibility.

Installation and Setup Commands

The quick start gives two installation paths. The recommended route for most Claude Code users is the plugin marketplace. You enter two slash commands one at a time inside a Claude Code session: "/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode" and then "/plugin install oh-my-claudecode". Pasting both lines at once will fail, so this is a manual step. The alternative is the npm CLI path: "npm i -g oh-my-claude-sisyphus@latest". After installation, setup is done with "/omc-setup" inside a session or "omc setup" from the terminal. If you run OMC with a custom plugin directory, you must add "--plugin-dir-mode" to "omc setup" or export "OMC_PLUGIN_ROOT" before running it, otherwise the installer may duplicate skills and agents that the plugin already provides at runtime. The README points to a decision matrix in docs/REFERENCE.md for all available flags. This is a real configuration detail that can trip up users who use custom plugin directories, so it is worth reading before you start.

The Linux-Only Constraint on Named Profiles

The most significant limitation is that named autopilot stage profiles only work on Linux with the flock utility. The reason is technical: the transcript evidence boundary uses Linux no-follow file-descriptor traversal, and the recoverable mutation lock uses kernel advisory locking. On unsupported environments, invoking "/autopilot --workflow <name>" is rejected before any autopilot state is created or changed. Legacy autopilot without the --workflow flag remains available. This means a team on macOS or Windows can use OMC's basic autopilot, but they cannot use the named workflow profiles. That is a hard boundary, not a soft recommendation. If your team is cross-platform, you need to decide whether the legacy autopilot is sufficient or whether you need to run OMC on a Linux CI machine. The README is upfront about this, which is good, but it also means the headline feature is not universally available.

Known Dependency Warning and Maintenance Cost

The npm install path prints a warning: "deprecated prebuild-install@7.1.3". The README explains that this comes from the upstream better-sqlite3 native-addon dependency. There is no safe repo-side dependency bump or override to remove the warning, because prebuild-install@7.1.3 is still the latest published version. The warning is tracked in issue #2913. This is a maintenance cost: you will see a scary warning on every install, and you have to trust that it is benign. The project cannot fix it without upstream changes. That is worth knowing before you adopt the npm path. The plugin marketplace path may avoid this warning, but the README does not say so explicitly. For a tool that promises zero learning curve, a confusing install warning is a small blemish. It is not a failure, but it is a friction point.

Alternatives: gajae-code and oh-my-codex

The README itself points to two alternatives. For Codex users, oh-my-codex offers the same orchestration experience for OpenAI Codex CLI. That is a direct port of the pattern to a different underlying agent. For Claude Code users who find OMC overkill, the README recommends gajae-code. The pitch is that gajae-code "Keeps Claude OAuth as-is while being faster, cheaper, simpler, and more powerful" and has an SDK-based integration path built for OpenClaw, Hermes, Grokbot, and similar agent runtimes. The key difference in approach is that gajae-code does not wrap Claude Code as a plugin; it integrates at the SDK level, which means it can work with multiple agent runtimes, not just Claude Code. OMC, by contrast, is tightly coupled to Claude Code's plugin system and CLI. If you want orchestration that is not tied to Claude Code, gajae-code is the more portable choice. If you are already invested in Claude Code, OMC's plugin approach is more direct.

What the Documentation Does Not Tell You

The README is clear about installation and workflow profiles, but it leaves several questions open. There is no mention of how OMC handles concurrent agents, error recovery, or resource limits. The transcript evidence boundary is mentioned, but not explained in practical terms. The README says "Everything else is automatic," but that is a promise, not a specification. I cannot confirm from the README how OMC behaves under load, what happens when an agent stage fails, or how it handles long-running tasks. The documentation points to a separate website and a migration guide, but those are not included in the README. If you are evaluating OMC for a production team, you should read docs/REFERENCE.md and the migration guide before committing. The project is MIT licensed, which is permissive, and the repository is actively maintained with recent releases in August 2026. The maintenance appears active, but the dependency warning suggests upstream issues can linger.

Editorial conclusion

Adopt oh-my-claudecode if your team uses Claude Code and needs structured multi-agent workflows with minimal learning curve. Skip it if you are on macOS or Windows and need named workflow profiles, since those require Linux with flock. Before adopting, verify that your Claude Code version supports the plugin marketplace, and check the migration guide if you are upgrading from an earlier OMC version. Also confirm that the npm warning about prebuild-install does not indicate a broken install on your platform. If you want a simpler, cheaper alternative, consider gajae-code, which keeps Claude OAuth as-is and targets SDK-based agent runtimes.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes