06-reference/research

claude config portability across runtimes

2026-05-27·research-brief·source: deep-research
portabilitymulti-runtimegrok-buildcodexharness-engineering

Is multi-runtime portability of RDCO's ~/.claude/ harness a real hedge, or a distraction from depth on Claude Code?

The question

How portable is RDCO's ~/.claude/ skill + harness config across runtimes (xAI Grok Build, Codex, Cursor) in practice — what transfers cleanly, what breaks — and is a multi-runtime portability posture a genuine hedge/moat or a distraction from depth on Claude Code? Context: AlphaSignal 2026-05-26 reported Grok Build now reads CLAUDE.md unchanged and supports Skills/hooks/MCP; SkillOpt (arXiv 2605.23904) showed optimized skills transfer Codex ↔ Claude Code. Distinct from the OpenAI-substrate-threat brief — this is portability-in-practice as a posture question, tied to an existing Grok-CLI eval Notion task.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

The portability picture cleanly splits along the same fault line the vault already named. What transfers across Grok Build, Codex, and Cursor is the content of RDCO's harness: the ~100 SKILL.md files (procedural knowledge — the verify-* critics, process-newsletter, deep-research, the pipeline seats) and the MCP server roster (Gmail, Notion, Calendar, xmcp, etc.). These are now demonstrably a cross-harness asset, not a Claude Code lock-in. What does NOT transfer is the machinery that makes RDCO an always-on autonomous COO rather than a coding assistant: settings.json hooks with deterministic ordering, the cron/LaunchAgent/Monitor session model, the autonomous-merge classifier and permission gates, the working-context.md ledger, and CLAUDE.md hard-rule enforcement with a real precedence chain. Codex's migration doctrine concedes the gap directly — cron has "no direct port path," subagents stay advisory, settings.json has no equivalent. So the literal answer: ~80-90% of RDCO's configuration capital is portable, but the ~10-20% that breaks is precisely the part that makes Ray autonomous rather than interactive. The autonomy is Claude-Code-specific today.

Is a multi-runtime portability posture a genuine hedge/moat? It is a genuine hedge but a weak moat — and pursuing it actively would be a distraction. It's a hedge because RDCO's bet was always "fat skills, thin harness" (Tan) and the skills + MCP being portable means RDCO is not stranded if Anthropic raises prices, degrades the model, or sunsets a primitive. That optionality already exists for free, by virtue of having built on the portable layer — RDCO does not need to do anything to hold it. It is not a moat because the moment skills are portable, they are also commoditizable: anyone can copy a SKILL.md. The actual moat is unchanged from the harness-moat-two-layers analysis — it's the Layer-2 personal-fit accumulation (Ben's earned hard rules, voice, vault) plus the orchestration machinery and verify-gate discipline that does NOT port, plus operating-time. SkillOpt sharpens this: the frontier is "whoever builds the verifier for open-ended tasks," and RDCO's verify-* critic gates are early on exactly that — but they're worth more as executed discipline on a deep substrate than as portable files.

The posture recommendation: go deep on Claude Code; treat portability as a low-cost insurance policy you already own, not a roadmap item. Concretely, do three cheap things and nothing more. (1) Keep authoring behavior in SKILL.md skills and MCP, not in CLAUDE.md prose or settings.json — RDCO already does this; just keep the discipline so the portable layer stays fat. (2) Run the one cheap experiment the Grok Build news unlocks: point Grok Build at the existing ~/.claude/ config and diff the behavior on a representative skill (a verify-* critic) — answer whether "reads CLAUDE.md" means executes-semantics or parses-but-ignores. This retires the open unknown on the Notion eval task for the cost of one session. (3) Do NOT invest in maintaining a parallel AGENTS.md / Codex / Cursor config, do NOT abstract skills to a lowest-common-denominator that loses Claude-Code-specific power (hooks, classifier, cron), and do NOT frame multi-runtime support as an RDCO product axis. The depth that matters — autonomous operation, the cron loop, the classifier, the accumulated personal-fit layer — is where the differentiation lives, and all of it rewards going deeper on one substrate rather than spreading thin across four. Portability is the consequence of having built right, not a goal to chase.

Open follow-ups

Sources