Coding-agent integration guide

Codex, Claude Code, and OpenClaw integrations.

OpenVibeCoding is the command tower for AI engineering, and it already fits into modern coding-agent workflows, but the truthful entrypoint is not “install our official plugin.” The truthful story today is: read-only MCP, repo-owned skills, API/client entrypoints, and Workflow Cases + Proof & Replay as the common operating record.

Use this page when you want the shortest honest answer to: “How do I actually use OpenVibeCoding with Codex, Claude Code, or OpenClaw right now?”

The safe product positioning is workflow-aligned and read-only MCP-compatible. Codex now has official plugin surfaces, Claude Code currently exposes project-level MCP / hooks / subagent surfaces, and OpenClaw already has plugin + skills hosts of its own. Keep plugin wording narrow: for OpenVibeCoding, the default public story is still integrations + skills + MCP plus local bundle examples, not a published listing.

Open read-only MCP quickstart Open compatibility matrix Open agent starter kits Open builder quickstart Open skills quickstart Open repository README

Need the fastest proof-first walkthrough instead of the deeper integration map? See the first proven workflow.

The shortest truthful compatibility map

Surface	Works today	How OpenVibeCoding fits	What we must not claim
Codex	Yes	Command Tower, Workflow Cases, Proof & Replay, read-only MCP, repo-owned skills, and API/client entrypoints all fit Codex-style governed coding loops.	Do not call OpenVibeCoding a published Codex directory entry or an OpenAI-managed integration surface.
Claude Code	Yes	The same repo-owned surfaces work for Claude Code workflows: read-only inspection, case tracking, operator guidance, and package-level builder glue.	Do not imply an official Claude Code plugin, Anthropic-managed partnership, or hosted account integration.
OpenClaw	Bundle-compatible only when explicitly mapped	OpenClaw belongs in the adjacent coding-agent layer. OpenVibeCoding can still provide read-only MCP, skill-pack guidance, and proof/case review surfaces around it without pretending the same first-class binding as Codex / Claude Code.	Do not present OpenClaw support as an official plugin, native OpenClaw plugin, or first-class product binding unless a real mapped bundle or native plugin ships and is tested.

Official ecosystem reality anchors

Codex

Native surfaces that already exist

Start from the official openai/codex repo, the Codex docs, and the IDE install path.

OpenVibeCoding should wrap Codex workflows with Command Tower, Workflow Cases, Proof & Replay, read-only MCP, and repo-owned skills or local bundle examples. It should not be framed as a published Codex directory entry or an OpenAI-managed surface.

Claude Code

Native surfaces that already exist

Start from the official Claude Code overview and the Claude Code MCP docs.

OpenVibeCoding should fit as the governed review/proof/control-plane layer around those workflows. It should not be framed as a Claude Code marketplace listing or Anthropic-managed plugin surface.

OpenClaw

Native surfaces that already exist

Start from the official OpenClaw repo, the skills docs, and the ClawHub registry/catalog.

OpenClaw already has its own skills and plugin/catalog reality. OpenVibeCoding should therefore land on the integration, proof, replay, and read-only MCP side first, not pretend it already ships a native OpenClaw plugin.

Current distribution status by platform

Platform	Official surface exists?	Current OpenVibeCoding state	Do not overclaim
Codex	Yes. Official plugins surface exists.	Public starter docs, one local marketplace example, and one portable local bundle exist. There is still no official Codex listing receipt tracked here today.	Do not say OpenVibeCoding is listed in an OpenAI-managed directory unless you have the listing URL or receipt.
Claude Code	Yes. Official marketplace, submit, and review flow exist.	Public starter docs and a local `--plugin-dir` bundle seed exist. The OpenHands submission is filed separately, but there is still no Claude marketplace submission receipt tracked here today.	Do not say `submitted`, `in review`, or `live` without the matching official receipt.
OpenClaw	Yes. Official ClawHub registry exists.	Public starter docs plus a compatible local bundle path exist. The matching adoption-router skill is live on ClawHub.	Do not say `in review` for OpenClaw. Its official model is publish-first, not review-queue-first.

Need the exact starter files next? Open the agent starter kits. Need the proof assets that show the public loop is real? Open the public use-case guide.

What teams can actually adopt today

Command Tower as the single operator surface above coding-agent runs
Workflow Cases as the shared operating record that ties request, queue, verdict, and linked runs together
Proof & Replay as the review surface you use before trusting an outcome
read-only MCP when you want machine-readable inspection without mutation
frontend client + contract + shared UI substrate when you want repo-owned builder entrypoints
repo-local skills when you want coding agents to use the same operating playbook

Fastest adoption ladder by ecosystem

Ecosystem	Start here	Then use OpenVibeCoding for	Stop sign
Codex	Codex CLI / IDE docs	Compatibility matrix → read-only MCP or proof-first use case → builder starter if package reuse is needed	Do not call OpenVibeCoding a published Codex directory entry.
Claude Code	Claude Code overview + MCP docs	Compatibility matrix → repo-owned skills + read-only MCP → builder starter for workspace reuse	Do not imply a plugin marketplace or hosted account integration.
OpenClaw	OpenClaw repo + skills docs + ClawHub	Use OpenVibeCoding as the adjacent review/proof/read-only MCP layer, then map packages or skills only when a concrete workflow really needs them	Do not present OpenVibeCoding as a native OpenClaw plugin unless a mapped path is shipped and tested.

Three copy-paste starting points

If your team wants something more concrete than “read the docs,” start with one of these repo-owned paths.

# 1) protocol-first: prove the read-only MCP surface is real
bash scripts/run_openvibecoding_readonly_mcp.sh

# 2) builder-first: prove the thin client + contract bootstrap path is real
node packages/frontend-api-client/examples/control_plane_starter.local.mjs \
  --base-url http://127.0.0.1:10000 \
  --role WORKER \
  --mutation-role TECH_LEAD \
  --preview-provider cliproxyapi \
  --preview-model gpt-5.4

# 3) proof-first: prove the public first-run loop is real
OPENVIBECODING_HOST_COMPAT=1 bash scripts/test_quick.sh --no-related

Need the client-specific setup files after that? Open the agent starter kits for tracked Codex config.toml, Claude Code .mcp.json, and OpenClaw openclaw mcp set starter objects.

Portable drop-in recipe for coding-agent teams

If your real question is “What do I actually hand to Codex, Claude Code, or OpenClaw maintainers this afternoon?”, keep the recipe small and honest:

Vendor the repo truth you want the agent to follow: README.md, AGENTS.md, and only the public route pages or specific skill folders you actually plan to reuse.
Wire the repo-owned MCP server as a stdio command, not as a hosted claim: bash /absolute/path/to/OpenVibeCoding/scripts/run_openvibecoding_readonly_mcp.sh.
Choose only one adoption lane first: protocol-first, skills-first, or builder-first. Do not promise plugin/store support unless a real platform surface exists and is verified.

# 1) keep the repo truth close to the agent
sed -n '1,220p' README.md
sed -n '1,220p' AGENTS.md

# 2) keep MCP on the truthful stdio path
bash /absolute/path/to/OpenVibeCoding/scripts/run_openvibecoding_readonly_mcp.sh

# 3) keep builder adoption copy-pasteable
node packages/frontend-api-client/examples/control_plane_starter.local.mjs \
  --base-url http://127.0.0.1:10000 \
  --role WORKER \
  --mutation-role TECH_LEAD \
  --preview-provider cliproxyapi \
  --preview-model gpt-5.4

OpenClaw teams should use the same three lanes as an adaptation recipe, not as proof of a first-class native plugin.

How to talk about this truthfully

Good wording

“OpenVibeCoding works with Codex and Claude Code workflows through Workflow Cases, Proof & Replay, read-only MCP, repo-owned skills, and builder entrypoints.”

Bad wording

“OpenVibeCoding already ships the official Codex / Claude Code / OpenClaw listing.”

Good wording

“OpenClaw stays in the adjacent coding-agent layer and can use OpenVibeCoding as a bundle-compatible review surface when the mapped path is explicitly shipped and tested.”

Bad wording

“OpenClaw is a first-class officially supported plugin surface inside OpenVibeCoding today.”

FAQ

Is this an official Codex or Claude Code plugin page?

No. OpenVibeCoding is the command tower for AI engineering, not an official Codex or Claude marketplace listing. Codex now has official plugin surfaces and OpenClaw has official plugin and skills surfaces, but the current public story still ships workflow compatibility, read-only MCP, repo-owned skills, builder entrypoints, and local bundle examples rather than a published listing.

Where does OpenClaw fit today?

OpenClaw stays in the adjacent coding-agent layer. OpenVibeCoding can still provide read-only MCP, proof and replay, and skill-pack guidance around it without claiming a first-class native plugin.

Should a new team start from MCP, builders, or skills?

Start from read-only MCP when the first need is protocol inspection, from builders or API when the first need is package-level integration, and from skills when the first need is repeatable operating playbooks.

Does this page mean OpenVibeCoding is hosted or write-capable through MCP?

No. The current public MCP contract is read-only, and OpenVibeCoding should not be described as a hosted operator product today.