Choose your Ponytail install method
| Host | Primary mechanism | Important distinction |
|---|---|---|
| Claude Code | Marketplace plugin | Commands run inside Claude Code, not ordinary Claude web chat. |
| Codex | Marketplace plugin and lifecycle hooks | Review hook trust; skills use a plugin namespace. |
| Cursor hooks | Node installer and a retained checkout | User scope by default; project scope is an explicit option. |
| Cursor rules | Project rule file | A simpler rules-only alternative, without the complete plugin command suite. |
| Copilot CLI | Native plugin | Follow the official CLI guide. |
| Copilot in an editor | Repository instructions | Not equivalent to the CLI plugin or inline completion. |
Read the upstream portability documentation before transferring a capability from one row to another. A host's ability to read instructions does not establish that it supports the same lifecycle, skill discovery, or command syntax.
Check the environment and preserve existing rules
- Confirm the host you actually use, its version, and the operating system. Distinguish a command-line application from an editor extension or a desktop chat interface.
- Record existing plugin registrations, hooks,
AGENTS.md, and project rules. Back up any file you plan to edit, and check whether another Ponytail integration is already present. - Review the fixed-version installation source and the scripts the chosen path invokes. Hooks can run local code; an instruction file and an executable hook are different trust decisions.
- Use a small disposable project for the first check. Keep private code, credentials, and production resources out of the exercise.
- Choose user or project scope deliberately, and note how to reverse that exact scope.
Do not replace an existing instructions file wholesale. Merge the relevant guidance while keeping architecture, security, testing, and team requirements. If two instructions disagree, resolve the conflict explicitly rather than assuming a smaller-code preference overrides a project contract.
Our verification scope: isolated macOS checks covered Claude Code and Codex CLI installation management, Cursor project-hook configuration, rule-file integrity, and removal. They did not start authenticated agent conversations or execute the lifecycle hooks. New-session loading, level switching in a live host, and delivery of instructions to a model remain unverified by Ponytail Guide.
Follow one complete platform path
Claude Code
The marketplace is added and the plugin installed through separate commands inside Claude Code. The Claude Code guide covers activation, commands, Node availability, update, and removal. The ordinary Claude website does not become a plugin host when you paste these commands into a chat.
Codex
The Codex path uses terminal plugin commands followed by a review of two lifecycle hooks. Start a new chat after trusting the reviewed hooks; restart Desktop after installation. The Codex guide also explains the rules-only AGENTS.md fallback and why a marketplace refresh is not a completed plugin update.
Cursor
Choose the Cursor hooks or rules path. The hooks installer keeps a reference to a local checkout, so that directory must remain available. A project rule offers a different delivery mechanism; duplicating both paths is not a way to increase strength.
Copilot
Use the upstream Copilot CLI installation instructions or its documented editor-instructions route. We do not present the CLI plugin as an installation for every Copilot surface.
Verify loading and behavior separately
A successful installation message establishes only one part of setup. First check that the host lists the plugin, hook, or rule in the intended scope. Then begin a fresh conversation so the relevant lifecycle can run. Confirm that the host can discover the expected skill or command; do not use the mere presence of a file as proof that the agent read it.
For a behavior check, give the agent a small task with an existing reusable helper. Ask it to inspect the project, preserve the public interface, and explain the smallest complete change. Review the resulting plan and patch yourself. One reasonable answer does not prove that the instructions will always be followed, but it can expose a wrong scope or unloaded rule.
Next, switch a supported level and test the difference between a session choice and the next session's default. Record the host version, Ponytail reference, scope, observed result, and removal steps. See configuration and commands for the distinction.
Troubleshoot and recover without losing project configuration
If a command is missing, first check its host and integration type. Rules-only setups do not expose a plugin command suite. If hooks are present but silent, inspect trust settings, script paths, Node availability, and whether the current surface triggers the required lifecycle. If guidance is repeated, look for a duplicate rule or installation.
To remove a setup, use the platform guide for the same scope you installed. Restore only the Ponytail changes in a shared rules file. Turning a level off is a reversible behavior choice, not an uninstall. The upstream's broader state-cleanup script can affect shared defaults and other local integrations, so do not treat it as a host-specific removal shortcut.
Source verification in this guide is tied to the checked commit. Your local verification remains necessary after changing the host, upgrading the plugin, moving a checkout, or editing rules. For decision failures after a correct installation, continue to risk scenarios and overrides.
Maintained by the Ponytail Guide editorial team. Found an outdated command or a factual error? Send a correction. Do not include secrets or private code.