Devin plugins and the Customize page

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. Plugins are the shared customization layer across cloud Devin sessions, the Devin CLI, and Devin Desktop: install a plugin once and its skills become available as /<plugin>:<skill> commands wherever you use Devin. Plugins can be installed at three levels:

Scope	Who installs	Who gets it
Personal	You	Your own sessions — cloud, CLI, and Desktop, on every device you’re signed in to
Organization	Org admins	That organization’s cloud sessions, plus the CLI and Desktop for members whose primary organization it is
Enterprise	Enterprise admins	Everyone in every organization of the enterprise

This page covers the web app side: the Customize page, installing at each scope, indexing, MCPs, and the managed manifests behind it all.

The Customize page

Plugins live on the Customize page, reached from the Customize item in the sidebar (it replaced the older Settings → Plugins, Settings → Marketplace, and Settings → Connections → MCP servers pages; old links redirect). It has five tabs:

Plugins — everything installed, grouped by scope, plus Browse marketplace to install more.
Skills — the skills Devin loads on demand, from installed plugins and your repositories.
MCPs — the MCP servers that give Devin tools beyond its built-in ones. See MCPs below.
Hooks — commands that run automatically at points in a session.
Rules — standing guidance Devin follows in every session.

Use the scope tabs to choose Personal, Organization, or Enterprise, depending on your access. Each scope shows its effective content: what actually applies after governance. To change repository-level content (skills, rules, and plugins declared in a repo’s .devin/config.json), edit the repository’s files. Who can change what:

Personal — anyone, for their own scope.
Organization — members with organization settings access.
Enterprise — members with enterprise settings access.

Click any plugin to open its details sheet: its skills, MCPs, hooks, rules, and subagents; the tracked ref or pinned SHA and path; which scopes it’s installed in and what requires it; its permissions; and — where you have rights — actions to connect its MCPs, change what it requires, uninstall it, or (for an uploaded plugin) delete it.

Installing plugins

From the marketplace

Click Browse marketplace on the Plugins tab. The marketplace is one list combining the Devin official marketplace (CognitionAI/devin-marketplace, mostly one plugin per integration such as Linear, Notion, Datadog, or Snowflake) with any plugins your organization or enterprise has added. Each card offers an install menu with every scope you can write to, and shows where the plugin is already installed (“Installed for me”, “Installed at organization”, …). Before the first install of a plugin, Devin shows a security notice: installing lets Devin run the plugin’s rules, hooks, and skills (and, for a plugin with MCP servers, reach external data through them), so only proceed if you trust the plugin and have verified its source. Official marketplace plugins are marked as such. After installing, a toast confirms the scope and — if the plugin ships an MCP server that needs credentials or authorization — offers Connect MCP to finish setup right away. Enterprise admins can hide the official marketplace for every org (Show official marketplace plugins switch), and can control which marketplace MCP servers organizations see under Marketplace availability.

From a repository, a `.zip`, or the editor

The Add plugin menu on the Plugins tab supports three more sources, each installable at any scope you can write to:

Where it lives	How to add it
Git repo (public or private)	From repository — enter `owner/repo` or a git URL, plus a subdirectory when the plugin lives in a subfolder. Any private repo Devin can reach through your Git integration works.
Not in a repo	Upload .zip — an uploaded plugin bundle is stored with the scope and installed for everyone in it.
Doesn’t exist yet	Create plugin — a file editor with Preview/Source tabs and Version history (every save is a restorable version).

Uploaded and created plugins can be edited later from their details sheet. Deleting one removes its files permanently — they have no other copy. Don’t put secrets in plugin files; use secret references instead.

From the CLI

devin plugins install <source> adds the plugin to your personal scope by default, so it follows you to cloud sessions and your other devices. Pass --local to install on the current machine only. See the CLI commands.

Letting Devin do it

In a cloud session you can ask Devin to save something as a personal skill, rule, hook, or MCP server, or to install a plugin for you. Devin proposes the change as a card you approve or deny; approved changes go to your personal scope and apply to future sessions.

How plugins reach sessions (cloud ↔ local sync)

Every scope is backed by a managed manifest stored in Devin Cloud (see The manifest). Installing anywhere writes that manifest, and every surface reads it:

Cloud sessions fetch the enterprise, organization, and personal manifests at start and install the resulting plugins on the session machine, alongside plugins declared by the repositories they clone.
The Devin CLI and Devin Desktop fetch the same manifests when you’re signed in, so a plugin you install on the web appears on your laptop, and devin plugins install on your laptop appears in your next cloud session. Plugins from private repos are fetched with your local git credentials, so you need access to the repo yourself. An enterprise can turn off CLI plugins entirely (Devin CLI plugins in enterprise settings).
Solo users (no organization) have only a personal scope.

Running sessions keep what they loaded at start; changes apply to the next session. Plugin installation and MCP authentication are separate steps. Connect cloud MCPs from Customize → MCPs; for a plugin’s OAuth server running in the CLI, use devin mcp login. Syncing a plugin does not mean every device shares the same credentials.

Indexing

Devin keeps an index of every scope’s plugins: it clones each plugin source, reads its manifest and contents, resolves dependencies, and applies governance. The Customize page shows the index result — the plugins, their skills, MCPs, hooks, and rules, and anything blocked by policy — and the status line reports when each scope was last indexed.

What triggers it — installing, removing, or editing a plugin queues a reindex automatically. Use Plugin settings → Reindex plugins to refresh the index after pushing changes to a plugin’s source repository.
While it runs — a run can be scheduled, queued, starting, or indexing. Frequent reindexes are spaced out, and uploaded-bundle saves can take a short time to queue. Plugin MCPs can be connected once their configuration has been indexed.
Results — open Plugin settings (the gear menu) to see the last indexed time and any issues. A failed refresh can leave the last successful result visible; the presence of a plugin in the list doesn’t prove the latest refresh succeeded.
Repository access — plugin content indexed from a repository is only shown in an organization that has access to that repository through its Git integration. If it doesn’t, the scope’s content is withheld with a Plugin repos unauthorized notice; grant the repository on Settings → Repositories. Governance from a withheld scope (its forbids) still applies.
Network policy — indexing runs on a machine that inherits your organization’s session network policy, so plugin sources must be reachable under it.

Sessions themselves don’t wait for the index: they fetch and install plugins directly at start.

Resolve indexing issues

Open Customize → Plugins in the organization where you need the plugin. Select its Personal, Organization, or Enterprise scope, then open Plugin settings to read the issue and the plugin or scope it names.
If a run is scheduled, queued, starting, or indexing, let it finish. If the plugin has never been indexed, or its source changed since the last index, choose Reindex plugins.
For a failed run or missing content, use the matching fix below. Save or commit the correction, then choose Reindex plugins and check the result again. Changes to a shared manifest or repository permissions may require an admin.

Message or symptom	What to do
Plugin repos unauthorized	Ask an admin to grant the affected organization access to every repository named in the issue from Settings → Repositories. An enterprise plugin may need repository access granted to several organizations. Adding the plugin to a manifest does not grant repository access.
Plugin source could not be cloned or Repository unavailable	Check the repository URL, branch or tag, and pinned commit. Confirm the organization has permission to read the repository, even if it already appears in the repository list. Check the network policy if the Git host cannot be reached. Reindex after fixing access or the source reference.
No plugin manifest found	Check that the source points to the plugin directory. A plugin in a subfolder needs that subdirectory in its source reference. Include a supported manifest at the expected location.
Plugin manifest malformed, Skill malformed, MCP config malformed, or another malformed asset	Open the issue’s Learn more link for the relevant format. Fix the named file in the source repository or uploaded plugin editor. Check manifest fields, skill frontmatter, MCP configuration, and paths relative to the plugin root.
Conflicting version pins	Inspect the manifests requiring the plugin. Align their `sha` values, or let the higher-authority scope supply the pin. See conflicts and dependencies. Reindexing alone cannot resolve contradictory pins.
Plugin source not pinned	This is an advisory, not an indexing failure. The plugin follows a branch or tag. Pin it to a commit if you need a fixed version.
Could not load plugin contents or Indexed content unavailable	Choose Reindex plugins to rebuild the indexed content. If the page instead says Couldn’t load your configuration, use Try again to retry loading it.
Installed but blocked	Read which scope forbids the plugin and ask the policy owner to review it. A lower scope cannot override that policy; see Governance.

After indexing succeeds, open the plugin’s details and confirm the expected skills, rules, hooks, or MCPs appear. If an MCP still needs authorization, finish connecting it. To use changed plugin content, start a new session. For a stale CLI install, use devin plugins update; a Customize reindex refreshes the web listing. An install made with --local stays on that device. If indexing keeps failing, or a run stays queued or indexing without progressing, contact support. Include the organization and scope, plugin source and ref, last indexed time, exact error, and a screenshot of the issue.

MCPs

MCP servers are managed on the MCPs tab of Customize, for the same three scopes. The tab has two kinds of entries:

From plugins — MCP servers declared by an installed plugin. The plugin owns the connection settings (URL, transport, required credentials), shown read-only; you can still enable, disable, connect, or uninstall it. Most official marketplace plugins are a single MCP server plus, optionally, skills.
Standalone — MCP servers installed on their own: custom servers (Add custom MCP) and servers installed from the legacy MCP marketplace, which is still reachable from the tab.

Connecting. A plugin MCP that needs an API key opens a Connect sheet with its secrets ready to fill in; one that uses OAuth opens the provider’s authorization flow; one that needs neither is ready as soon as the plugin is installed. Connect from the install toast, from the plugin’s details sheet, or from the MCP’s row. Shared vs. per-member connections. For an OAuth MCP installed at the organization or enterprise scope, the server’s Access setting decides how the connection is shared: Organization access is one shared connection for everyone in the scope — use a service account, not a personal login — while Personal access has each member authorize their own account. For servers without per-member access, install the plugin (or the MCP) at the personal scope when each member needs their own credentials. If members are connecting the same marketplace MCP one at a time, an admin can install it once for the organization and plugins that declare it will use that connection. Enterprise MCPs. Enterprise admins configure a server once — including a private-CA certificate bundle for MCP traffic routed through the customer network — and choose which organizations get it. An organization’s own installation of the same server overrides the enterprise one. For transport types, custom-server fields, and per-server setup notes, see MCP servers.

The manifest

Behind each scope is a managed manifest — a JSON document with three lists. The Customize UI edits it for you; Plugin settings (gear) → Edit manifest on the Plugins tab exposes it directly:

{
  "requiredPlugins": ["acme/review-tools"],
  "optionalPlugins": [],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*"]
}

requiredPlugins — installed for everyone in scope (recursively, including any plugins they depend on). Installing from the UI adds an entry here.
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.

Governance

The three lists are the policy language at every level — enterprise, organization, repository (.devin/config.json), and personal — and higher authority wins: an enterprise can require a plugin no organization, repo, or user can remove, and forbid one no lower level can bring back. A plugin blocked by policy shows under Installed but blocked on the Plugins tab, and its skills are skipped at session start with a warning naming the forbidder. To lock an enterprise down to an approved set, forbid "*" and list the approved plugins (and their dependencies) in requiredPlugins/optionalPlugins; see Set up your plugin ecosystem for a worked example and inheritance and levels for the complete rules.

Scope and inheritance

Standalone accounts have an account manifest (labelled Organization in Customize) plus each member’s personal manifest.
Enterprises have an enterprise manifest inherited by every child organization, a per-organization manifest layered below it, and personal manifests below that.

How updates roll out

Manifest changes (installs, removals, manifest edits) apply to the next session, on every surface.
Plugin content changes — merging to the branch a plugin tracks reaches new sessions automatically (cloud sessions fetch at start; the CLI refreshes on devin plugins update). Customize shows the new content after the next index run — click Reindex plugins to pull it immediately.
Running sessions keep what they loaded at start — updates never change a session mid-flight.

Pinning a plugin

A plugin written as "owner/repo" (or with a ref) follows a branch or tag, so the same manifest can resolve to different content over time. Customize flags such entries as Plugin source not pinned. To lock a plugin to exact content, use the object form with a sha:

{
  "requiredPlugins": [
    { "source": "github", "repo": "acme/review-tools", "sha": "3f2a9c1d8e4b7a6f5c0d1e2f3a4b5c6d7e8f9a0b" }
  ]
}

A pinned plugin never changes until you edit the SHA. ref (a branch or tag) and sha are mutually exclusive — an entry can’t set both. The same fields work with the url and git-subdir source forms. Uploaded plugins are always pinned to the content you uploaded. If two scopes pin the same plugin to different SHAs, the index reports a pin conflict.

Plugin environment variables

Add env to a requiredPlugins or optionalPlugins entry to configure command hooks in cloud sessions. Reference Devin Secrets for credentials; other values can be literal strings.

{
  "requiredPlugins": [
    {
      "source": "github",
      "repo": "acme/review-tools",
      "env": {
        "API_KEY": "secret:org:REVIEW_API_KEY",
        "REVIEW_MODE": "strict"
      }
    }
  ]
}

Start a new cloud session to apply changes. Dependencies need their own manifest entry and env.

Supported references

secret:org:NAME
secret:enterprise:NAME
secret:personal:NAME
secret:session:NAME
secret:repo:owner/repo:NAME

The secret must be available to the session. For an existing key-value secret, append /ENTRY, for example secret:org:AWS_CREDS/ACCESS_KEY_ID. Plugin MCP configs reference secrets as ${NAME}; members supply the values from the server’s details sheet, and any literal value written into the config is stripped.

Learn more

Plugins reference — plugin file format, manifest, governance semantics, CLI commands
Set up your plugin ecosystem — build and govern your own plugin repo
Quickstart: team marketplace — from zero to a shared plugin repo
Skills — the SKILL.md procedures that plugins bundle
MCP servers — transports, custom servers, per-server setup

Get Started

Essential Guidelines

Onboarding Devin

Working with Devin

Product Guides

Integrations

Admin

Release Notes

Devin plugins and the Customize page

What are plugins?

The Customize page

Installing plugins

From the marketplace

From a repository, a `.zip`, or the editor

From the CLI

Letting Devin do it

How plugins reach sessions (cloud ↔ local sync)

Indexing

Resolve indexing issues

MCPs

The manifest

Governance

Scope and inheritance

How updates roll out

Pinning a plugin

Plugin environment variables

Supported references

Learn more

​What are plugins?

​The Customize page

​Installing plugins

​From the marketplace

​From a repository, a .zip, or the editor

​From the CLI

​Letting Devin do it

​How plugins reach sessions (cloud ↔ local sync)

​Indexing

​Resolve indexing issues

​MCPs

​The manifest

​Governance

​Scope and inheritance

​How updates roll out

​Pinning a plugin

​Plugin environment variables

​Supported references

​Learn more

What are plugins?

The Customize page

Installing plugins

From the marketplace

From a repository, a `.zip`, or the editor

From the CLI

Letting Devin do it

How plugins reach sessions (cloud ↔ local sync)

Indexing

Resolve indexing issues

MCPs

The manifest

Governance

Scope and inheritance

How updates roll out

Pinning a plugin

Plugin environment variables

Supported references

Learn more