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
| Outcome | How |
|---|---|
| Update one plugin now | Update now on its row, or /plugin update <name> |
| Update a marketplace and its plugins | Update 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 marketplace | The switch on its row under Marketplaces |
| Use Localix's plugins in plain Claude Code | claude 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:
claude plugin marketplace add rsaryev/localix-marketplace
claude plugin install <plugin>@localixName 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:
- the
versionin the plugin's manifest; - else the
versionon its marketplace entry; - 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'ssha256shortened to 12, orunknownfor a local folder ornpm.
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 variable | Effect |
|---|---|
DISABLE_UPDATES, DISABLE_AUTOUPDATER, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC | The whole pass is off and the switches are hidden |
FORCE_AUTOUPDATE_PLUGINS=1 | Keeps 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.
| Setting | In Localix |
|---|---|
extraKnownMarketplaces | Registered 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 |
enabledPlugins | Decides 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, blockedMarketplaces | Checked before a marketplace is added or installed from, with Claude Code's matching |
pluginConfigs | A 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
sha256pin, and an npm entry, have the versionunknownunless aversionfield 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.