Plugins & Marketplaces

A plugin bundles skills, slash commands, and MCP servers into a single installable package. A marketplace is a catalog, hosted in a git repository or a local folder, that lists many plugins you can browse and install.

Posit Assistant adopts the same plugin.json + marketplace.json format used by Claude Code (and read by VS Code, Copilot, and OpenAI Codex), so a plugin repository authored for those tools generally installs in Posit Assistant too.

How it works

Installing a plugin has two parts:

1. Register a marketplace so the assistant knows where to look. A marketplace can be a GitHub repository (owner/repo), a full git URL (https:// or http://), or a local directory (an absolute path, a ~/-relative one, or a path relative to your project).
2. Install a plugin from that marketplace by name. Its skills and commands join the same menus as your built-in ones, and its MCP servers become available after you approve them (see Trust & consent).

Both steps happen in the plugin manager. Registrations and enablement are recorded in a settings file under Claude Code-compatible keys — your own or the project’s, as you choose (see Scope) — while the downloaded content is always kept per-user in ~/.posit/assistant/plugins/ and shared across every surface you run Posit Assistant on.

The plugin manager

Everything plugin-related happens in the plugin & marketplace manager, which is available on every surface: the web and desktop app, the TUI, RStudio, and Positron.

How you open it depends on where you are running Posit Assistant.

• In the web, desktop, RStudio, and Positron apps, open the header More menu (the ⋯ button) and choose Plugins, or run /plugin. In Positron the manager opens as a native editor tab; elsewhere it opens as a dialog.
• In the terminal (TUI), press Ctrl+G or run /plugin. Use the arrow keys to move between tabs and rows; the footer lists the keys for the current tab.

The manager has three tabs:

• Installed — the plugins you have, with enable/disable, update, and uninstall controls. Uninstalling offers to keep the plugin’s stored data.
• Browse — plugins available from your registered marketplaces, with a search box and an Install button per entry.
• Marketplaces — the marketplaces you have registered, with an input to add one, a Check for updates action per marketplace, and a Check all to refresh every catalog.

Plugins are referenced as <plugin>@<marketplace>, for example data-tools@acme. Marketplace names are derived automatically for remote sources (a GitHub owner/repo becomes owner-repo) or taken from the marketplace’s own manifest.

Scope: global or project

When you install a plugin or add a marketplace, you choose where the declaration is recorded:

Scope	Written to	Use it for
Global	~/.posit/assistant/settings.json	Plugins you want everywhere, on every project. This is the default. Every Posit Assistant surface reads this file, so a plugin you install in the terminal is active in Positron too, and vice versa.
Project	<repo>/.posit/assistant/settings.json	Plugins a repository needs, so they can be committed and shared with your team.

Pick the scope before installing: the manager shows an Install to (or Add to) control on the Browse and Marketplaces tabs. In the TUI, press s to switch it.

Only the declaration is scoped. Downloaded plugin content and marketplace clones always live per-user under ~/.posit/assistant/plugins/, so a project-scoped plugin is not re-downloaded for each repository that declares it, and switching scope never moves anything on disk.

Because that content is shared, uninstalling removes the declaration from the scope you uninstalled it in and only deletes the downloaded files once nothing else declares the plugin. If another project still uses it, the uninstall says so and leaves the files in place. Removing a marketplace works the same way.

Updates

Posit Assistant does not update plugins on its own — updating is always something you ask for.

An update becomes visible after you refresh the marketplace catalog it came from. Use Check for updates on a marketplace (or Check all), and the Marketplaces tab records when each catalog was last checked. If a refreshed catalog offers a newer version than what you have installed, the plugin’s row on the Installed tab shows v1.2.0 → v1.3.0, and its Update button fetches the new version.

Version comparison uses the version the marketplace catalog declares. A plugin whose version is recorded only inside its own plugin.json shows no indicator rather than a guess — you can still update it at any time.

Trust & consent

Plugins run under the same permission and trust model as the rest of Posit Assistant; there is no separate plugin sandbox. A few extra gates apply specifically to plugins:

• Skills and commands contributed by a plugin are namespaced (plugin-name:skill, invoked /plugin-name:skill) so they never collide with your own skills of the same name.
• Plugin MCP servers are disabled by default and start only after you consent by installing or enabling the plugin. That consent is bound to the server’s exact configuration: if an update changes what a server runs or how it authenticates, the server stays down until you re-approve it by re-enabling the plugin in the manager.
• Environment variables referenced by a plugin’s MCP config ({env:VAR}) resolve only against the values you approved for that server.
• A plugin MCP server does not inherit your environment. It starts with only the variables a launcher needs (PATH, HOME, locale, npm/Node settings, proxy settings), plus whatever its own config declares — so your provider API keys and cloud credentials are not visible to it. Your own MCP servers in settings.json are unaffected and still inherit the full environment.

A plugin MCP server that needs to sign in is listed with every other MCP server in the Session panel, where you can sign in to it — see MCP Servers. See Permissions & Trust for how the runtime permission system gates tool calls.

Marketplace sources

When registering a marketplace, these source types are supported:

Source	Example
GitHub owner/repo	acme/plugins
Full git URL (HTTPS)	https://github.com/acme/plugins.git
Full git URL (HTTP)	http://ppm.example.com:4242/agent-plugins/latest/marketplace.git
Local path	~/dev/my-marketplace

Plain http:// is supported for hosts that are not served over TLS — an on-premises Posit Package Manager marketplace, for instance. Credentials sent to such a host are not encrypted in transit, whether they come from a configured token or are embedded in the URL itself, so the assistant logs a warning the first time it sends them to that host; prefer https:// wherever the host offers it.

Enterprise administration

Administrators can lock down which marketplaces and component types are allowed by delivering plugins.strictKnownMarketplaces, plugins.blockedMarketplaces, and plugins.allowedComponents through POSIT_ASSISTANT_SETTINGS_ENFORCED. This is a non-overridable policy tier read from the launch environment, so a user cannot grant themselves access it hasn’t allowed, and it applies on every platform — Positron, RStudio, Standalone, Desktop, and the terminal.

Enforcement is applied at activation, so a blocklist added after a plugin was installed deactivates it. Pair an allowlist with extraKnownMarketplaces in the same payload to make the blessed marketplace appear in the manager; policy-declared marketplaces cannot be removed by the user. See the plugin keys reference for the key names and entry shapes, and the enforced-settings admin docs for how Workbench delivers the environment.

If you have written a lockdown in your own settings.json as well, the two combine rather than replace each other: a marketplace must satisfy both allowlists, a match on either denylist blocks it, and the two component ceilings intersect. Your own list can restrict further, never widen what the administrator allowed.