Roll out to a fleet

A fleet rollout uses the same installer as a single machine, described in Install Golem. What changes is who runs it, how machines land in the right group, and the order in which you turn things on. Most teams go in three steps: find out what is there, see how it is set up, then enforce.

flowchart TD
    A["Push the installer<br/>as each user"] --> B["Watch: rule packs in Shadow"]
    B --> C["Read Agent settings<br/>in Security Inventory"]
    C --> D["Lock risky modes<br/>through your MDM"]
    D --> E["Enforce: packs and rules<br/>to Ask or Block"]

Install as the user on macOS and Linux#

On macOS and Linux the Golem agent is a per-user service, and the machine's identity is created for that user. MDM scripts usually run as root, and a root install produces a machine that looks enrolled but never reports, because the service is registered for an account nobody uses. golem join refuses to enroll when it is run as root through sudo.

Run the installer as the logged-in user. On a Mac, from a Jamf, Kandji or Intune script:

uid=$(stat -f %u /dev/console)
user=$(id -un "$uid")
launchctl asuser "$uid" sudo -u "$user" /bin/sh -c \
  'curl -fsSL https://app.golem.team/install.sh | GOLEM_WORKSPACE_KEY=glk_... GOLEM_NO_SANDBOX=1 sh -s -- --with-editor-ext'

GOLEM_NO_SANDBOX=1 stops the installer asking the user for their password to set up the sandbox. To give your Macs the sandbox without that prompt, run the sandbox step as root in a second payload. As root it installs Apple's container package silently, and the Golem agent fetches the rest as the signed-in user the first time it is used:

user=$(id -un "$(stat -f %u /dev/console)")
bin=/usr/local/bin/golem
[ -x "$bin" ] || bin="/Users/$user/.local/bin/golem"
"$bin" install sandbox

It does nothing on an Intel Mac or one older than macOS 26. --with-editor-ext installs the editor extension into every VS Code-family editor on the user's PATH. The browser extension is deployed through Chrome policy instead.

On Linux, run the installer as the target user in a session where systemctl --user works.

Install as SYSTEM on Windows#

Windows inverts the rule. The agent is a machine service, so install.ps1 must run elevated, and an Intune script running as SYSTEM is correct:

$env:GOLEM_WORKSPACE_KEY='glk_...'
$env:GOLEM_LABELS='env=prod,team=platform'
iwr -useb https://app.golem.team/install.ps1 | iex

The machine's identity lives in C:\ProgramData\Golem, not in a user profile, so it does not matter which user is signed in.

Connecting the coding agents is still per user. Run as SYSTEM, the installer connects SYSTEM's clients, which nobody uses, and says so. Push a second script that runs in the signed-in user's context:

golem setup-client

Until it runs, the machine is enrolled and healthy while none of its coding agents talk to it.

Enrollment keys in a payload#

The key in GOLEM_WORKSPACE_KEY is used once, by golem join, and is not written anywhere on the machine. It is visible in your MDM script, though. Create one key per deployment wave under Deploy → Install, named for the wave, so a key that leaks can be revoked without touching the next wave, and the machines it enrolled can be found. A revoked key cannot enroll another machine.

Put machines in the right group#

Groups carry settings down to the machines in them, including which profile, rules and storage apply. You can place machines by hand, or let a label rule claim them:

1. Tag machines at install with GOLEM_LABELS=env=prod,team=platform (at most 10 labels; keys are lowercase letters, digits, _ and -, up to 32 characters; values up to 64).
2. In the console, open Hosts, Groups & Profiles, pick the group, and add a label rule under Label rules.

A machine whose labels match is claimed on the next pass, with no work per machine. A machine cannot name its own group: a label is something the machine says about itself, and the rule that maps it to a group is written by an admin.

Watch first#

Each profile's rule packs have an Enforce or Shadow switch. In Shadow, every rule in the pack records what it would have done, such as "would have blocked", and stops nothing. Start new packs in Shadow, look at what they would have stopped on real work, then switch them to Enforce.

Two things enforce from the first minute, by design:

• Golem's built-in rule that blocks catastrophic shell commands (rm -rf /, writing to a raw disk, a fork bomb). Built-in packs cannot be put in Shadow; each built-in rule acts at its own step, and this one blocks.
• On macOS, the shell jail around Claude Code's shell commands.

The posture report#

Within minutes of installing, each machine reports how its coding agents are set up to run. Open Security Inventory → Agent settings. Each row is one risky setting on one client, with how many machines have it and when it was last seen. Needs attention narrows the list to what alerts; Show fixed adds settings that have since been fixed. Open a row for the machines, the file and the value, and, under Lock it with, the managed setting that prevents it.

The Golem agent reads each client's own settings files every 10 minutes. A launch flag leaves nothing in a file, so it also reads the command lines of running agents, and the hooks report each session's permission mode. A session run with prompts off is listed for 7 days.

Lower-risk settings, such as Claude Code without its sandbox or Codex set never to ask, are listed as information and do not alert. A repository's own settings file counts too, since a cloned repo can switch prompts off for everyone who opens it.

A setting that appears is a signed entry in the record and an alert, which reaches your alert destinations like any other. When the machine's setting is fixed, the alert resolves itself. If a setting is deliberate, for example Codex never asking on CI runners like ci-runner-01, choose Accept the risk: it stays listed, for the whole workspace, and stops alerting. Only the setting's name and value leave the machine.

Turn the checks off with Agent settings in the Security Inventory's settings. Off, machines read and report nothing.

Lock risky modes with your MDM#

The posture report tells you which machines to fix; your MDM fixes them. Push the setting named under Lock it with. For Claude Code that is a managed settings file, such as /Library/Application Support/ClaudeCode/managed-settings.json on a Mac, or the managed preferences profile your MDM already writes:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Claude Code then refuses bypass mode and --dangerously-skip-permissions. The Golem agent reads the managed settings Claude Code actually applies, so once the lock is in place, bypass set in a settings file drops to information.

Then enforce#

1. Switch the rule packs you watched from Shadow to Enforce.
2. Move individual rules to Ask or Block. See Rules and CEL and Block, hold and contain.
3. Start with the built-in rule Shell command with permission prompts off. It ships at Watch. At Ask it puts a person back in front of every shell command in a Claude Code, Codex or Cursor session that runs without its prompts; at Block it refuses them. The posture drawer links to it.

Check the rollout#

Do not take an installer's exit status as proof of capture. On a sample of machines:

golem status --json
golem doctor

golem doctor exits non-zero when anything is broken, which suits a compliance script. In the console, Hosts, Groups & Profiles lists each enrolled machine. A machine that reports healthy but shows no agent activity usually has clients that were never connected, or connected for a different user. Tools nobody connected show up under Shadow AI.

To deploy Golem's golem-fleet skill where users cannot edit it, run golem install-skill as root. It writes the skill into Claude Code's managed skills folder, where it outranks the per-user copy. golem install-skill --print writes it to standard output instead, for tooling that places files itself.

Updates across a fleet#

The Golem agent never updates itself. By default it asks the coding agent, once per session, to offer the person golem update. A fleet that updates by MDM can turn that off with Update notice in a profile's Maintenance section and push golem update on its own schedule, in the same user context as the install.

Remove it fleet-wide#

On macOS and Linux, push the uninstaller in the user's context, the same way as the install:

curl -fsSL https://app.golem.team/install.sh | sh -s -- --uninstall --purge

On Windows, run golem setup-client --remove in each user's context first, then the uninstaller as SYSTEM:

$env:GOLEM_UNINSTALL='1'; $env:GOLEM_PURGE='1'; iwr -useb https://app.golem.team/install.ps1 | iex

Then remove what the uninstaller does not: a managed golem-fleet skill you deployed as root, Claude Code's skill and command files in each user's ~/.claude, and Apple's container package on Macs that had the sandbox. Each machine stays in the console with its signed history; revoke its key from its page under Hosts, Groups & Profiles if it should never report again. See Uninstall.

To contain machines rather than remove Golem, see Quarantine a machine.

What this does not do#

• Golem never changes an agent's settings. The posture report reads them and tells you; the fix goes through your MDM or the client's own admin console.
• It cannot stop a program from starting. A risky mode is something a rule can act on while the session runs, through entry.permission_mode, not something Golem can prevent.
• Some modes leave no trace. Gemini CLI's YOLO switched on inside a session, and Devin's mode changed inside a session, are not seen. A short session of a client Golem did not connect can fall between two 10-minute scans.
• Connecting clients is per user. A machine with several people needs golem setup-client in each of their sessions.