Déployer les agents Kiteworks dans toute votre organisation

Who this is for

You administer Claude Code across a team or a company, and you want the Kiteworks agents in front of everyone without walking each person through the marketplace. One file does most of it: a managed settings document that registers the Kiteworks marketplace on every machine and pre-selects the agents you want people to have.

Rolling out to Claude on the web or Desktop instead? That runs through Organization settings, not this file — see Roll it out to your team.

Either way, each person signs in to Kiteworks once through the official Kiteworks MCP connector. The agents read Kiteworks as the person running them, inside their own permissions and audit trail — there is no service account to provision and no backend to deploy. See Kiteworks MCP connector setup.

Where the file goes

Claude Code reads managed settings from a fixed system path, one per operating system:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux and WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

Managed settings apply above every other settings level, so a developer cannot override them from their own files. Ship the file with whatever you already use for device configuration — MDM, an imaging step, or a configuration-management run.

Step 1 — register the marketplace

extraKnownMarketplaces registers a marketplace by name on every machine the file reaches, so nobody has to run claude plugin marketplace add:

{
  "extraKnownMarketplaces": {
    "kiteworks-lite": {
      "source": {
        "source": "github",
        "repo": "kiteworks/claude-agent-marketplace"
      },
      "autoUpdate": true
    }
  }
}

Set autoUpdate explicitly. Third-party marketplaces default to false, so leaving it out freezes your fleet on whatever it first installed. With true, Claude Code refreshes the marketplace and updates the installed Kiteworks agents in the background after startup.

The Kiteworks marketplace repository is public, so this route needs no token, no credential helper, and no GitHub App.

Step 2 — pre-enable the agents you want

enabledPlugins decides which agents are on, keyed agent-name@kiteworks-lite. Use the exact plugin name shown on each agent's catalog page:

{
  "enabledPlugins": {
    "cmmc-compliance-check@kiteworks-lite": true,
    "duplicate-finder@kiteworks-lite": true
  }
}

An agent set to false in managed settings is blocked at every scope and hidden from the marketplace — that is how you keep one specific agent out rather than listing the ones you allow.

The whole file

{
  "extraKnownMarketplaces": {
    "kiteworks-lite": {
      "source": {
        "source": "github",
        "repo": "kiteworks/claude-agent-marketplace"
      },
      "autoUpdate": true
    }
  },
  "enabledPlugins": {
    "cmmc-compliance-check@kiteworks-lite": true,
    "duplicate-finder@kiteworks-lite": true
  }
}

Two things that otherwise reach your help desk

1. Repository settings wait for folder trust. The same two keys work in a repository's .claude/settings.json, which is tempting — commit it once and every developer on that project gets the marketplace. But Claude Code honors extraKnownMarketplaces from a repository only after the developer accepts the workspace trust dialog for that folder. In a folder nobody has trusted, including a claude -p run there, it ignores the entry without a message, which reads as "the rollout did not work". The system-wide managed-settings.json above is not gated that way — that is the reason to prefer it when you want no per-developer step.

2. Each person still installs the agent once. As of Claude Code v2.1.195, registering a marketplace does not install plugins that come from an external source, on any path that loads plugins. Until the developer installs one, Claude Code reports the agent as not installed and prints the command to run:

claude plugin install <agent-name>@kiteworks-lite

So managed settings remove the discovery work — find the marketplace, add it, choose agents, keep them current — and leave exactly one command per person. Put it in your onboarding note and it is a copy-and-paste, not a walkthrough.

Check that it landed

• /status in a session: the Setting sources line names the managed source in force.
• claude plugin marketplace list: kiteworks-lite is listed.
• claude doctor: reports anything Claude Code dropped from a settings file, which is where a typo in the JSON shows up.

If you distribute through Organization settings

Kiteworks cannot publish agents into your Claude organization, and you treat any vendor who says otherwise with suspicion. Organization sync under Organization settings, Plugins reads a marketplace repository that belongs to your own organization and is private or internal, through your own Claude GitHub App installation or your own GitLab token. There is no route for a vendor-owned repository. Two things do work:

• Mirror it. Copy the Kiteworks marketplace into a private or internal repository your organization owns and distribute from there, with Installed by default or Required. Full steps are under "Roll it out to your team" on the Claude Desktop guide. Your copy does not track us on its own — re-sync it when you want newer agents.
• Reference it. Organization sync fetches a public plugin source without credentials, so a marketplace repository you own can point at the public Kiteworks repository for the agents you want, instead of carrying a copy of them.

What your people get

• Scoped. Each agent declares the exact Kiteworks tools it can call on its catalog page, and acts only within the permissions of the person running it.
• No infrastructure. Skill instructions plus the official Kiteworks MCP connector. Nothing to host, nothing to patch.
• Best-effort, not audited. These are productivity-grade tools driven by host instructions, not the audited Kiteworks Compliance Runtime. Do not use their output as the sole basis for a compliance or deletion decision — see the install disclaimer.