Skip to content
Data Workers Onboarding

Deploy with Claude Code enterprise controls

This doc is for the admin who manages Claude Code across your organization (via MDM, fleet management, or Claude’s admin tooling). It takes Data Workers from “works on one laptop” to “present, pre-approved, and policy-locked on every engineer’s machine.”

Do the day-0 kickoff on one machine first — fleet rollout should distribute a configuration you’ve already live-verified.

Before you begin

Section titled “Before you begin”
  • Admin control over Claude Code managed settings — the policy file your fleet tooling deploys to /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux), or C:\Program Files\ClaudeCode\managed-settings.json (Windows). Claude’s docs cover the equivalent MDM plist / registry and server-managed delivery paths.
  • Your Data Workers workspace credentials (customer npm token for local installs, or the hosted endpoint API key for remote) from your onboarding engineer.
  • Node.js 20+ on engineer machines (local install path only).

Option A — Managed remote MCP server (most controlled)

Section titled “Option A — Managed remote MCP server (most controlled)”

Deploy the hosted endpoint org-wide in managed settings; users can’t remove it:

{
  "managedMcpServers": {
    "dataworkers": {
      "type": "http",
      "url": "https://mcp.dataworkers.io/v1",
      "headers": { "X-Mcp-Source": "claude-code" }
    }
  },
  "allowManagedMcpServersOnly": true
}

Notes that matter at enterprise scale:

  • Managed server entries take literal values only (no ${VAR} expansion) and no helper programs, so don’t embed per-user secrets in the managed file. Use per-user OAuth in the /mcp panel, or have users add the Authorization header at user scope — your onboarding engineer will set up whichever auth shape your workspace uses.
  • allowManagedMcpServersOnly: true locks the fleet to your allowlist — engineers can’t add unapproved MCP servers. Use allowedMcpServers / deniedMcpServers for a softer allowlist without the hard lock.

Option B — Project-scoped .mcp.json (per-repo, reviewable)

Section titled “Option B — Project-scoped .mcp.json (per-repo, reviewable)”

Check the server into the data platform repos engineers actually work in:

{
  "mcpServers": {
    "dataworkers": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "dw-claw"],
      "env": { "DW_TELEMETRY_OPT_IN": "false", "DW_MCP_SOURCE": "claude-code" }
    }
  }
}

For fleet configs, pin the version ("args": ["-y", "dw-claw@<version>"]) instead of floating latest — your onboarding engineer tells you the current pinned version and notifies you of updates; rollback is re-pinning the previous version and re-syncing. Project scope is version-controlled and code-reviewed like everything else in the repo; engineers get a one-time trust prompt on first load. .mcp.json supports ${VAR:-default} expansion, so connector credentials stay in each engineer’s environment per the least-privilege guidance, never in the repo.

Pre-approve the tools (permissions policy)

Section titled “Pre-approve the tools (permissions policy)”

Stop the per-tool permission prompts fleet-wide by shipping permission rules in the same managed settings file:

{
  "permissions": {
    "allow": ["mcp__dataworkers__*"],
    "deny":  []
  }
}

Tool rules use the mcp__<server>__<tool> pattern, so you can pre-approve read tools individually and leave write tools prompting — a common first-quarter posture. Claude Code merges user rules additively; admins who need the rules locked use the managed allowManagedPermissionRulesOnly control.

Pin the plugin path (optional)

Section titled “Pin the plugin path (optional)”

If your org prefers the Data Workers plugin over raw MCP config, managed settings can restrict plugin installation to marketplaces you name (strictKnownMarketplaces, with disableSideloadFlags to close the side door) — add Datapokopia/data-workers to your allowed list and publish the two install commands on your internal wiki.

Verify the rollout

Section titled “Verify the rollout”

On any engineer’s machine:

/status        # shows the managed-settings source in effect
claude mcp list    # dataworkers listed, with its scope/source
/permissions   # the mcp__dataworkers__* rules visible

Then the product-level check, same as everywhere: “What’s the status of my data connectors?” — fleet rollout distributes configuration, but each connection still only counts when its live test passes.