Claude Code, wired in

The problem it removes

Most setups are engine-specific by accident. Your Claude Code skills are in ~/.claude/skills/. Your Gemini config is somewhere else. Your Codex prompts are somewhere else again. When you want to compare two backends on the same task, you're reconfiguring from scratch. When Claude releases a new model, you update one place; when you try Gemini, you rebuild.

Ikenga's engine layer removes that accident. Each engine is a manifest-declared pkg. Your skills, commands, and MCP servers install once and are available to all of them. Swapping backends for a thread is a two-click popover, not a config migration.

Claude Code is the default, fully wired

Claude Code (com.ikenga.engine-claude-code) ships as the built-in engine pkg — your Chi, the reasoning layer at the heart of every thread. It spawns your local claude binary, parses its stream-json output through a Rust translator, and produces normalized SessionUpdate envelopes on the shell's session wire. Every shell feature — session persistence, resume (claude --resume <id>), the cockpit's skills/commands/MCP manager, thinking, tool use, MCP — is exercised through this path.

No separate account required. Auth is claude login or ANTHROPIC_API_KEY — whichever you already use in the terminal.

Gemini and Codex as pluggable adapters

Gemini CLI (com.ikenga.engine-gemini) and Codex CLI (com.ikenga.engine-codex) follow the same manifest-and-adapter pattern. Both are separately installable engine pkgs — add them from the shell's package manager or directly via the ikenga CLI. Install one or both alongside Claude Code; remove either without touching anything else.

The Gemini adapter uses an ACP passthrough: it spawns gemini and proxies its JSON-RPC 2.0 NDJSON protocol bidirectionally. The Codex adapter uses a custom stream adapter: it parses codex exec --json output into the shell's normalized envelopes. Either way the frontend sees the same wire — one session shape, one chat UI, regardless of which engine is active.

Each adapter's manifest declares an onboarding block: which vault keys it needs (GEMINI_API_KEY, OPENAI_API_KEY), the auth command to copy, and a docs link. The first-run wizard surfaces this before you can start a thread, so auth never breaks silently.

Per-turn engine and model switching

A chat thread is created with one engine and stays pinned to it — sessions resume against the same backend they were started on. But within a thread, the composer lets you swap the engine and model per turn: a single send can route to a different backend without changing the thread. The picker is a two-level Engine → Model popover, always visible in the composer.

This is useful for comparison: start a thread with Claude Code, send the same prompt to Gemini in the next turn, see both responses in the same history. No context copy-paste, no tab-switching.

Engines are pkgs — the architecture is open

Every engine adapter is a standard Ikenga pkg. It declares a kind: "engine" manifest, a capability matrix the UI reads to enable or disable features per backend, and the onboarding metadata for the auth wizard. Installing or removing an engine is the same operation as installing or removing any other pkg.

Adding a brand-new engine today requires both a manifest pkg in ikenga-pkgs and a Rust adapter in the shell — it is not yet a pure drop-in. The Engine interface in @ikenga/contract is the direction of travel; treat it as forward-looking until the purely-pkg-side adapter path lands.

Available engines

Each engine requires its CLI binary on your $PATH. The shell resolves the binary path from a configurable setting (claude_binary, gemini_binary, codex_binary) so non-default install locations work.

Install

Claude Code is the built-in engine — it is active as soon as you install the Ikenga shell. No extra step.

To add Gemini CLI or Codex CLI:

Apache-2.0. Read it.

See also