> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Devin plugins and the Customize page

> Install Devin plugins from Customize, resolve indexing issues, connect MCP servers, and manage personal, organization, and enterprise scopes.

## 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](/cli/extensibility/plugins/overview) for the file format and what a plugin can ship.

Plugins are the shared customization layer across **cloud Devin sessions**, the [**Devin CLI**](/cli/index), 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**](https://app.devin.ai/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](#mcps) below.
* **Hooks** — commands that run automatically at points in a session. See [Hooks](#hooks) below.
* **Rules** — standing guidance for sessions in scope. See [Rules](#rules) below.

The page also has a **Memory** tab for the personal notes Devin keeps about working with you. See [Memory](/product-guides/memory).

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](https://github.com/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. A repo with only `skills/<name>/SKILL.md` and no manifest (the [skills.sh](https://skills.sh) layout) installs as a skills-only plugin named after the repo. |
| **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](#plugin-environment-variables) 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](/cli/extensibility/plugins/overview#installing-a-plugin).

### 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](#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](#mcps); for a plugin's OAuth server running in the CLI, use [`devin mcp login`](/cli/extensibility/mcp/configuration#troubleshooting). 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](/product-guides/security-profiles), 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

1. Open [Customize → Plugins](https://app.devin.ai/customize) 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.
2. 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**.
3. 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](https://app.devin.ai/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](/product-guides/security-profiles) 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](/cli/extensibility/plugins/overview#compatible-formats) at the expected location, or at least one skill at `skills/<name>/SKILL.md`. |
| **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](/cli/extensibility/plugins/overview#manifest), [skill frontmatter](/cli/extensibility/skills/creating-skills#frontmatter-reference), [MCP configuration](/cli/extensibility/plugins/overview#mcp-servers), 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](/cli/extensibility/plugins/overview#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](#pinning-a-plugin) 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](#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](#mcps). To use changed plugin content, start a new session. For a stale CLI install, use [`devin plugins update`](/cli/extensibility/plugins/overview#managing-plugins); 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](/work-with-devin/mcp).

## Hooks

Hooks are commands Devin runs at points in a session, such as before or after a tool call. **New hook** on the Hooks tab edits the scope's `hooks.json`; changes apply to new sessions. Pass credentials through [plugin environment variables](#plugin-environment-variables), not the hook itself. Hooks are best effort: one that fails doesn't stop the session.

For the file format, see the [hooks reference](/cli/extensibility/hooks/overview).

## Rules

Rules are standing guidance for sessions in scope, like team conventions. **New rule** on the Rules tab adds a Markdown file to the scope's `rules/`. Devin automatically includes up to 16 KiB from the beginning of each always-on rule file in its context; see the [AGENTS.md guidance](/onboard-devin/agents-md) for details. Keep always-on rules short, and prefer [skills](/product-guides/skills) for anything that only matters sometimes.

For the file format and `trigger` options, see the [rules reference](/cli/extensibility/rules).

## 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:

```jsonc theme={null}
{
  "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.

### Uploaded plugins

An uploaded plugin is referenced by its bundle ID, and its files belong to the scope it was uploaded to. A reference without `bundleScope` resolves against the files of the manifest that lists it:

```json theme={null}
{ "requiredPlugins": [{ "source": "account-upload", "bundleId": "bugzilla" }] }
```

To install an **enterprise** upload into an organization (or a personal scope), list it in that scope's `requiredPlugins` with `"bundleScope": "account"`, so it resolves against the enterprise's files:

```json theme={null}
{ "requiredPlugins": [{ "source": "account-upload", "bundleId": "bugzilla", "bundleScope": "account" }] }
```

Where an enterprise upload is listed decides who gets it:

* **Enterprise `requiredPlugins`** — installed in every organization.
* **Enterprise `optionalPlugins`** — shown under **Suggested** in each organization, where an admin can install it. From the enterprise plugin's details sheet, **Required organizations** installs it into the organizations you select.

Organization and personal uploads can't be offered to other scopes.

The manifest is stored verbatim; the agent validates the full source at install time. See the plugins reference for the [source forms](/cli/extensibility/plugins/overview#manifest) each entry can take and the full [dependency and governance semantics](/cli/extensibility/plugins/overview#dependencies).

## 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](/product-guides/plugin-ecosystem#6-govern) for a worked example and [inheritance and levels](/cli/extensibility/plugins/overview#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`:

```json theme={null}
{
  "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](/cli/extensibility/plugins/overview#dependencies). 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](#hooks) in cloud sessions. Reference [Devin Secrets](/product-guides/secrets) for credentials; other values can be literal strings.

```json theme={null}
{
  "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

```text theme={null}
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](/cli/extensibility/plugins/overview) — plugin file format, manifest, governance semantics, CLI commands
* [Set up your plugin ecosystem](/product-guides/plugin-ecosystem) — build and govern your own plugin repo
* [Quickstart: team marketplace](/cli/extensibility/plugins/quickstart) — from zero to a shared plugin repo
* [Skills](/product-guides/skills) — the `SKILL.md` procedures that plugins bundle
* [MCP servers](/work-with-devin/mcp) — transports, custom servers, per-server setup


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.