POC: offer to install first-party extensions on first use

[tedkahwaji]

Why

Proof of concept for making first-party extensions discoverable without a separate install step. Today an agent or user has to know to run pup extension install <owner/repo> before pup setup (for example, a setup extension wrapping the public @datadog/ai-setup-cli package) does anything. Without that, pup setup fails as an unknown subcommand.

This POC keeps the extension's code, release cadence and CI outside pup core, but makes the first run feel built in.

What

• New src/extensions/first_party.rs with a small allowlist. It has one entry, setup -> DataDog/pup-setup, which is a placeholder: that repository and release don't exist yet.
• In the existing extension dispatch in main.rs, if the candidate is neither built-in nor installed but is on the allowlist, pup offers to install it using the existing install_from_github path, then dispatches as usual.
• Behavior by mode:

Mode	Behavior
Interactive terminal	Install it now? [y/N]. Declining falls through to today's unknown-command error
--yes or agent mode	One-line notice on stderr, install, run
Non-interactive without --yes	Error naming the pup extension install command
--read-only	Refuses to install

• Test hook, debug builds only: PUP_DEV_FIRST_PARTY_LOCAL_SOURCE=<file> installs from a local file instead of GitHub, so the flow can be exercised before a release exists. It's compiled out of release builds via cfg!(debug_assertions).
• Docs: new "First-Party Extensions" section in docs/EXTENSIONS.md.

Testing

cargo test --bin pup first_party: 7 passed. Covers the allowlist lookup (known, unknown, wrong case, empty) and every decision branch.

cargo test --bin pup extensions: 123 passed. cargo clippy -- -D warnings and cargo fmt --check are clean.

Smoke tests ran against ./target/debug/pup with an empty PUP_CONFIG_DIR, in a clean environment so agent-mode autodetection stays off.

Non-interactive, no --yes:

$ pup setup --help </dev/null
Error: 'setup' is a first-party pup extension that is not installed. Install it with `pup extension install DataDog/pup-setup`, or rerun with --yes.

Read-only plus agent mode:

$ pup --agent --read-only setup --help
Error: 'setup' is a first-party pup extension that is not installed, and installing extensions is blocked in read-only mode. Run `pup extension install DataDog/pup-setup` without --read-only first.

Interactive, user declines:

'setup' is a first-party pup extension from DataDog/pup-setup. Install it now? [y/N]: n
error: unrecognized subcommand 'setup'

Interactive, user accepts (debug local source, stub extension):

'setup' is a first-party pup extension from DataDog/pup-setup. Install it now? [y/N]: y
stub pup-setup invoked with: --product apm

Agent mode (debug local source), then a second run dispatching directly to the now-installed extension:

$ pup --agent setup --product apm
pup: 'setup' is not installed; installing first-party extension from DataDog/pup-setup
stub pup-setup invoked with: --product apm
DD_SITE=datadoghq.com PUP_AGENT_MODE=true token_set=yes

--yes against the placeholder GitHub source fails cleanly with the existing "no releases found for DataDog/pup-setup" error.

Open questions

• Where should first-party extensions be released from, and who owns that repository?
• Should agent mode really auto-install? The alternative is to always require --yes. Agents usually pass --yes, but autodetected agent mode also implies auto-approve today, which is why the smoke tests needed a clean environment.
• Downloaded extensions aren't signed. Should first-party auto-install require a checksums.txt (optional today) or a signature before running?
• Should the allowlist live in code, as here, or come from a signed remote index so new first-party extensions don't need a pup release?
• pup --agent setup --help still prints pup's schema rather than the extension's help (an existing limitation).

🤖 Generated with Claude Code