Install Claude Code plugins

Localix reads a Claude Code plugin in place: .claude-plugin/plugin.json and its component folders load as they are, with no conversion, and the same folder keeps working in Claude Code. Use this page to install one and to see which Claude Code features run in Localix. Localix's own plugins are in the Localix marketplace.

What you can do

A Claude Code marketplace is a repository, folder or hosted file whose catalog is .claude-plugin/marketplace.json. /plugin marketplace list <name> shows its plugins, /plugin marketplace update <name> refreshes it and updates what was installed from it (naming any plugin it leaves for you to update), /plugin marketplace update with no name refreshes every listing and leaves installed plugins at their versions, and /plugin marketplace remove <name> removes it with the plugins installed from it.

/plugin install leaves a plugin whose manifest or marketplace entry sets defaultEnabled: false off until you enable it, and names the dependencies it installed. /plugin disable refuses while another enabled plugin depends on the one named, and /plugin enable or /plugin disable on a plugin already in that state says so. Removing a plugin from the last place it is installed also deletes its ${CLAUDE_PLUGIN_DATA} folder and its vault-held settings. /plugin validate <path> validates a folder that is not installed and ends with Claude Code's verdict line.

A user-scope plugin has one configuration in every project, as Claude Code's pluginConfigs does. A sensitive userConfig value is stored in the vault, encrypted and bound to the plugin; the plugin's settings keep only a reference, and the value reaches its hooks (also as CLAUDE_PLUGIN_OPTION_<KEY>) and its MCP servers' ${user_config.KEY} when they run.

Localix ships no plugin. It registers the Store's default marketplaces on first start, localix (the Localix marketplace), Anthropic's official and its community one, for browsing; every other plugin comes from a source you add. Manage them in the Store (Plugins) or with /plugin. A plugin runs no Localix native code. Screens, a backend and agent tools over Localix's APIs are a mini app's, a separate format with its own folder, settings and command; see Build a mini app.

How it works

Discovery reads the manifest and component folders with Claude Code's rules. A folder without a manifest is a plugin named after the folder when it has a component folder such as skills/ or commands/. the Store (Plugins) lists it and skips authoring reminders such as a missing license. A root plugin.json is not read, as in Claude Code, and a folder holding a .localix-mini-app/mini-app.json is a mini app: it loads nothing as a plugin.

Boundary: in a remote MCP server's url and headers, a variable whose name looks like a credential (TOKEN, SECRET, API_KEY, PASSWORD, …) reads as empty unless the plugin's settings supply it; a stdio server inherits the environment anyway.

Hook events

Every Claude Code hook event runs at its Localix point, with Claude Code's input fields and decisions. Where Localix's moment differs, the table says where it fires. See Hooks and commands.

Three events have no Localix moment and never fire; validation says why. Setup runs only for Claude Code's --init and --maintenance flags. DirectoryAdded needs /add-dir, and a Localix session has one folder. WorktreeRemove fires for worktree sessions, which Localix does not run; like Claude Code, it keeps a workflow agent's hook-made worktree. Between-turn events (a model switch, a project move, a file change) fire the hooks the conversation's latest turn assembled.

A tool call reaches a hook under Claude Code's name and in Claude Code's shape; see Hook tool calls.

transcript_path names the conversation as a JSONL file in Claude Code's transcript format, one user or assistant entry per line with Claude Code's tool names, so hooks such as ralph-loop and hookify's stop rules read it as they do in Claude Code. A SubagentStop hook's agent_transcript_path is the delegated task's own file, under subagents/ beside it. Localix keeps the conversation in its database and rewrites these files from it before a hook that can read them runs; they live in the session's data folder and go with the session.

Marketplaces and updates

Localix registers the Store's default marketplaces on first start, and updates plugins installed from marketplaces by Claude Code's version rule, on its own for marketplaces with auto-update on. See Plugin marketplaces and updates.

Earlier installs

Versions before this one converted a Claude Code plugin at install and wrote a root plugin.json beside it. That file is now ignored, and the .claude-plugin/ manifest is read. Plugins installed into the Default project's folder (~/.localix/workspace/.localix/plugins), which its chats never saw, still move to ~/.localix/plugins once at startup, with their saved state. A plugin of the same name already there keeps both copies where they are, and the log says so. The copies of the first-party mini apps that earlier versions kept in ~/.localix/plugins are removed at startup; mini apps now live in ~/.localix/mini-apps. A user-scope copy an earlier version installed from a marketplace into ~/.localix/plugins/<name> keeps working, and its next update moves it into the version cache.

Marketplaces

A marketplace entry names where its plugin comes from, and Localix fetches it as Claude Code does.

An npm package may carry its version (@org/formatter@2.0.0) or be an https link to the tarball; a link on github.com, gitlab.com (outside its npm registry API), bitbucket.org or git.sr.ht is refused. A registry your ~/.npmrc holds an _authToken for receives it. An archive download gets the entry's headers and, on the catalog's own origin, the headers of a url marketplace source; an entry headersHelper runs only once you accept it (see Accept a headersHelper command). A relative entry path must start with ./ (a bare name only under metadata.pluginRoot) and use /, and a catalog needs an owner, as in Claude Code.

An archive must hold the plugin at its top or one folder down (a __MACOSX folder beside it is ignored). It is refused whole, with nothing written, when an entry would land outside the plugin, when a link points outside it or another entry is written through a link, when an entry repeats a path or inflates past the size it declares, and when the download is too large or its host is a loopback, link-local or cloud-metadata address.

/plugin install <name>@<marketplace> and /plugin update read the marketplace again first, unless it was refreshed in the last 30 seconds or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set; when that fails, the install goes on from the cached catalog and says marketplace not refreshed. /plugin update leaves a plugin as it is when the marketplace offers the version already installed (plugin.json first, then the entry); a plugin without a version, or from a local folder, is fetched again. /plugin marketplace update follows the catalog's renames chain and installs a renamed plugin under its current name; a plugin the catalog dropped stays with a warning, or is uninstalled when the catalog sets forceRemoveDeletedPlugins.

When a plugin is copied in, its symlinks are handled as Claude Code handles them: a link that stays inside the plugin is kept as a relative link, one to elsewhere in its marketplace is replaced by a copy of what it points to (each time it is linked), and one that leads outside the marketplace, to nothing, or back into a folder being copied is left out. A plugin from a local folder keeps only the links inside it. Localix refuses an install whose links would bring in more than 20,000 entries or 256 MiB, and leaves the installed copy as it was.

When a plugin is copied in, its Node.js packages install from its lockfile as Claude Code installs them: bun.lock, npm-shrinkwrap.json or package-lock.json with a matching package.json, only pinned registry packages, scripts off, for at most 60 seconds, in a folder of its own. A lockfile that cannot be checked (bun.lockb, yarn.lock, pnpm-lock.yaml) leaves a note instead.

A dependency resolves in its own marketplace, or in the one "name@marketplace" or { "marketplace": … } names under the root catalog's allowCrossMarketplaceDependenciesOn. Its version range installs the highest <plugin>--v<version> tag of a git-backed plugin's repository (none in range fails the install). A plugin whose dependency is not installed, is switched off or falls outside the range does not load, nor does a plugin that needs it, and its row says why (Dependency "<name>" is disabled — enable it or remove the dependency). Only plugins at the install's scope count: a project's copy does not satisfy a user-wide install.

Claude Code settings

Localix reads the marketplaces, plugins and plugin settings Claude Code's settings files declare (extraKnownMarketplaces, enabledPlugins, managed policy, pluginConfigs); see Claude Code settings.

An entry whose plugin has no .claude-plugin/plugin.json is its manifest: the official *-lsp plugins get their language servers this way. Where both exist, the entry's commands, agents, skills, output styles and themes are added and its hooks replace the manifest's per event; strict: false with components in both is refused as conflicting manifests. Reserved marketplace names (Anthropic's own, inline, npm and look-alikes) are refused unless the source is Anthropic's GitHub.

A marketplace added from a local folder is read where it is, not copied. A user-scope install of one of its relative-path plugins loads in place from its folder, as in Claude Code: edit the files and run /plugin reload, with no update and no version bump. ${CLAUDE_PLUGIN_ROOT} is that folder, and /plugin update checks the files again and says the plugin loads in place. /plugin remove and /plugin marketplace remove forget the record Localix keeps in ~/.localix/plugins/.in-place.json; no command deletes or changes the folder.

A plugin installed as a copy by an earlier version keeps working as one; /plugin update turns it into an in-place plugin and removes the copy.

Trust: you approve the plugin, not its files, and its folder can change after you approve it. A hook, MCP server or script added there later loads at the next /plugin reload under that approval, as in Claude Code, so add a marketplace from a local folder only when you control what is in it.

Output styles, themes and settings

An output style shapes how agents answer. Localix offers Claude Code's Default, Proactive, Concise, Explanatory and Learning, a plugin's output-styles/*.md as <plugin>:<name>, and your own Markdown files in ~/.localix/output-styles/ and .localix/output-styles/ in the working directory and each folder above it, and those you wrote for Claude Code in ~/.claude/output-styles/ and .claude/output-styles/ in the same folders. The nearest folder wins a name, at one level Localix's folder wins it, and no style replaces a built-in one. A plugin style's text is used as written: ${CLAUDE_PLUGIN_ROOT} and the other variables are not substituted in it.

Set the style every chat starts in under Settings → Preferences → Output style. Use /output-style <name> for one chat (a plugin's style by its full <plugin>:<name>) and /output-style default to turn styles off there. keep-coding-instructions keeps the engineering lines of the agent's instructions, and a style marked force-for-plugin applies while its plugin is enabled. Styles shape a chat's own replies, not delegated tasks.

A plugin's themes appear in Settings → Preferences → Appearance and through /theme <name>, with those of the open project's plugins. Choosing one applies its light or dark base plus its colors; Localix falls back to the base when the plugin is disabled.

A plugin's agents/*.md are subagent types. Agents that can delegate see them under # Agent types and hand a task to one with Agent and subagent_type: "<plugin>:<name>", or the bare name when only one plugin defines it; a workflow's agent() takes the same agentType. The child runs with the agent's prompt, tools and disallowedTools, preloaded skills, maxTurns, autoCompactWindow, omitClaudeMd and memory. background: true never waits for the report, and isolation: worktree works in a fresh git worktree, which is kept. As in Claude Code, a plugin agent's hooks, mcpServers and permissionMode are ignored; see Claude Code agent types.

Without tools, the child inherits the chat's tools, its MCP tools included behind ToolSearch. A tools list is exact: the child holds those tools and ToolOutput, which recovers compressed results. It names an MCP tool as mcp__<server>__<tool>, a plugin's server as plugin_<plugin>_<server>, or every tool of a server as mcp__<server>__*; disallowedTools takes the same names.

The lists use Claude Code's tool names, the same ones a hook sees a call under (hook tool calls), and Localix's own tool names too (Plan, Jobs, Browser, Skill …). One name can cover more than Claude Code's tool does, and some Claude Code tools have no counterpart:

A main agent's tools list switches off every Localix tool it leaves out, Browser, Skill, Plan and Loops included, as Claude Code's exact list does. Only the run's own plumbing stays on: ToolSearch, ToolOutput and ContextBudget.

An entry with a specifier in disallowedTools or disallowed-tools, such as Bash(rm *) or Read(.env), denies only what the pattern matches, written as in a permissions.deny rule. A Read(...) entry also covers Edit and Write on that path. An agent's disallowedTools reads the same way, and a skill the model loads applies its list from then on.

A plugin's settings.json agent runs chats on the default agent as that plugin agent, on the chat's model. subagentStatusLine rewrites the rows of running subagents in the agent sessions panel under the message box.

Channels

A plugin MCP server that declares claude/channel speaks into the chat that last used it; enabling the plugin opts it in. For a server you added, turn on Listen as a channel on its Store page (Settings tab), as Claude Code's --channels does. Localix remembers which chat a channel speaks into, so after a restart its messages arrive before your next message. A channel that declares claude/channel/permission receives each approval prompt opened in its chat and may answer yes <id> or no <id>; the first answer applies to that one call.

Workflows

A workflow is a JavaScript script that runs many agents. The Workflow tool takes an inline script, the name of a saved or plugin workflow, or a scriptPath; args reaches the script as the global args, and resumeFromRunId resumes a run. Saved workflows live in <project>/.claude/workflows/ (every folder up to the repository root, the closest one wins) and in ~/.claude/workflows/; the project's wins over yours. A saved workflow is the command /<name>, a plugin's is /<plugin>:<name> [input].

A run goes on in the background: the chat stays free, the run is a background job you can stop with Jobs, and its result arrives in a later turn. Each agent() call is a child task of the chat, on its agent's model and effort (yours, else the chat's) and, with isolation: 'worktree', in a fresh git worktree under ~/.localix/worktrees that is removed when the agent changed nothing. Up to 16 agents of a run go at once, fewer on machines with fewer cores (CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS sets 1 to 256), at most 4,096 items go to one parallel() or pipeline() call, and a run starts at most 1,000 agents.

Each run has an id (wf-…) and keeps its script (its scriptPath) and journal in ~/.localix/workflow-runs/. Run the workflow again with resumeFromRunId to resume a stopped run: completed agents return their saved results, and the first changed or failed agent and everything after it run again.

Compatibility

Checked against the Claude Code plugins reference. Most parts Localix does not run are reported in the plugin's validation; the few it takes in without a note are listed under Limits. In October 2026 all 328 plugins of Anthropic's claude-code and claude-plugins-official marketplaces installed through them without an error.

A plugin that is installed but still waits for your approval has loaded none of its commands, so typing one would show nothing. Typing its name in the composer shows one row instead, is waiting for your OK; choosing it opens the plugin's page in the Store (the Plugins shelf when Localix cannot place it), where you give the OK.

Mods

A plugin whose hooks/hooks.json lists modules is a mod. Localix runs mods written for Claude Code unchanged: panes, the band above the message box, buttons and their hotkeys, and Claude Code's $ API. See Run Claude Code mods.

Limits

• Some manifest fields are read and have no effect, with no validation note: metadata, types (the .d.ts of a mod's state) and experimental.evals, since Localix has no claude plugin eval. A component folder that a manifest path names but that does not exist, such as a skills folder, simply yields no components. A command file that a path names and that cannot be read is an error.
• A plugin whose components live only in its marketplace entry, such as the *-lsp plugins, has them when installed through the marketplace, not from its folder alone.
• Plugins are keyed by name: two plugins of one name from different marketplaces cannot both be installed.
• A hosted marketplace.json takes only entries with their own sources, since relative paths have no folder to resolve from. update and remove act on global installs, not project ones, and only user-scope copies go into the version cache and are auto-updated; a project install stays a copy in the project.
• An archive entry without a sha256 pin, and an npm entry, have the version unknown unless a version field is set, so they are not updated automatically. A marketplace added from a git repository, npm, a URL or a catalog file is a copy under ~/.localix/marketplaces: run /plugin marketplace update <name> to refresh it. One added from a local folder is read in place, but a change to its catalog still takes that update.
• A Default project chat has no project folder, so --project there fails with a hint to install globally.
• Enabling a plugin with hooks, a hooks module, MCP servers or bin/ executables lets it run local code.

Related guides

• Build a mini app
• Plugin marketplaces and updates
• Hooks and slash commands
• Language servers

Source of truth

• The Claude Code plugin format
• Reading a plugin folder
• The mods runtime
• Mods engine and elements
• Hook events and the inert ones
• MCP variable expansion
• Claude Code marketplace names
• Marketplace entry sources
• Layout tests