Skip to main content
Plugins are in closed beta. To request access, contact support@cognition.ai. Behavior and configuration may change in future releases.

​
What are plugins?

A plugin bundles skills — and optionally rules, hooks, MCP servers, and subagents — so it can be installed and reused as a unit. See the plugins reference for the file format and what a plugin can ship. Managed plugins let an admin install plugins centrally, from the Devin web app, so they apply to everyone in the org or enterprise — no per-user setup. This covers cloud Devin sessions and Devin CLI users logged into the account (enterprise/account-level config reaches the CLI too — see cloud sessions vs. the CLI). When a plugin is installed, its skills become available to Devin automatically as /<plugin>:<skill> commands. This page covers the web app side of plugins: managed manifests, scopes, and uploads.

​
Where to configure them

Go to Settings → Resources → Plugins. The page has two tabs:
  • Marketplace — browse plugins (the Devin official catalog plus any your org or enterprise has added) and install them. Installing a plugin adds it to the manifest of the chosen scope as a required plugin, so it’s installed for everyone in that scope.
  • Configuration — edit the raw plugin manifest as JSON, and upload your own plugin as a folder or .zip (or build one in the editor).
Access is permission-gated:
  • Org admins (organization settings access) manage the org manifest.
  • Enterprise admins (enterprise settings access) additionally manage the shared enterprise manifest.

​
The manifest

The manifest is a single JSON document with three lists:
  • requiredPlugins — installed for everyone in scope (recursively, including any plugins they depend on).
  • optionalPlugins — an allow-list that endorses plugins without auto-installing them; used to carve out exceptions to a forbidden entry.
  • forbiddenPlugins — a deny-list of plugin identities or glob patterns.
The manifest is stored verbatim; the agent validates the full source at install time. See the plugins reference for the source forms each entry can take and the full dependency and governance semantics.

​
Adding your own plugins

Depending on where the plugin lives, add it in one of these ways:

​
Uploading a plugin bundle

On the Configuration tab, the Uploaded plugin section lets you upload a plugin as a folder or .zip, or build one directly in the editor. Saving it adds it to the manifest as a required plugin (installing it for everyone in scope); deleting it removes the reference. This is a good option for a plugin you don’t want to (or can’t) host in a git repo.

​
Using a private skills repo

Point the manifest straight at the private repo — you generally don’t need to bake it into your environment snapshot. Any private repo Devin can already reach through your Git integration installs automatically. Use the git URL form, or git-subdir to install a plugin from a subfolder of a shared repo. (CLI users covered by the same manifest fetch with their own local git credentials, so they’ll need access to the repo too.) If the repo isn’t reachable through your Git integration, either upload it as a bundle (above) or clone it during environment setup and reference it with a local path.

​
How updates roll out

  • Manifest changes (Settings → Resources → Plugins) apply to the next session.
  • Plugin changes — merging to the branch a plugin tracks reaches new sessions automatically, within a few hours. Pin the plugin to a commit SHA to control updates yourself; on the CLI, devin plugins update refreshes immediately.
  • Running sessions keep what they loaded at start — updates never change a session mid-flight.

​
Scope and inheritance

Managed manifests exist at up to two levels:
  • Standalone accounts have a single account manifest that applies to everyone.
  • Enterprises have a shared enterprise manifest that is inherited by every child org, plus a per-org manifest layered below it. The Marketplace view shows both, and enterprise admins can choose to install a plugin at the enterprise scope (applies everywhere) or an org admin can install it at just their org.
These sit at the top of the overall plugin hierarchy, above repo- and user-level plugin config. See inheritance and levels for the other levels and the authority rules.

​
Cloud sessions vs. the CLI

Both cloud Devin sessions and the Devin CLI enforce the enterprise/account manifest — required plugins are installed and forbids are enforced for CLI users logged into the account too. The org manifest applies only to cloud sessions. The CLI authenticates at the account level and has no org context, so org-level requires and forbids don’t reach CLI users. Put anything you need enforced in the CLI (or account-wide) in the enterprise/account manifest, and use the org manifest for org-specific additions to cloud sessions.

​
Learn more

  • Skills — the SKILL.md procedures that plugins bundle
  • CLI plugins reference — plugin file format, authoring, and per-user install
  • Playbooks — reusable prompt templates attached to sessions