Quickstart

Prerequisites

• One of the supported agent harnesses installed and working — Claude Code, Cursor, GitHub Copilot CLI, or Codex. Install detects which you have and wires the right hooks for each.
• Your tenant ID (a UUID handed to you at onboarding) — required for telemetry, recovery sync, and any cloud-side feature.

Install

One script does everything: places the binary, enables telemetry, enrolls it to your tenant, wires the agent hooks, verifies the wire is live, and self-updates. The same script works two ways — run it yourself on one machine, or have your MDM push it fleet-wide.

Download install-mdm-template.sh from the PointFive app — it’s generated per-tenant, with your tenant ID already baked in, so there’s nothing to fill in yourself.

On a single machine

sudo bash install-mdm-template.sh

Needs root exactly once, to place the binary and wire your shell profile. The binary itself ends up user-owned under ~/.tokenshift/bin afterward — everything it does from then on (self-update, hooks) runs as you, never root again.

Note

macOS and Linux only. Windows ships as a signed .msi via Intune — see below.

Across the organization, via MDM

Every MDM method ends up at the same result — a user-owned binary, enrolled to your tenant, hooks wired — but each uses whichever push mechanism is most native to that tool:

MDM	Mechanism
JumpCloud	Runs the same per-tenant install-mdm-template.sh directly as a Command — no different from the single-machine copy above.
Jamf	Pushes the signed .pkg (places the binary, wires PATH) as one policy, then drops the enrollment manifest as a second policy.
Intune	macOS: same .pkg + manifest pattern as Jamf. Windows: the signed .msi, manifest dropped via a Win32 app or config profile.
Ansible	A playbook that performs the same steps natively (download, unpack into the user-owned store, wire PATH, drop the manifest) — no script invocation needed.

Full policy/task detail per tool, verifying a fleet-wide rollout, updating an already-deployed manifest, and decommissioning are in MDM rollout.

Either way — single machine or MDM-pushed — every step is logged to a file under ~/.tokenshift/ you can hand to support if something goes wrong.

Tip

tokenshift doctor is the first thing to run any time something feels off — it reports pinning, manifest, telemetry, and hook state in one block. tokenshift doctor --verify also ships one synthetic record through the live ingest path to confirm the wire is actually live.

What just happened

• The agent’s Bash commands now run through TokenShift: it recognizes the command, runs the real thing, and hands back a shorter version of the output the model sees.
• Full output is preserved in a local recovery cache, on harnesses where the proxy runs unsandboxed (Claude Code, Copilot CLI). The model gets a hint like [Full output: tokenshift recover a1b2c3d4] and can fetch the original whenever it needs it. Cursor and Codex sandbox the proxy, so there’s nothing for recover to replay on those two — see Recovery cache scope.
• Telemetry ships hybrid-encrypted records straight to the ingest endpoint. No control plane, no broker.

Next

• How it works — the architectural overview.
• Core commands — doctor, dashboard, recover, and the other handful you might run by hand.
• MDM rollout — full per-tool detail.
• Security overview — what stays local, what goes off-device.