Deploy with Jamf Pro
Ship the signed Straza pkg to Macs with one Jamf Pro policy that installs it and runs the managed install for your Straza server, and keep the service switched on with a Managed Login Items profile.
- Who
- You, as the Jamf Pro administrator of the Macs whose agents you govern
- Where
- Jamf Pro, and a Mac or a Linux machine for the download and its check
- Profile
- Standalone and enterprise
In short
One Jamf Pro policy installs the signed Straza pkg on each Mac and then runs the managed install for your Straza server as a script. A configuration profile with a Managed Login Items rule for team WMPWM57KYK keeps the Straza background service switched on, because while it is off every governed tool call is refused.
On this page
Jamf Pro can put straza service on every Mac of a fleet. This page installs the Straza package for macOS and runs the managed install for your Straza server in one policy, and a configuration profile keeps the service switched on. Those are the steps that Install the service on macOS takes by hand. Each person then enrolls once, as Enroll a machine shows.
Before you start
- The Straza pkg,
straza_<version>_darwin_universal.pkg, from 2.0.0 or a later release, checked with cosign and its checksum as Install shows. The release job signs it with the Developer ID of SynapTech s. r. o., team WMPWM57KYK, and Apple notarizes it, so Jamf Pro installs it as it is. - Macs on macOS 13 or later, enrolled in Jamf Pro through Automated Device Enrollment or with an enrollment the person approved, which the profile of the last step needs.
- The address of your Straza server, and the harnesses the Macs run:
claude-code,codexorgemini.
Upload the pkg
In Jamf Pro, open Settings, then Computer management, then Packages, and add a new package. Upload the pkg under its own file name, which carries the version, so every release you upload stays apart from the others. Leave the options of the package at their defaults, because the pkg needs no restart.
Add the managed install script
Open Settings, then Computer management, then Scripts, and add a script named
Straza managed installwith the text below. On its Options tab, set the priority to After, and label parameter 4Straza serverand parameter 5Harnesses.#!/bin/sh # Jamf Pro runs this as root after the policy installs the pkg. # Parameter 4 is the Straza server's address, parameter 5 the harnesses. server=$4 harnesses=$5 bin=/opt/straza/bin/straza if [ -z "$server" ] || [ -z "$harnesses" ]; then echo "The Straza managed install needs the server's address in parameter 4 and the harnesses in parameter 5, such as claude-code codex, and one of them is empty, so nothing was changed. Fill in both in the policy's Scripts payload, then run the policy again." >&2 exit 1 fi if [ ! -x "$bin" ]; then echo "The Straza managed install found no $bin, which the Straza pkg installs, so nothing was changed. Add the pkg to this policy's Packages payload, keep this script at the priority After, then run the policy again." >&2 exit 1 fi # Each harness becomes one argument, so $harnesses stays unquoted. set -f exec "$bin" install --managed --server "$server" $harnessesThe script changes nothing when a parameter is empty or the pkg’s binary is missing, and it says which one in the policy’s log. It runs as root outside sudo, so for codex the managed install writes no Straza MCP registration into any person’s
config.tomland says so. The managed codex hooks still govern every codex tool call.Claude Code uses only its highest managed settings source, so on a Mac with a Claude Code profile from Jamf Pro or server-managed settings that lack Straza’s hooks, Claude Code skips them with no warning, as Claude Code skips Straza’s hooks under a higher managed source in Known limits says.
Create the policy
Open Computers, then Policies, and add a policy named
Straza. Give it the Packages payload with the pkg and the Scripts payload with the script, fill in the fields as the table shows, and scope it to the Macs whose agents you govern.Payload Field Value General Trigger Recurring Check-in, and Enrollment Complete for Macs that enroll later General Execution Frequency Once per computer Packages Action Install Scripts Priority After Scripts Straza server Your server’s address, such as https://straza.example.comScripts Harnesses claude-code, or several separated by spaces, such asclaude-code codexYou should see
In the policy’s logs, each Mac in scope shows the install of the pkg, then the script’s output with a
managed configline that names/etc/straza/config.yaml, amanaged binaryline that names/opt/straza/bin/straza, and themanaged wiringandmanaged mcplines of each harness.The priority After runs the script once the pkg is installed, so the managed install always finds the binary. A Mac where the pkg refused to install, such as one where accounts other than root can change
/opt, gets the script’s sentence about the missing binary in the log, and/var/log/install.logon that Mac says why the pkg stopped, as Install shows.Keep the service switched on
Without a Managed Login Items profile, the service can be switched off under Login Items & Extensions in System Settings, and while it is off every governed tool call on the Mac is refused. Open Computers, then Configuration Profiles, and add a profile at the computer level that installs automatically. Add its Managed Login Items payload with one rule. Scope the profile to the same Macs.
Field Value Rule Type Team Identifier Rule Value WMPWM57KYKComment Straza service, or leave it emptyThe rule matches every login item whose code is signed by team WMPWM57KYK, which is the Straza service of the release pkg. macOS turns such an item on and keeps it on, and on macOS 26 it also skips its prompt about background items for it. A package built from source without that team’s Developer ID does not match the rule.
Upgrade and remove
For a later release, upload its pkg, and add a second policy with only that pkg, at the frequency Once per computer and with the same scope. It upgrades each Mac in place while harness windows stay open, as Backup and upgrade describes. The managed install needs no new run, because the upgrade keeps its configuration and wiring. Then put the new pkg in the first policy in place of the old one, so a Mac that enrolls later starts on the new release.
To take Straza off a Mac, remove it from the scope of the first policy and the profile. Then run a policy on it, at the frequency Once per computer, with a script that runs the uninstall of the binary itself.
#!/bin/sh
exec /opt/straza/bin/straza installer uninstall
The uninstall stops the service and removes the managed wiring, the package’s files and its receipt, and keeps the keys in /var/db/straza-service for a reinstall. On a Mac you retire, add --purge at the end of that line, which also deletes the keys and the _straza-service account, and then revoke the Mac’s devices at the Straza server, as Backup and upgrade shows.
What was tested
This recipe has not run on a Jamf Pro instance, and no Mac enrolled in Jamf Pro has taken the pkg, the script or the profile. The account that runs a policy script and the parameter slots are as Jamf’s documentation describes them, and they have not been seen on a Mac. The page is written from the release workflow and the pkg’s sources, before any release carried a pkg. An unsigned package built from the source tree, and on 2026-10-27 a package signed with the Developer ID and notarized by Apple, ran in a macOS 26.6.2 virtual machine that no device management tool manages.
Walked on v1.0.0-1614-g5e1d90de-dirty on 2026-10-26, except every Jamf Pro step, which has not run on a Jamf Pro instance or a Mac it manages.
Not walked. Written on 2026-10-26 from the working tree of the release workflow that adds the pkg, before any release carried one, and from Jamf's documentation on packages, policy scripts and the Managed Login Items payload, read the same day. No Jamf Pro instance and no Mac enrolled in one has run this recipe. Outside Jamf Pro, on 2026-10-27, a pkg built at v1.0.0-1615-g272946e5, signed with the Developer ID and notarized by Apple, passed spctl on a Mac, and a test script installed, upgraded, uninstalled and purged it in a macOS 26.6.2 virtual machine that no device management tool manages.