Skip to content

fidelodok/metaforge

v0.1.0Apache-2.0

Engineer hardware against a digital twin: requirements, CAD, simulation and evidence, with writes held for human approval.

GitHubOpen Website

MetaForge for Codex

Generated by scripts/build_integrations.py — do not edit by hand.

As a plugin

Codex reads a marketplace at .agents/plugins/marketplace.json, and an entry's ./plugins/<name> resolves from the directory that contains .agents/, not from the marketplace file:

<root>/.agents/plugins/marketplace.json   <- copy marketplace.json here
<root>/plugins/metaforge/                 <- copy this directory here

<root> is either your project or your home directory. Restart Codex, then /plugins.

Or wire the MCP server up by hand

Append config.toml to ~/.codex/config.toml and restart. This needs no plugin and is the path this repo has been running.

What is verified

Loaded and driven end to end against codex-cli 0.118.0 and 0.159.2 — the manifest format survived that upgrade unchanged, which is the thing most worth knowing, since the format was read out of the binary rather than from a published spec.

Installation, checked by driving codex app-server over stdio rather than by eyeballing /plugins:

  • plugin/list finds the marketplace and returns metaforge@metaforge with marketplaceLoadErrors: [] — the manifest parses, installPolicy and authPolicy survive, and every interface field lands where the curated plugins put theirs.
  • plugin/read resolves all 43 skills and mcpServers: ["metaforge"].
  • plugin/install succeeds and writes [plugins."metaforge@metaforge"] into ~/.codex/config.toml.
  • Codex connects to the MCP server itself: its client logs server_info: Implementation { name: "metaforge-mcp" } at protocol 2025-06-18, and tools/list returns the MetaForge tools.

And the agent actually uses them:

  • A read goes through. Codex called project.list and got back a status: success envelope.
  • A write is held. Codex called project.create; the server refused with -32001 / code: approval_required, outcome: not_configured, retryable: false, naming the caller as untrusted. A follow-up project.list came back empty, so the write did not run — which is the point. A guardrail that returns an error after doing the write is worse than none, because the error makes it look like it held.

That second one is why the guardrails exist at all: the same tool was gated when a person asked in the dashboard and ungated when an external harness asked over MCP. It is gated now, and this is an external harness asking.

One cosmetic wart: Codex opens GET /mcp for a server-initiated SSE stream, the sidecar answers 405 (which the Streamable HTTP spec permits), and Codex logs that as an ERROR line before carrying on normally. It is not a failure — ignore it.

If the plugin ever stops loading, re-check the manifest format against your Codex version first: it is read from the binary, not from a published spec, so a Codex upgrade can move it.

Skills

43 engineering skills are bundled. Codex prefixes a plugin's skills with its name, so they appear as metaforge:<skill>.