Skip to main content
When you deploy Unbound through your MDM, Claude Code, Cursor and Augment Code are configured through managed settings — configuration written to a system-wide location rather than into a user’s own files. Codex and the GitHub Copilot CLI read their configuration from each developer’s own profile, so for those two the daily re-run, rather than file ownership, is what keeps Unbound in place. How well that system-wide location is protected is not the same on every platform. macOS, Windows and Linux below sets out, per tool, exactly where each file lands and who can change it — read it before you rely on file ownership as your enforcement story on a Windows fleet.

​
Why managed settings hold up better than personal settings

Instead of writing configuration into each user’s personal settings, which that user can edit, Unbound is installed into the device’s managed settings: a system-wide location, created root-owned by the installer on macOS and Linux.

Out of the user's own files

Managed settings live in a system-wide location, not in the user’s profile. How locked down that location is varies by tool and platform — see macOS, Windows and Linux.

It takes precedence

Each tool reads its managed settings ahead of a user’s own, so the hook registration written there is not undone by a personal config change. Where that file is administrator-owned varies by platform — see the table below.
Managed deployment must be run with administrator privileges. See Deploy AI Tools via MDM for the per-tool install commands.

​
When your Claude Code policy is managed elsewhere

By default an MDM run writes Claude Code’s managed settings itself. On macOS and Linux that means managed-settings.json directly, with its hooks merged into whatever the file already contains. On Windows it writes a drop-in file, managed-settings.d\unbound.json, leaving a managed-settings.json you own untouched; it writes managed-settings.json itself only if that directory cannot be created. If your organization authors Claude Code policy remotely from the Anthropic admin console and you want that file to have exactly one author, add --skip-managed-settings. Unbound then installs its hook as usual but neither reads nor writes the managed settings file:
On Windows pass -SkipManagedSettings; in the Jamf binary script it is the tenth script parameter. The flag applies to Claude Code alone — every other tool’s managed configuration is unrelated and is still installed as usual. The run then prints what your remote policy needs to name: the Python installer prints the path of the hook script it wrote, and the binary runtime prints one hook command per event. Copy what it prints into the remote policy’s hooks.
Set the remote policy up before the first run with this flag, not after. Like every MDM run, it clears user-level Unbound hooks — so until the remote policy names what the run printed, nothing on that device is enforcing.

​
Reapply on a daily schedule

Schedule the MDM deployment to run once a day on each device. If a setting is ever changed or removed, the next run restores it — so any gap closes within 24 hours without manual intervention.
1

Deploy via MDM

Push the MDM install command for each AI tool to your managed devices.
2

Run it daily

Configure your MDM platform to re-run the same command on a daily schedule. Re-running is safe — it reapplies the managed settings and changes nothing on devices that are already correct.
3

Confirm on AI Tools Discovery

Check Discovery — Summary for each device’s Last Sync, and the Setup Tampered list for devices whose setup was removed or modified.

​
Keep an eye on your fleet

Settings → Devices lists each registered machine by serial number, name and owner, and Discovery — Summary shows when each last reported in. Use it to confirm coverage: a device that hasn’t reported recently, or that an administrator knows was reinstalled, is worth a closer look. When a device needs attention, an administrator can re-run the MDM deployment on it at any time to restore enforcement immediately, and the daily schedule does this automatically.
Pair the daily schedule with a regular check of Last Sync and the Setup Tampered list. The schedule heals drift automatically; the review tells you which devices keep needing it, so you can follow up with those users.

​
macOS, Windows and Linux

Where each tool’s configuration is written, and what protects it once it is there: On macOS and Linux the three managed-settings tools are administrator-owned. Codex and the Copilot CLI are written into each developer’s own profile on every platform: the developer can change those, and the daily re-run is what restores them. GitHub Copilot’s reporting for VS Code is configured machine-wide, under /Library/Application Support/GitHubCopilot, /etc/github-copilot or C:\Program Files\GitHubCopilot, and does need administrator rights to change.
On Windows, Unbound does not protect Cursor’s or Augment Code’s managed settings. Those two are written under C:\ProgramData rather than C:\Program Files, and the installer applies no Windows ACL to them — it sets file permissions on macOS and Linux only. So whether a standard user on your fleet can edit C:\ProgramData\Cursor or C:\ProgramData\Augment is decided by your own ProgramData permissions, not by anything the installer does. Claude Code is not affected: it goes to C:\Program Files\ClaudeCode.Check it on one of your own Windows devices, signed in as a standard (non-administrator) user:
If Users or Authenticated Users appears with anything beyond (RX), a standard user on that device can change those files.Two things still hold either way, and they are what to lean on here: the daily re-run restores the files within 24 hours, and a device whose managed configuration was changed or removed shows up as Setup Tampered in the dashboard on its next run. If you harden the ACLs yourself, leave the hooks subdirectory writable — the hook writes its logs there.
Windows stores Unbound’s environment values machine-wide, so changing them needs administrator rights. macOS and Linux have no machine-wide equivalent, so the same values are written into each user’s shell profile alongside a per-user config file. A standard user can edit those and stop their own device reporting, and the daily re-run restores the values within 24 hours. It is the strongest reason to keep the schedule daily rather than weekly.
If users on a device have local administrator rights, they can change administrator-level settings. Limit local admin rights, keep the schedule daily, and review the Setup Tampered list.

​
Windows Subsystem for Linux (WSL)

Many developers run AI coding tools like Claude Code inside WSL (Windows Subsystem for Linux) rather than directly on Windows. A WSL distribution is a separate Linux environment, and it needs its own treatment.
The Windows installer does not reach into WSL. An Unbound MDM run on Windows configures the Windows side — C:\Program Files\ClaudeCode and each Windows user profile. It never invokes wsl.exe, so a distribution is only configured if you run the Linux install command inside it. Until you do, a developer working in WSL is running unconfigured.
Inside a distribution, Unbound’s tooling takes the Linux path — the Linux install command, and unbound itself behaves as it does on Linux. Once you have run it there, Claude Code’s managed settings are at /etc/claude-code inside that distribution, root-owned. Whether that amounts to protection depends on whether your developers can become root inside their own distributions, which is a property of how WSL is set up on your fleet rather than anything the installer controls.

​
Check it on your own fleet

Run this from a Windows terminal on a device you are rolling out to, signed in as a standard (non-administrator) user:
If that prints 0 with no UAC prompt, that user can reach root inside the distribution and can therefore edit or delete /etc/claude-code/managed-settings.json and the hook script beside it. Confirm what is actually there with:

​
What to do about it

Prefer the native Windows install

Where developers can work on Windows rather than in WSL, the Windows run puts Claude Code’s managed settings under C:\Program Files\ClaudeCode, which standard users cannot write to.

Schedule the Linux run inside the distribution

If WSL is required, run the Linux install command inside the distribution daily, the same way you schedule the Windows run. A file that is removed is back within 24 hours.

Restrict root in the distribution

Root inside WSL is what defeats the file ownership, exactly as local administrator rights do on Windows. Treat it the same way in your standard build.

Monitor your fleet

Pair either approach with a regular check of Last Sync and the Setup Tampered list to catch a device whose configuration went missing.

​
Best practices

Deploy through MDM

Use managed deployment rather than per-user setup so enforcement is administrator-owned from the start.

Run daily

A daily schedule restores any removed or changed settings within 24 hours.

Limit local admin rights

Administrator rights — and root inside WSL — are what let a user change managed settings. Keeping both scarce is what keeps the file ownership meaningful.

Review device activity

Check in regularly to confirm every device is still reporting, using Last Sync on AI Tools Discovery.
Questions? Reach us in Slack or email support@unboundsecurity.ai.

​
Seeing tampered setups in the dashboard

When a device’s Unbound setup is removed or altered, it surfaces in three places:
  • Home — a Tampered Devices recommendation counting the affected machines, captioned “Unbound setup was changed or removed”. Click it to open the user list filtered to those people.
  • Users — arriving from that card applies an Unbound Setup: Removed filter, which stays in the URL so the view can be shared.
  • The user side panel — an Unbound Setup section headed Setup Tampered, listing each affected machine by serial number and, beneath it, one line per tool: Setup removed where the managed configuration is gone entirely, Setup modified where only the hook script was lost.
A developer can repair the machine with sudo unbound doctor --fix. Because these are organization-managed installs, the repair needs administrator rights — without them the command repairs the developer’s own tools, reports the organization-managed ones that are still broken, and asks for an elevated run.
Read this as “needs attention now”, not as an audit trail. Specifically:
  • It covers MDM-deployed installs only. A per-user install that a developer deletes is never counted here.
  • It is retrospective — nothing is detected until the setup command next runs on that device, so there is up to a full schedule interval of lag.
  • Offline is not tampered. A device that is switched off, off the network, or whose scheduled run has stopped firing reports nothing and will not appear. Coverage gaps belong to the Devices view instead.
  • A first-ever install is never flagged.
  • It clears itself — a later clean run drops the device off the list.
  • No timestamp of the tampering is shown, deliberately: only the date of the discovery run is knowable.
  • There is no webhook and no notification.
This is different from the Tampered status unbound doctor reports. That is one machine’s local verdict, run by the developer on demand. This is your fleet-wide view, built from what devices report back.