[Feature]: Extension management makes no sense

[ak47]

Problem Statement

Looking to explore and try some extensions and discovering the extension management feature makes no sense.

It's as if you're actively trying to prevent and dissuade people from using extensions.

First, you have a "default" catalog but there is no obvious way to know what is in this "default" catalog except (apparently) looking into the JSON file in the code. Is this "default" catalog even something I would care about? It sounds like an official approved list of extensions, but maybe it's just the extensions that are already built in? No idea and no obvious way of learning what this even is.

Then I discover there is a "community" catalog. Ok, how do I get at that?

So I can list the catalogs, but to add a catalog for any usage I need to run a command that requires the URL and the name - both of which you just told me when I listed the catalogs - so I have to regurgitate back to you what you just told me? Why? Why not just accept the name "community".

Then it gets more bizarre because adding a catalog doesn't mean I can add an extension I need to explicitly allow installation. But I didn't know that so I try to add again with the "install-allowed" option but then it errors because it's already there. So... I have to remove it and re-add it? Who came up with this completely non-intuitive design?

I just don't get it. Why not make is simple and intuitive? Why not have sensible commands with options that make it easy to work with? What is the goal here?

Proposed Solution

Make extension management clear and intuitive to understand.

Alternatives Considered

No response

Component

Other

AI Agent (if applicable)

None

Use Cases

No response

Acceptance Criteria

No response

Additional Context

No response

[mnriem]

Thanks for the detailed writeup, @ak47 — the frustration is fair, and some of these are genuine gaps we should close. But a few things are working as designed, and the design is deliberate, so let me lay out the model clearly.

The two built-in catalogs have different jobs on purpose:

• default — the official, vetted catalog. Install-allowed.
• community — a discovery-only surface. Intentionally not installable, and already active for search out of the box (you don't need to add it).

community is discovery-only as a security boundary, not an oversight. It's an open, unvetted list; making everything in it one-command-installable would mean pulling arbitrary third-party code with no review. A discovery-only catalog should stay discovery-only — you should never flip it to install_allowed. That's the whole point.

So how do you actually install something you found in community? Two supported paths, neither of which involves loosening the community catalog:

1. Just install the one you vetted directly: specify extension add <name> --from <url>. No catalog authoring, no flags to flip — you point at the specific extension you've reviewed and install it.
2. Curate your own catalog (for an org / a set you maintain): host a catalog you control with install_allowed: true for entries you've vetted. This is for "I want a governed, reusable install source," not for turning community into one.

Where you're absolutely right, and what we'll fix:

1. None of this is explained. Neither docs/reference/extensions.md nor --help says why community is discovery-only, or that --from is the lightweight install path. The docs cover mechanics but not intent.
2. Worse, our own error text ("add to an approved catalog with install_allowed: true") reads like an invitation to flip the community catalog — exactly the wrong move. That's a messaging bug on us, and it's most of what sent you down this path.

Concretely, we'll:

• Document the trust model explicitly: discovery-only vs. vetted, --from for one-off installs, and self-curated catalogs for governed sources.
• Rewrite the install/search/error messaging so it points at --from and your own catalog — never at making community installable.
• Surface the "why" in --help, not just the docs.

To be direct on the one point: we won't make community directly installable, and the fix is not a switch to flip it. Keeping discovery separate from install is the security model. What we owe you is making that obvious and making the correct path (--from, own catalog) easy to find.

Appreciate you pushing on this — it surfaced real rough edges in how we communicate the model.

---

Posted by GitHub Copilot (model: Claude Opus 4.8) on behalf of the maintainer.