Skip to main content
Section navigation

Claude Cowork on Windows

Install the Authenticode-signed systemprompt-cowork.exe, apply the HKCU\SOFTWARE\Policies\Claude registry policy via Intune Custom OMA-URI or Group Policy ADMX, and verify the sync. Covers elevated install, Credential Manager-backed PATs, scheduled tasks, and TPM-backed mTLS.

On this page

Prerequisites - Read the general deployment reference first for the architecture, auth tiers, manifest shape, and audit schema. This page covers Windows-specific mechanics only.

Pick the right binary

Platform Target triple File
Windows x64 desktop or server x86_64-pc-windows-msvc systemprompt-cowork.exe

The binary is Authenticode-signed, so SmartScreen accepts it on first run without a "Run anyway" prompt. Scripted rollout works without manual trust steps.

Install

Three moves: verify the hash, drop into Program Files, run the bootstrap from an elevated PowerShell.

# 1. Verify the hash against SHA256SUMS from the release page
certutil -hashfile systemprompt-cowork.exe SHA256

# 2. Install into a stable path
mkdir "C:\Program Files\systemprompt"
Move-Item systemprompt-cowork.exe "C:\Program Files\systemprompt\systemprompt-cowork.exe"

# 3. First-run bootstrap - ELEVATED PowerShell
& "C:\Program Files\systemprompt\systemprompt-cowork.exe" install `
    --gateway https://cowork-gateway.example.com `
    --print-mdm windows

The elevation matters. install prefers system scope and creates C:\ProgramData\Claude\org-plugins\ with machine-wide ACLs only when run from an elevated PowerShell. Run as a normal user and it silently falls back to %LOCALAPPDATA%\Claude\org-plugins\. Cowork always reads from the system path first, so plugins land where the client ignores them and the UI looks empty. This is the single most common rollout mistake.

Confirm with:

& "C:\Program Files\systemprompt\systemprompt-cowork.exe" validate

Every line should be [ok]. The first line reports which org-plugins path resolved and at what scope - this is your chance to catch the user-scope mistake before it becomes a support ticket.

The registry policy

The five managed-preference keys live at HKEY_CURRENT_USER\SOFTWARE\Policies\Claude. Machine-wide HKEY_LOCAL_MACHINE is a supported fallback; the canonical scope is user.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Policies\Claude]
"inferenceProvider"="gateway"
"inferenceGatewayBaseUrl"="https://cowork-gateway.example.com"
"inferenceCredentialHelper"="C:\\Program Files\\systemprompt\\systemprompt-cowork.exe"
"inferenceCredentialHelperTtlSec"=dword:00000e10
"inferenceGatewayAuthScheme"="bearer"

dword:00000e10 is 3600 decimal (one hour). The gateway URL is rejected unless it is HTTPS or resolves to 127.0.0.1.

Local import for testing

reg import cowork.reg
reg query "HKCU\SOFTWARE\Policies\Claude"

Fully quit Cowork (right-click tray icon → Quit, confirm no Claude.exe in Task Manager) before relaunching. Cowork reads managed preferences once on process start.

Intune Custom OMA-URI

Convert each key into a Custom OMA-URI row under ./User/Vendor/MSFT/Policy/Config/Claude/. The Microsoft Intune Custom OMA-URI docs document the transport.

OMA-URI Data type Value
./User/Vendor/MSFT/Policy/Config/Claude/inferenceProvider String gateway
./User/Vendor/MSFT/Policy/Config/Claude/inferenceGatewayBaseUrl String https://cowork-gateway.example.com
./User/Vendor/MSFT/Policy/Config/Claude/inferenceCredentialHelper String C:\Program Files\systemprompt\systemprompt-cowork.exe
./User/Vendor/MSFT/Policy/Config/Claude/inferenceCredentialHelperTtlSec Integer 3600
./User/Vendor/MSFT/Policy/Config/Claude/inferenceGatewayAuthScheme String bearer

Group Policy ADMX

The systemprompt-core repo ships an ADMX stub alongside the release artefacts. Drop it into your Central Store and the five settings appear under User Configuration → Policies → Administrative Templates → Claude.

Intune Win32 LOB packaging

Wrap the binary and the registry import in an Intune Win32 app (.intunewin).

  • Install command: "systemprompt-cowork.exe" install --apply --gateway https://cowork-gateway.example.com
  • Install context: System - ACLs land on C:\ProgramData\.
  • Install behaviour: reboot-not-required.
  • Detection script: runs "C:\Program Files\systemprompt\systemprompt-cowork.exe" validate and greps stdout for [ok] lines; emits "Installed" on all-green.

install --apply is idempotent - re-running on a configured machine refreshes the pinned pubkey and gateway URL without disturbing the cached JWT. Intune re-evaluates detection on every check-in; idempotency keeps that safe.

Task Scheduler for periodic sync

The credential helper runs on every inference call, keeping the JWT fresh. Manifest sync is separate. A Scheduled Task is the right shape - runs at logon, then on an interval.

& "C:\Program Files\systemprompt\systemprompt-cowork.exe" install --emit-schedule-template windows
# writes: systemprompt-cowork-sync.xml

schtasks /Create /TN "SystempromptCoworkSync" /XML systemprompt-cowork-sync.xml
schtasks /Query  /TN "SystempromptCoworkSync" /V /FO LIST

The XML conforms to the Task Scheduler schema and can be edited before import to change interval, scope, or run account.

mTLS with TPM-backed storage

For the mTLS tier in regulated environments, the device certificate belongs in hardware-backed storage. Windows uses the Microsoft Platform Crypto Provider, which backs keys to the Trusted Platform Module.

The binary reads an OS keystore reference, not a raw private key. Set SP_COWORK_DEVICE_CERT_LABEL via MDM to point at a certificate-store entry. The private key stays inside the TPM; the binary signs challenges through the Cryptography API (CNG) and the certificate is extracted only for its public portion.

Issuance rides on the existing corporate PKI - Intune Certificate Connector, NDES, or a user-driven systemprompt-cowork enrol flow requests a cert from the internal CA at enrolment. Revocation is immediate: flag the cert in the CRL and the next /v1/auth/cowork/mtls call returns 403.

Verification checklist

  • systemprompt-cowork.exe validate returns all [ok] lines, org-plugins path resolved at system scope.
  • reg query "HKCU\SOFTWARE\Policies\Claude" echoes all five keys.
  • Cowork launches without showing Anthropic's sign-in screen.
  • systemprompt-cowork.exe sync succeeds and prints sync ok: N installed, 0 updated, 0 removed.
  • One row appears in audit_events per Cowork chat turn with the expected user_id and tenant_id.

Troubleshooting

  • validate reports scope: user. install ran without elevation. Re-run from an elevated PowerShell so the ACLs land on C:\ProgramData\. Plugins in user scope are invisible to Cowork.
  • "credential helper failed" in Cowork. The binary printed something other than one JSON line to stdout. Run systemprompt-cowork.exe directly from a terminal; any extra stdout breaks the contract.
  • sync fails "manifest signature verification failed". The gateway's signing key rotated. Open %APPDATA%\systemprompt\systemprompt-cowork.toml, delete the [sync] block, and re-run install --gateway <url> to pin the new key.
  • manifest fetch failed: 401. The PAT expired or was revoked. systemprompt-cowork.exe logout; systemprompt-cowork.exe login <new-pat>.
  • Chat works but no plugins visible. Sync ran at user scope while Cowork reads system scope. Reconcile with validate and re-run install elevated.
  • Cowork still shows an Anthropic sign-in screen. MDM keys did not apply. reg query "HKCU\SOFTWARE\Policies\Claude" must show all five values. If they are present and Cowork still prompts, the client was not fully quit before relaunch.

Where to go next