What it syncs

KoNiMa Claude Sync organizes what it syncs into independent domains. Each domain is opt-in and becomes available based on your edition: the same VSIX is installed everywhere — it’s the license that decides what’s available. Everything travels exclusively through your own git repository.

The domains at a glance

Domain	What travels
Configuration	Rules, skills, slash commands, agents, settings.json, and CLAUDE.md — opt-in per individual domain.
Plugins	The inventory of installed plugins: install once, it propagates to every machine.
Custom plugins	The plugin bundles your team authors itself travel through the repository and install automatically on every machine.
MCP servers	The MCP server definitions. Credentials are scrubbed before export and never reach the repository.
Memories	Claude’s memories and project notes, merged and deduplicated across machines; projects are recognized by their git remote.
Hooks	Claude Code’s custom hooks with their per-operating-system variants; a manifest reconnects them on any machine.

Configuration

The heart of the product. The Claude Code configuration that lives in ~/.claude — rules, skills, commands, agents, CLAUDE.md, and settings.json — becomes a consistent baseline across all your machines. Every category is opt-in: you can sync skills but not commands, or the other way around.

Plugins

Your Claude Code plugin inventory travels with you. You install a plugin once and, on the next sync, every other machine receives it. Likewise, removing a plugin removes it everywhere: it’s a decision that applies to your entire fleet, so it requires explicit confirmation.

Custom plugins

Don’t confuse this with the Plugins domain: that one syncs the inventory of plugins installed from public marketplaces, while custom plugins are bundles your team writes itself, and what travels through the repository is the plugin’s own files. A maintainer prepares them in a dedicated folder; on the next sync, every machine receives, installs, and enables them automatically, with no manual action. If a plugin needs extra preparation, that runs on its own; if something goes wrong, the plugin stays installed but is flagged in the dashboard, and syncing is never blocked.

For the full guide, see Custom plugins.

MCP servers

MCP server definitions sync across machines, but with one essential safeguard: credentials never leave your machine. Before export, the values of keys matching token, secret, key, password, auth, bearer, and credential are wiped. What lands in the repository is the server’s structure, not its secrets.

Memories

Claude’s memories and project notes are merged and deduplicated across machines: each machine brings along what the others have learned. Projects are identified by their git remote, not by their local path — so the same project, cloned into different folders on different machines, is still recognized, and its memories are remapped onto the correct local folder. It makes no difference whether the remote is written as https://…, git@host:…, or ssh://…: the same repository is recognized as one project, not three. Projects cloned over SSH now sync their memories too — previously they were left out without a word. The Memories domain requires an edition that includes it.

Project memories sync the same on Windows, macOS, and Linux — they only need a recent system Node.js (23.4 or newer), which the System check verifies for you. If you were on macOS or Linux before, your project memories start appearing at the first alignment, with nothing to reconfigure.

On some git services the product can tell whether a repository has been archived; on others it can’t, and it says so plainly rather than assuming the repository is still active. You’ll notice this when merging projects, where the operation pauses to explain what it couldn’t check.

The scope of project memories

Not every project on your machine has its memories exported: they’re collected within a scope decided from where your sync repository is hosted.

• On a shared host — GitHub, GitLab, Bitbucket, Codeberg, Gitea.com, SourceHut, or Azure DevOps — the default scope is your own organization: the repositories under the same owner as your sync repository. Your personal repositories on the same host stay out of scope, so their memories are never exported to the shared repository. On Azure DevOps this holds for both address forms — dev.azure.com/<organization>/… and the legacy <organization>.visualstudio.com/….
• On your company’s own git server (a self-hosted host), the whole host is your company, so the scope is the entire host — the behavior is unchanged.

Projects outside the scope aren’t hidden. They’re listed in the Projects tab as out of scope, each with the reason, and a per-project switch lets you include one deliberately if you do want its memories to travel.

Hooks

Claude Code’s custom hooks travel with their per-operating-system variants: a single manifest knows which executable variant to use on Windows, macOS, or Linux. If a hook has no valid variant for the current machine, the app reports it instead of running it to no effect.

Keeping files out of a folder — .knmsyncignore

Some files simply should not travel — machine-generated indexes, build output, caches, anything rebuilt locally that would only create noise between machines. To declare them, drop a .knmsyncignore file at the root of any synced folder. It uses the same familiar syntax as a .gitignore, and it travels with the folder — so the whole team shares one declaration instead of each person configuring their own exclusions.

• One line per pattern; # starts a comment.
• name excludes a file or folder called name at any depth; dir/ excludes a whole directory; *.log excludes by extension; a leading / anchors to the folder’s root; !pattern re-includes something a broader rule excluded.

For example, if a hook generates an index file inside hooks/, add a .knmsyncignore there listing it and that file will stay on the machine that produces it. The custom plugins folder already ships a ready-made .knmsyncignore (see Custom plugins), which you’re free to edit. You can open and edit the file directly from the dashboard.

Designed to be safe

Syncing follows a few principles that prevent lost work:

• Your changes always win. A pull never blindly overwrites local work: a three-way reconciliation is performed against a per-machine baseline, and before anything is applied a local backup snapshot is saved.
• No force-push, ever. Conflicts are shown in the dashboard and never resolved silently.
• Idempotent. Every operation is declarative and can be re-run without harm.
• Multi-window aware. A single VS Code window drives the sync; the others follow without collisions.
• Offline tolerant. Failed pushes are queued and retried; the license works offline for up to seven days from the last successful validation.

What never travels

Your data never passes through KoNiMa’s servers. The only endpoint contacted is the license API, and only for validation (and, when requesting a trial, an anonymous, one-way hash of the machine to prevent abuse). Repository credentials and the license key stay in the VS Code secret store, never written to disk.

Two machine-specific items also stay out of syncing:

• The ~/.claude.json file stays in your home folder: Claude Code never moves it (even with a custom configuration folder) and Claude Sync never syncs it.
• The Claude folder choice itself — the machine-scoped setting — never travels between machines.
• The .knm-sync working area inside the Claude folder — where Claude Sync keeps its own baselines, safety backups, and locks — is strictly local to each machine and is never synced.