Pluginstaller

# Pluginstaller

Use when the user gives a GitHub repo for a Codex plugin and wants it available in Codex.

Follow the current Codex plugin docs. Do not invent alternate install flows.

## Inputs

- GitHub repo URL or `owner/repo`
- Install scope: `repo` or `personal`
- If the repo contains more than one plugin root, ask which plugin folder to install.

## Workflow

0. If the user does not specify whether the plugin should be repo-scoped or personal, stop and ask.
1. Fetch the repo and locate the plugin root by finding `.codex-plugin/plugin.json`.
2. Read `.codex-plugin/plugin.json` and validate the canonical structure:
   - `name`, `version`, and `description` should exist.
   - Bundled paths such as `skills`, `apps`, and `mcpServers` should be relative to the plugin root and start with `./`.
   - Only `plugin.json` should live inside `.codex-plugin/`.
3. Prefer the built-in `@plugin-creator` skill when the task is to scaffold a new local plugin or add an existing local plugin to a marketplace. Use the manual path below when you are wiring up a repo the user already provided.
4. Copy the entire plugin directory, not just `SKILL.md`, into a marketplace-visible location. Default to the documented standard locations unless the repo already uses a different valid marketplace-relative path:
   - `repo`: `$CWD/plugins/<plugin-name>` and `$CWD/.agents/plugins/marketplace.json`
   - `personal`: `~/.codex/plugins/<plugin-name>` and `~/.agents/plugins/marketplace.json`
5. Preserve the full bundle at the plugin root, including sibling `skills/`, `.app.json`, `.mcp.json`, `assets/`, and any other plugin files. Do not move those files under `.codex-plugin/`.
6. Create or update the marketplace file with the documented schema:
   - top-level marketplace `name`
   - optional `interface.displayName`
   - plugin entry `name`
   - `source.source = "local"`
   - `source.path` relative to the marketplace root:
     - `repo`: `./plugins/<plugin-name>`
     - `personal`: `./.codex/plugins/<plugin-name>`
   - `policy.installation`
   - `policy.authentication`
   - `category`
7. Use marketplace values that match the docs unless the user says otherwise:
   - `policy.installation = "AVAILABLE"`
   - `policy.authentication = "ON_INSTALL"`
   - `category` from `interface.category` when present, otherwise `Productivity`
8. Merge into any existing marketplace file instead of replacing it.
9. Restart Codex and verify the plugin appears in `/plugins`.
10. Report the runtime behavior accurately:
   - The marketplace entry points to the source plugin directory.
   - Codex installs the plugin into `~/.codex/plugins/cache/<marketplace>/<plugin>/<version>/`.
   - For local plugins, the installed cache version is `local`.
   - Plugin enabled or disabled state is stored in `~/.codex/config.toml`.

## Rules

- Prefer the terms `repo marketplace` and `personal marketplace` over `workspace` and `global`.
- Do not present copying into `plugins/` as the complete install. The marketplace entry is what makes the plugin discoverable in Codex.
- Do not flatten or rename the plugin bundle.
- Keep the plugin `name` stable and consistent across folder, manifest, and marketplace entry.
- Keep manifest and marketplace paths relative and `./`-prefixed where the docs require it.
- Treat the documented repo and personal plugin directories as defaults, not absolute requirements, as long as the marketplace `source.path` remains valid and stays inside the marketplace root.
- If the repo already ships a marketplace file, prefer it as the source of truth for marketplace ordering and metadata, and only add or update the plugin entry that is needed.
- If the manifest is missing required basics or uses invalid root-relative paths, fix the plugin structure before claiming installation is complete.

## Scope guide

Use `repo` when the plugin should live with one repo or be shared through that repo's marketplace. Use `personal` when the plugin should be available from the user's own Codex setup across projects.