Skip to content

Plugin marketplaces and updates

Localix registers the Store's default marketplaces on first start and keeps plugins installed from marketplaces up to date the way Claude Code does. Use this page to see which marketplaces come registered, where a plugin's version comes from, and when an update runs.

What you can do

OutcomeHow
Update one plugin nowUpdate now on its row, or /plugin update <name>
Update a marketplace and its pluginsUpdate marketplace on its row, or /plugin marketplace update <name>
Refresh every listing, installing nothing/plugin marketplace update
Turn auto-update on or off for a marketplaceThe switch on its row under Marketplaces
Use Localix's plugins in plain Claude Codeclaude plugin marketplace add rsaryev/localix-marketplace

How it works

Localix's own plugins

Localix ships no plugin. Its own live in the Localix marketplace, which is the localix default marketplace below: they install, update and switch off in the Store (Plugins) like any other, and carry no special origin or precedence. In plain Claude Code:

Shell
claude plugin marketplace add rsaryev/localix-marketplace
claude plugin install <plugin>@localix

Name conflicts: Localix's order, highest first, is your installs (~/.localix/plugins and the version cache), plugins loading in place from a local-folder marketplace, plugins Claude Code installed, then a project's own plugins under a name nothing else holds.

The default marketplaces

On first start Localix registers the Store's default marketplaces, the way Claude Code adds claude-plugins-official: its official localix from the GitHub repository rsaryev/localix-marketplace (only .claude-plugin/ and plugins/ are checked out), Anthropic's claude-plugins-official and its community claude-community. Nothing from them is installed. One already registered from the same repository, under any name, is reused. They need the network once; offline (or with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set) they are skipped and tried again at the next start. Removing one is remembered: it is not added back until you add it yourself, for example with /plugin marketplace add rsaryev/localix-marketplace.

Updates

Localix computes a version for every plugin it installs from a marketplace, as Claude Code does, and the version is how an update is detected:

  1. the version in the plugin's manifest;
  2. else the version on its marketplace entry;
  3. else one from the source: a git commit shortened to 12 characters (github, url, git-subdir, which also carries a hash of its path, and a relative path in a marketplace cloned from git), an archive's sha256 shortened to 12, or unknown for a local folder or npm.

A version that cannot name one folder (empty, ., .., or holding a slash) is skipped as if unset. A command entry ignores its entry version and has the version unknown.

A manifest that pins "version": "1.0.0" therefore keeps everyone on that copy until the string changes. An entry pinned to a sha never moves. A plugin that loads in place from a local-folder marketplace has no versions: it loads its current files.

A user-scope copy from a marketplace lives in ~/.localix/plugins/cache/<marketplace>/<plugin>/<version>/, recorded in ~/.localix/plugins/installed_plugins.json in Claude Code's shape. An update installs the new version beside the old one and points the record at it; an unchanged version installs nothing (<name> is already at the latest version). The old version folder gets an .orphaned_at marker and is removed 14 days later, so whatever already started from it keeps its files. An update that fails keeps the version before. Uninstalling orphans the version the same way.

When updates run. Auto-update is on by default for the official localix marketplace and off for every other one; the switch on a marketplace's row changes it. Claude Code updates once per session, a random delay of up to ten minutes after the first message. Localix keeps running, so the pass runs a random one to ten minutes after start and then every hour: it refreshes each marketplace with auto-update on, updates the plugins installed from it on disk, and sweeps orphaned versions. A run already under way keeps what it loaded; the next run loads the new version, mods reload when the update lands, and a chat's plugin monitors keep running until the chat ends.

Environment variableEffect
DISABLE_UPDATES, DISABLE_AUTOUPDATER, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICThe whole pass is off and the switches are hidden
FORCE_AUTOUPDATE_PLUGINS=1Keeps the pass on despite those

Update now on a plugin's row updates it at once, with its progress on the row; it appears when updating would install another version. A check fetches each plugin's listing entry as an install does (a relative entry is read in the marketplace's copy) and computes its version as Claude Code does; the update that follows within ten minutes uses that fetch. The Store (Plugins) checks when it opens, and every marketplace refresh checks again. A newer version found in a marketplace with auto-update on is installed at once, so Update now is offered only for the other marketplaces.

A plugin whose check could not run, because its listing could not be read or its fetch failed, shows could not check next to its version, with the reason on hover: its state is unknown, not up to date.

A plugin whose manifest sets version updates only when that changes, while one without follows its commit. A check never fetches an entry with a headersHelper or a command source, since both run a command you accept, so neither is offered here. Update marketplace refreshes the listing and updates the plugins installed from it, and names any it leaves for you, such as an entry with a headersHelper. A marketplace's autoUpdate lives on its record in ~/.localix/marketplaces/known.json; one that Claude Code's settings declare under extraKnownMarketplaces brings its own autoUpdate value along (see below).

Claude Code settings

Localix reads the marketplaces and plugins Claude Code's settings declare, where Claude Code keeps them: CLAUDE_CONFIG_DIR (else ~/.claude) for the user's settings and CLAUDE_CODE_PLUGIN_CACHE_DIR (else <config>/plugins) for its installs.

SettingIn Localix
extraKnownMarketplacesRegistered in the background when a scope's plugins are listed, from user, project, local and managed settings; the highest entry wins whole and its autoUpdate is kept
enabledPluginsDecides Claude Code's own installs; managed settings outrank every file, true forcing a plugin on and false blocking it, and a managed false refuses a Localix install
strictKnownMarketplaces, blockedMarketplacesChecked before a marketplace is added or installed from, with Claude Code's matching
pluginConfigsA Claude Code install's saved option values, from user and managed settings, are its values here; a sensitive one is asked for again

Managed settings are read from managed-settings.json and managed-settings.d/*.json in the system directory; MDM profiles and server-managed settings are not. A project's settings cannot re-point a marketplace already added, nor run a headersHelper. Localix's project scope is per machine, like Claude Code's local scope; Claude Code's shared project scope is read from the repository's .claude/settings.json.

Dependencies

A dependency's version range installs the highest <plugin>--v<version> release tag of the dependency's repository that the range admits. When several installed plugins constrain the same dependency, it resolves to the highest version every range admits, and an installed copy outside one of them moves to that version. Ranges that share no version refuse the install with Dependency "<name>" has conflicting version requirements, naming each range and the plugin that set it; what is installed stays as it was. A plugin whose installed dependency is outside its range does not load and says Requires "<name>" <range>, installed <version>.

Accept a headersHelper command

A marketplace entry may fetch its archive with the headers a headersHelper command prints. The command runs only when you install or update that one plugin and accept it: the first /plugin install <name>@<marketplace> stops and shows the command, the archive URL and a sha256. Run the install again with --accept-command <sha256> (also on /plugin update) to run that command for that plugin of that catalog, as Claude Code does.

The sha256 covers the command, the plugin and the marketplace's whole catalog, so a changed command or any change to the catalog needs a new acceptance (an acceptance of an earlier Localix version, which covered only the command and URL, is asked again once). Each install asks again, and an install as another plugin's dependency or a background update leaves the plugin for you. The command runs through sh in Claude Code's configuration directory, without the variables that look like credentials and with CLAUDE_CODE_PLUGIN_NAME and CLAUDE_CODE_PLUGIN_ARCHIVE_URL set.

Limits

  • Only user-scope copies from a marketplace go into the version cache and are auto-updated; a project install stays a copy in the project, and a plugin loading in place has no versions.
  • 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 on their own.
  • Every check fetches each remote entry (git, npm, archive) as an install would: Claude Code's version can come from the fetched manifest, so nothing cheaper (a commit or tag listing) settles it. Only a version a claude.ai marketplace records is compared without a fetch.

Source of truth