# patchcord — Agent Plugins 1.0.0 packaging

**Generated. Do not edit by hand** — run `node scripts/build-agent-plugin.mjs`.
This whole directory is deleted and rewritten on every build.

This is an EXPERIMENTAL second packaging of the same skills and the same MCP
server. It replaces nothing. `npx patchcord` and every per-harness config the
installer writes are untouched and keep working exactly as before.

## What is in here

| File | Read by | Purpose |
|---|---|---|
| `plugin.json` | Agent Plugins clients | The open-standard manifest. Required: `$schema`, `name`. |
| `mcp.json` | Agent Plugins clients | Standard MCP declaration. **Carries no credential — see below.** |
| `.codex-plugin/plugin.json` | Codex | Codex uses pointer fields (`skills`, `mcpServers`) instead of the spec's fixed locations. |
| `.mcp.json` | Codex | Codex MCP config, with the token read from an env var. |
| `skills/*/SKILL.md` | both | Copied from `../skills/`, with `name:` rewritten to the directory name. |

## The credential, and why `mcp.json` looks incomplete

Agent Plugins 1.0.0 expands `${PLUGIN_ROOT}` and `${PLUGIN_DATA}` only, and
only inside `args`, `env`, and `cwd`. `headers` is not in that list and there
is no host-environment passthrough anywhere in the spec.

So **the standard has no way to express "use this user's bearer token"**, and
patchcord is nothing but a per-project bearer token. Writing
`"Authorization": "Bearer ${PATCHCORD_TOKEN}"` into `mcp.json` would send that
literal string to the server. The file therefore names the endpoint and the
transport and stops, rather than looking complete and failing at runtime.

Clients close the gap with their own extensions, which is where the token
actually comes from:

- **Codex** — `bearer_token_env_var` in `.mcp.json`, pointing at
  `$PATCHCORD_TOKEN`.
- **VS Code** — `envFile` / `headers`, neither of which is in the core schema.

This is the one finding worth taking upstream: the portable core can carry the
server's identity everywhere, but not its credential.

## Trying it in Codex

The marketplace is already registered, so:

```bash
export PATCHCORD_TOKEN=<an agent bearer for the namespace you want>
codex plugin add patchcord-ap@patchcord-marketplace
```

Remove it with `codex plugin remove patchcord-ap@patchcord-marketplace`. The
existing `patchcord@patchcord-marketplace` entry is unaffected either way.

## Known limitation: one token per environment

`$PATCHCORD_TOKEN` is a single value per shell, while patchcord's model is one
namespace per project. A plugin installed this way is therefore **one identity
per environment**, not one per project — the same constraint that already
applies to Hermes, and the reason the current per-project installer writes
per-directory config instead. Do not use this packaging for multi-seat work
until the standard grows a per-project secret mechanism.