Jason ZhouandClaude Opus 5
46459b5b36
Supersedes the previous take, which told the agent to SKIP `treg mcp install`. That was wrong twice over. Wrong on intent: the wanted end state is CLI + skill + tools, not skill alone. Skills-only is a property of the MANIFEST, not of what the user ends up with. The manifest still declares no connector — anything it declared would be registered at install time, before a human has signed in, i.e. five always-on tools that 401 on every call — and that is what keeps `/plugin install` zero-config. The SKILL then finishes the setup at first run, when a human IS present to sign in. Wrong on fact: it warned that `treg mcp install` would "register a second copy which would fail with 401". cmd_mcp_install does neither. It reads the token from config and sys.exits BEFORE writing anything when there is none, and again on a 401 with "nothing was written". So a premature run is a silent no-op, and after `treg login` the registration simply works. An overstated warning in the product's most-read page is its own kind of wrong. The bootstrap is now an ordered three-step block — install.sh, treg login, treg mcp install — and the order is load-bearing for the reason above: step 3 ahead of step 2 writes nothing, quietly enough that an agent moves on believing the tools exist. A test pins the sequence, and pins the restart note too, since `claude mcp add` does not take effect until the agent restarts. Also noted for the human rather than acted on: install.sh always runs `treg skill bootstrap` (no flag suppresses it), so step 1 drops a second copy of this same skill into ~/.claude/skills/treg/. Harmless but redundant with the plugin. Deleting files under $HOME is not a skill's call to make. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012x16Skh3DNWoqv7LgNxUYF
treg — Codex / ChatGPT plugin
A distribution wrapper, not a second product. It ships the same skill that
treg skill bootstrap already installs into ~/.codex/skills/, packaged so people find treg by
searching the plugin directory that ChatGPT and Codex share.
One of two plugins. The Claude Code plugin lives at the repo root (
.claude-plugin/+skills/treg/) and declares no connector in its manifest, so it installs with no token and nothing about it waits on a review queue — its skill wires up the CLI and the MCP tools at first run instead. Both are rendered by the samescripts/build_plugin.pyfrom the same source; they differ only in the prepended bootstrap. Seedocs/CLAUDE-PLUGIN.md.
plugin/
├── .codex-plugin/plugin.json the manifest + the listing copy
├── skills/treg/ GENERATED — do not edit by hand
└── assets/ icon + logo (▚ in clay #e0703f)
The skill is generated
src/treg/web/skill.md is the one source. It is served at /skill.md, written into every agent by
treg skill bootstrap, and rendered into this plugin by:
python3 scripts/build_plugin.py # regenerate BOTH plugins
python3 scripts/build_plugin.py --check # fail if either is stale (also a test)
Two things differ from the served copy, both because a plugin arrives where the server does not:
{BASE}is baked to the public deployment. The server substitutes that placeholder per request; nothing substitutes it inside an installed plugin, so a raw copy would ship the literal.- A bootstrap section is prepended. Every other install path implies the CLI already exists —
treg skill bootstraponly runs becausetregis installed. This is the one path where the skill can land on a machine with no treg at all, and without it a first run ends incommand not found.
Never edit skills/treg/SKILL.md. Change src/treg/web/skill.md and regenerate;
tests/test_plugin.py fails if the two disagree.
Testing it locally (verified with codex-cli 0.145.0)
No desktop app required — the Codex CLI installs and loads plugins itself.
The marketplace manifest is a user-side file and is deliberately not part of this plugin. It
lives at ~/.agents/plugins/marketplace.json, and its path is resolved relative to $HOME,
not to the manifest and not as an absolute path:
{
"name": "superdesign-local",
"interface": { "displayName": "superdesign (local dev)" },
"plugins": [
{
"name": "treg",
"source": { "source": "local", "path": "./devs/superdesign/tools-registry-oss/plugin" },
"policy": { "installation": "AVAILABLE", "authentication": "ON_INSTALL" },
"category": "Developer Tools"
}
]
}
Then:
codex plugin list # treg@superdesign-local — not installed
codex plugin add treg@superdesign-local # the @marketplace suffix is REQUIRED
codex plugin list # installed, enabled, 0.7.1
Installed copies land in ~/.codex/plugins/cache/$MARKETPLACE/$PLUGIN/$VERSION/. Confirm the skill
actually loaded — it should appear as treg:tools-registry:
codex exec --skip-git-repo-check "List the names of every skill you have available."
codex plugin marketplace add ./plugin does not work: that command expects a marketplace root,
and this directory is a plugin.
The listing copy is the product
category and capabilities are not guesses — they are what OpenAI's own shipped plugins use
(github is Developer Tools + ["Interactive", "Write"]; gmail is Communication;
openai-templates is Productivity). The published docs show neither list, so read a real installed
manifest under ~/.codex/plugins/cache/ before inventing a value.
Before submitting through OpenAI's plugin portal, check the manifest version matches
pyproject.toml (a test enforces this), and that the copy still describes what treg does: it
compares providers and the agent chooses. treg does not route automatically and does not fail
over — the landing page had to be corrected for that claim once already, and a directory listing is
harder to correct than a web page. A test guards this too.