Overview

What a plugin adds

A plugin gives Filer one or more of: tools the folder agent can call (MCP tools), right-click AI actions on files and folders, hooks that run on app events, settings shown in Connect, and inbound channels — relays that bring messages in from outside the app, the way a Telegram bot does.

Most plugins ship a runtime: "node" handler: a JavaScript module that runs inside the app’s own plugin host process. A second mode, runtime: "process", exists for plugins that are their own executable instead of a module the host loads — see Process runtime.

Three layers

registry.json   (iyulab/filer-plugin-registry — the community list of plugin sources)
  └── plugin source   (a public GitHub repository with filer-plugins.json at its root)
        └── plugin    (a folder with filer-plugin.json, handlers, schemas)

Filer ships with the official source already registered, so its plugins are visible in Connect without any setup. Anyone can add any public GitHub repository as a source — the registry is a directory of known sources, not a gate you need to pass through to install or run a plugin. See Publish from your own repository and List in the registry.

What a plugin may touch

Everything a plugin can do is declared up front in its manifest’s permissions, and enforced by the context object (ctx) its handlers receive — calling a capability the manifest doesn’t declare throws a permission error that names the plugin and the capability. Paths passed as tool arguments are checked against the calling agent’s folder, so a plugin cannot read or write outside the folder the agent is scoped to. ctx.fetch refuses requests to localhost and private IP ranges.

A plugin also inherits the folder agent’s trust level for approval gating, and a folder’s settings can carry an allow-list that limits which installed plugins may run in it at all. See Permissions for the full model.

Next

• Your first plugin — build and install one tool
• Guides › Tools
• Reference › Manifest