myclaude: a multi-agent orchestration layer for Claude Code

The problem myclaude targets: one Claude Code session doing every job

Claude Code is good at holding a plan and bad at being the only worker. A single session that plans, edits and verifies tends to lose the thread on long features, and it burns the same model on mechanical edits that a cheaper or more literal backend could handle. myclaude exists to split those roles. The repository describes a two-role architecture: Claude Code as orchestrator, responsible for planning, context gathering and verification, and a binary called codeagent-wrapper as executor, responsible for code editing and test execution. The wrapper is not tied to one vendor. The README lists four backends it can drive: Codex, Claude, Gemini and OpenCode.

The intended audience is narrow and identifiable. You need Claude Code installed, you need at least one of those backend CLIs on PATH with the specific flags the README enumerates, and you need to be comfortable with the idea that a slash command in your editor will spawn another process in your terminal. This is a tool for people already inside the Claude Code workflow, not a way to get into it.

How the orchestrator and codeagent-wrapper split the work

The data flow is command-first. You type a slash command such as /do, /omo or /sparv in Claude Code; that command expands into an agent prompt that plans the task, gathers context and then delegates the actual file edits to codeagent-wrapper. The wrapper translates the request into whichever backend CLI is configured and returns the result to the orchestrating session, which verifies it. The README's architecture table states this division plainly, and the bin/codeagent-wrapper path in the post-install directory listing confirms the wrapper ships as a compiled binary rather than a script.

That design has a cost the README does not discuss. Every backend brings its own CLI contract, and the repository lists the required features per backend rather than a single abstraction: Codex needs `codex e`, `--json`, `-C` and `resume`; Claude needs `--output-format stream-json` and `-r`; Gemini needs `-o stream-json`, `-y` and `-r`; OpenCode is invoked as `opencode` in stdin mode. Those are version-sensitive flags. If a backend ships a breaking CLI change, the wrapper is the layer that breaks, and the failure surfaces as a backend CLI error rather than a myclaude error, which is exactly why the troubleshooting section tells you to run `which codex && codex --version` and its siblings.

The module system sits on top of this. Modules are directories copied into the install target: skills from do, omo, sparv and course; agents from bmad and requirements; commands from essentials; hooks from claudekit. A config.json with per-module `enabled` booleans decides which of them are active, and only `do` is enabled in the example the README gives.

Installing myclaude and running a first /do workflow

The README's recommended path is the npx installer, which fetches the package straight from GitHub rather than from the npm registry. Run it with no arguments for the interactive installer, which is where you select modules and the codeagent-wrapper binary.

npx github:stellarlinkco/myclaude

Before installing, list what is available so you know which module names you will be choosing between. The README shows this as the way to see installable modules, skills and the wrapper.

npx github:stellarlinkco/myclaude --list

If you want the install somewhere other than the default `~/.claude`, or you are reinstalling over an existing tree, the README gives `--install-dir` and `--force`. Both flags appear in the same example block.

npx github:stellarlinkco/myclaude --install-dir ~/.claude --force

After installation the target directory should contain `bin/codeagent-wrapper`, a `CLAUDE.md`, and subdirectories for commands, agents, skills and hooks depending on which modules you picked. Two files are generated rather than shipped: `settings.json` for hook configuration and `installed_modules.json` for module tracking. Verify the second one before you assume the install worked.

cat ~/.claude/installed_modules.json

For a first real task, the README's workflow selection table points feature development at `/do`, described as a five-phase feature development flow with codeagent orchestration, and marks it as the recommended module. Bug investigation and fix go to `/omo` instead, and simple tasks to `/code` or `/debug` from the essentials module. If the wrapper is missing after install, the troubleshooting section says to rerun the installer and select codeagent-wrapper specifically.

Where myclaude breaks: backends, .gitignore and permissions

The README's own troubleshooting table is the most honest part of the project, and it names three failure modes that are structural rather than accidental.

The first is that Gemini cannot read files listed in .gitignore. The suggested workaround is to remove them from .gitignore or switch backends. That is a real constraint on a multi-backend design: the abstraction is not perfect, and file visibility differs by backend. If your project keeps secrets or generated artifacts in .gitignore, routing edits through Gemini is the wrong choice.

The second is Codex permission denial, with the fix given as setting `approval_policy = "never"` in `~/.codex/config.yaml`. Read that carefully. The documented remedy for an executor that cannot write is to disable its approval prompts. That is a deliberate trade of safety for automation, and it is the kind of setting you should decide on consciously rather than paste in because a table said so.

The third is cosmetic: an "Unknown event format" message that the README says is a logging display issue and can be ignored. Fine, but it means log output is not a reliable signal of health, which weakens the verification step the orchestrator is supposed to perform.

Beyond the table, the README does not document rollback, does not describe how to pin a module to a specific version, and does not mention a dry-run mode. The `--update` path detects installed modules from `installed_modules.json` and overwrites module files from the latest GitHub release. Overwrite is the documented behaviour, so local edits to a module are not preserved by design.

myclaude versus the Claude Code plugin system it also ships

The repository contains a `.claude-plugin/` directory and a `PLUGIN_README.md`, so myclaude is not only a standalone installer; part of it is packaged as a Claude Code plugin. That is the closest thing to an alternative inside the same project, and the difference matters.

A plugin is loaded by Claude Code itself and stays inside its extension model. The myclaude npx installer instead copies files into `~/.claude`, writes `settings.json` and `installed_modules.json`, and places a compiled `codeagent-wrapper` binary in `bin/`. The installer route gives you multi-backend execution, because the wrapper is the thing that spawns Codex, Gemini or OpenCode. A plugin route that does not carry the wrapper cannot do that; it can only add commands, agents and skills that run inside Claude Code's own backend.

So the choice is between reach and containment. If you want one backend and a clean extension boundary, the plugin path is the smaller commitment. If the point is to route edits to a different vendor's CLI, you need the installer and the wrapper, and you inherit the flag-compatibility and permission issues described above.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-05-04. Releases are frequent within a version line: v6.8.0, v6.8.1 and v6.8.2 all landed within three days in March 2026, with v6.8.2 on 2026-03-03. The package.json in the repository still declares version 6.7.0, so the manifest and the release tags are not in lockstep. Treat the tags as the release record and the package.json version as stale metadata.

Upgrade cost is low in effort and non-trivial in risk. `npx github:stellarlinkco/myclaude --update` detects installed modules and overwrites them from the latest release. There is no documented way to hold a module at an older release, and no documented rollback if an update breaks a workflow. Because the installer pulls from GitHub rather than a registry, there is also no lockfile pinning the fetched revision. The practical consequence is that a working setup can change under you on the next update, and your recovery path is the git history of the upstream repository.

Licensing is AGPL-3.0, stated in both the README and package.json. AGPL obligations attach to network use in ways that permissive licences do not, so if myclaude ends up inside a service other people reach over a network, the licence question is worth raising with counsel rather than assuming. The README offers a commercial licensing route for use without AGPL obligations, via [email protected]. That address is the only commercial contact the README gives, and the terms behind it are not described.

Editorial conclusion

Adopt myclaude if you already run Claude Code daily and want its planning loop to hand edits to a second backend, and if you accept AGPL-3.0 obligations or will contact [email protected] about commercial terms. Skip it if you have not installed the backend CLIs it shells out to, since the wrapper has nothing to call, and skip it if you need a documented uninstall path or version pinning, because the README describes neither. Before committing, run npx github:stellarlinkco/myclaude --list to see the modules, then read ~/.claude/installed_modules.json after a first install to confirm what actually landed in the directory.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. stellarlinkco/myclaude on GitHub