Rolling Out Trusted Devices for a Small Team: Enrollment, Preflight, and Rotation

Last week I got uneasy about being the only person babysitting a set of scheduled build jobs, so I asked a second person to help run them. Almost immediately, one fact stuck out: from their laptop, they could remotely view and drive my local Claude Code session. As an indie developer who had funneled everything onto a single machine, this was a question I never had to ask. The moment one more person joined, it appeared.

Trusted Devices, available for Team and Enterprise, fills exactly this gap. Before a member can remotely view or operate a local Claude Code session, the feature verifies that their machine is one the administrator has registered as trusted. Pinning a single device for solo use takes a few minutes. But once two or more people are involved, the operational side — enrollment, revocation, and swapping devices — suddenly gets heavier. Here is how to start without letting it break, at a 2-5 person scale.

Decide the scope before you trust anything

The biggest trap with Trusted Devices is turning the feature on first and thinking about scope afterward. Do it in that order and one day a member's session gets blocked with no obvious cause, and you burn half a day isolating it. Before you enable anything, I recommend writing down three things.

First, how far does remote operation go — view only, or command execution too? Second, how many devices may one person keep trusted? Capping it at two, say a main desktop plus a backup laptop, makes the rotation below much easier. Third, who is responsible for revocation? If it is unclear who presses the button when someone leaves or loses a device, the trusted list becomes a graveyard of old machines.

Turn those three into a minimal policy table and drop it in a shared folder so everyone shares the same picture.

Enrollment must complete on the member's own machine

The usual stumble here is an admin trying to trust a member's device on their behalf. Device verification only means something when the person approves it on that very machine. What an admin can stand in for is the decision — whose device, which one, and until when — not the actual verification step performed on the device itself.

So fix enrollment to this order and the confusion goes away. The admin includes the member in the Trusted Devices scope. The member signs into Claude Code on their machine and personally confirms that the device fingerprint shown in the admin console matches their one machine. The admin then approves the surfaced device with a name. That name pays off later. Something like masaki-macbook-14, where the person and model are obvious at a glance, means that six months on, during an audit, you never hesitate about which entry is safe to drop.

Preflight the trust state before any unattended run

The scariest failure in team operation is a scheduled run quietly starting from an untrusted device, getting blocked partway, and leaving a half-finished artifact behind. Nobody is present when an unattended pipeline fails. That is exactly why you place a gatekeeper before the real work: check the trust state, and if the condition is not met, do not begin the work at all.

Here is a preflight pattern to run once, just before the main job. The key is to stop explicitly with exit 1 when verification fails, and never let the rest proceed. Let it continue silently and broken output rides the cache, spreading the damage.

#!/usr/bin/env bash
# preflight_trusted_device.sh — a gatekeeper to run once, right before an unattended job
set -euo pipefail
 
# The team-agreed registry of trusted devices (export from the admin console and place here)
REGISTRY="${HOME}/.config/claude-team/trusted_devices.json"
# This machine's fingerprint (issued once per device, stored in an env var or a protected file)
THIS_FINGERPRINT="${CLAUDE_DEVICE_FINGERPRINT:-}"
 
fail() { echo "PREFLIGHT FAILED: $1" >&2; exit 1; }
 
[ -f "$REGISTRY" ]          || fail "registry not found: $REGISTRY"
[ -n "$THIS_FINGERPRINT" ]  || fail "device fingerprint is empty (env not set on this machine)"
 
# Is this fingerprint present and active in the registry?
status=$(python3 - "$REGISTRY" "$THIS_FINGERPRINT" <<'PY'
import json, sys
registry, fp = sys.argv[1], sys.argv[2]
data = json.load(open(registry, encoding="utf-8"))
for d in data.get("devices", []):
    if d.get("fingerprint") == fp:
        print(d.get("status", "unknown")); break
else:
    print("absent")
PY
)
 
case "$status" in
  active)  echo "device trusted (active). proceeding." ;;
  revoked) fail "this device was revoked. stop and re-enroll." ;;
  absent)  fail "this device is not in the registry. do not run unattended here." ;;
  *)       fail "unknown device status: $status" ;;
esac

Chain it in front of the real job, like ./preflight_trusted_device.sh && node run_pipeline.mjs, and a run from an untrusted device never reaches the work. Treat the console export as the source of truth for the JSON registry, and forbid hand-editing it on the device to shrink the room for tampering. Why keep the registry locally at all? Because unattended jobs also fire in flaky-network windows, and if every check depends on an online lookup, a brief hiccup in the verification service stalls the run outright. A local registry for the first pass, falling back to an online check only when something looks off, is what stayed stable in my setup.

The gaps that hide in rotation and offboarding

Devices always turn over. You move to a new laptop, send one out for repair, or a member leaves. When that happens, everyone remembers to add the new device — and almost everyone forgets to drop the old one. The trusted list only grows, and unused machines quietly stay behind. That is the weakest point.

To prevent the leak, treat addition and revocation as a pair. That is why the per-person cap of two exists. When you want a third device, start by dropping one. The monthly audit surfaces devices whose last access is older than a set threshold, confirms with the owner, then revokes them.

Deciding how to start small

Trusted Devices gets heavy if you try to lock everything down at once. When I started with a two-person setup, I first settled only the minimal shape — allow view plus execute, up to two devices each, audit monthly — dropped in a single preflight, and let it run. Widening the scope is fine once operations are turning.

For a concrete next step, pick one scheduled run that is currently going unattended and slot the preflight in front of it. A single gatekeeper structurally removes the awkward, discovered-too-late failure of "a run started quietly from an untrusted device and broke." Design the pipeline assuming people will be added, and when they actually are, you will not be scrambling.

Thank you for reading — I hope it helps your own setup.