v1.3.0 — default permissions: move deny rules to ask

What changed

Permissions

• The built-in default Claude Code managed-settings.json no longer hard-denies network fetches and secret-file reads. All seven rules move from deny to ask, so they now prompt for explicit approval instead of being blocked outright:
  • Bash(curl:*), Bash(wget:*)
  • Read(**/.env), Read(**/.env.*), Read(**/secrets/**), Read(**/.ssh/**), Read(**/credentials/**)
• deny is now empty; ask carries these plus the existing Bash(git push:*) and Write(**).
• This only affects machines that use the built-in default config. Deployments that supply their own --settings-file template, or that already have a managed-settings.json on disk, are unchanged.

Merged PRs

• Relax default permissions: move all deny rules to ask (#13)

Assets

Four prebuilt binaries, built from source main (commit d07ac10) with -trimpath -ldflags="-s -w", CGO_ENABLED=0:

• tfy-local-ai-setup-darwin-arm64
• tfy-local-ai-setup-darwin-amd64
• tfy-local-ai-setup-linux-amd64
• tfy-local-ai-setup-windows-amd64.exe

v1.2.5 — optional --force-login-org (restrict Claude Desktop sign-in)

Adds an opt-in control to restrict Claude Desktop sign-in to your Claude org.

New

• --force-login-org <uuid> (repeatable, opt-in). Writes the forceLoginOrgUUID managed preference for Claude Desktop, so only accounts belonging to the listed Claude org UUID(s) can sign in (blocks personal/consumer accounts). Off by default — the key is omitted entirely unless at least one UUID is passed, so existing behavior is unchanged.
  • macOS: single UUID → native <string>; multiple → native <array>.
  • Windows: single UUID → REG_SZ; multiple isn't a documented registry format, so the first is applied with a warning.
  • Pair with org-side SSO + domain capture to control who is a member of the org.

Merged PRs

• Add optional --force-login-org to restrict Claude Desktop sign-in (source#12)

Full changelog: v1.2.4...v1.2.5

Assets

Prebuilt binaries for macOS (arm64/amd64), Linux (amd64), and Windows (amd64), built from source main @ 59f0944 with -trimpath -ldflags="-s -w".

v1.2.4 — Windows: run as SYSTEM (MDM privilege-check fix)

Windows fix: the binary now runs as the SYSTEM account that MDM (Intune/SCCM/GPO) uses.

Fix

• Accept SYSTEM integrity in the privilege check. checkRoot() on Windows only accepted High integrity (S-1-16-12288, elevated admin) and rejected everything else with error: must be run as Administrator. SYSTEM runs at System integrity (S-1-16-16384) — higher than High, but not matched — so the binary failed on every real Windows MDM run. It now accepts System integrity as well. (macOS/Linux unaffected — they check os.Getuid() == 0.)

Merged PRs

• Windows: accept SYSTEM integrity in checkRoot (MDM runs as SYSTEM) (source#11)

Full changelog: v1.2.3...v1.2.4

Known follow-up

Windows per-user CLI detection still uses the elevated LookPath (the user-context detection in v1.2.3 covered macOS/Linux only). If claude/codex are installed per-user, detection under SYSTEM may still miss them — tracked separately (read HKCU\Environment PATH).

Assets

Prebuilt binaries for macOS (arm64/amd64), Linux (amd64), and Windows (amd64), built from source main @ 53127df with -trimpath -ldflags="-s -w".

v1.2.3 — MDM: detect CLIs & persist token in the logged-in user's context

Fixes two silent MDM failures on macOS/Linux. Both had the same root cause: under MDM the binary runs elevated (root via launchd/systemd), and it was using that elevated/daemon context instead of the logged-in user's — so it couldn't see per-user installs or write to the user's home. Both now resolve against the logged-in user (the same principle v1.2.2 applied to Claude Desktop detection).

Fixes

• CLI detection under MDM (Claude Code / Codex). toolInstalled used the elevated process's PATH, which under launchd is minimal (/usr/bin:/bin:/usr/sbin:/sbin) and misses every per-user install — Homebrew (/opt/homebrew/bin, /usr/local/bin), npm-global, nvm, ~/.local/bin. --claude-code/--codex (and auto-detect) therefore reported the CLIs not installed and skipped them, leaving them ungoverned while the run exited 0. Detection now runs command -v in the logged-in user's interactive login shell (sudo -H -u <user> <login-shell> -ilc …), with a fallback to the elevated PATH for system-wide installs and an 8s timeout. (An interactive sudo test masked this; launchd's minimal PATH did not.)
• Refresh token not persisted → browser login every run. The token child was re-exec'd with sudo -u <user> (no -H), inheriting the daemon's HOME=/var/root; the default token path ~/.tf resolved to /var/root/.tf, which the user can't write (mkdir /var/root/.tf: permission denied), so the refresh token was never cached. Added -H so ~/.tf resolves to the user's home and the token persists for silent refresh.

Merged PRs

• Detect CLIs and persist tokens in the logged-in user's context (MDM fix) (source#10)

Full changelog: v1.2.2...v1.2.3

Assets

Prebuilt binaries for macOS (arm64/amd64), Linux (amd64), and Windows (amd64), built from source main @ 7a2e962 with -trimpath -ldflags="-s -w".

v1.2.2 — Windows: MSIX Desktop detection, RDP user fallback, schtasks wrapper

Windows-only reliability fixes for managed (Intune / SCCM / GPO) fleets. macOS and Linux behavior is unchanged from v1.2.1. This promotes the v1.2.2-rc1 / v1.2.2-rc2 pre-releases to stable — the code is now merged to source main (#9).

Fixes

• Claude Desktop detection (MSIX/Appx): detect the Claude package via Get-AppxPackage -AllUsers / Get-AppxProvisionedPackage -Online instead of stat-ing a nonexistent %LOCALAPPDATA%\Programs\Claude folder. The old check failed on managed fleets and under elevated/SYSTEM (wrong profile). Fixes --claude-desktop and auto-detect on Windows.
• Logged-in-user resolution (RDP fallback): Win32_ComputerSystem.UserName is empty on RDP-only / no-console SYSTEM contexts. Falls back to the owner of explorer.exe (always the real interactive user). Fixes could not determine logged-in user: WMI returned empty user name.
• schtasks /tr 261-char limit: the device-login command exceeded the schtasks /tr cap once stderr was redirected to a log file (introduced in v1.2.1). It is now written to a small .cmd wrapper and the task points at the wrapper, keeping /tr ~85 chars regardless of path/URL length.

Merged PRs

• Windows: MSIX Desktop detection, RDP user fallback, schtasks /tr wrapper (source#9)

Full changelog: v1.2.1...v1.2.2

Assets

Prebuilt binaries for macOS (arm64/amd64), Linux (amd64), and Windows (amd64), built from source main @ f2ea88a with -trimpath -ldflags="-s -w".

v1.2.2-rc2 (test) — Windows: MSIX Desktop detection + RDP user fallback

Test / pre-release — Windows fixes, built from tfy-local-ai-setup-source working tree (not yet merged).

Changes vs v1.2.2-rc1:

• Claude Desktop detection (Windows): detect the Claude MSIX/Appx package via Get-AppxPackage -AllUsers / Get-AppxProvisionedPackage -Online instead of stat-ing a nonexistent %LOCALAPPDATA%\Programs\Claude folder. Fixes --claude-desktop and auto-detect on managed (Intune/SCCM/GPO) fleets.
• Logged-in-user resolution (Windows): Win32_ComputerSystem.UserName returns empty on RDP-only / no-console SYSTEM contexts. Now falls back to the owner of explorer.exe. Fixes could not determine logged-in user: WMI returned empty user name.

Also includes the rc1 schtasks /tr 261-char wrapper fix.

🤖 Generated with Claude Code

v1.2.2-rc1 (test) — fix Windows schtasks /tr 261-char limit

⚠️ Test / pre-release for customer validation. Not the latest stable release. Code: branch fix/windows-schtasks-261 in tfy-local-ai-setup-source.

Fix

Windows: schtasks /create failed with Value for '/tr' option cannot be more than 261 character(s).

The device-login command (self path + control-plane URL + two temp-file paths + redirects) exceeded the schtasks /tr 261-character limit — introduced in v1.2.1 when stderr began being redirected to a log file. The command is now written to a small .cmd wrapper and the scheduled task runs the wrapper, keeping /tr short (~85 chars) regardless of path/URL length.

This affected all first-time logins on machines with typical user/temp path lengths on v1.2.1, with or without --debug/--log-file.

Includes everything from v1.2.1 (Windows browser-open fix via cmd /c start, live-streamed device-login output, --debug/--log-file, configure-only-installed-tools).

Test command (elevated PowerShell)

.\tfy-local-ai-setup-windows-amd64.exe --debug `
  --url="https://<control-plane>" --tenant="<tenant>" `
  --gateway="https://<control-plane>/api/llm" `
  --log-file="$env:TEMP\tfy-mdm.log"

v1.2.1 — Windows device-login fix; configure only installed tools

Fixes & improvements

Windows device-login no longer hangs

First-time device login on Windows previously hung on "Fetching auth token" with no browser. The browser is opened from a scheduled task, and rundll32 url.dll,FileProtocolHandler silently failed in that non-interactive context (while the fallback URL was discarded to nul).

• openBrowser on Windows now uses cmd /c start "" <url>, which reliably launches the default browser from a scheduled task.
• The scheduled-task child's device-login output (sign-in URL + any errors) is streamed back to the parent in real time, so a failed auto-open shows a copy-paste URL instead of an apparent hang.

Configure only installed tools

• --claude-code / --codex / --claude-desktop now mean "configure if installed" — an explicit flag for an absent tool is skipped with a warning instead of writing a stray locked config.
• When no supported tool is installed, the binary exits 0 before the token fetch (clean no-op, no login popup) — so it's safe to push all flags to an entire fleet.

New diagnostic flags

• --debug — verbose logging; surfaces the device-login browser URL and streams the Windows child-process output; keeps the child log file for inspection.
• --log-file <path> — append all log output to a file (useful for headless/MDM runs with no console).

Assets

Prebuilt binaries for macOS (arm64/amd64), Linux (amd64), and Windows (amd64). Built with -trimpath -ldflags="-s -w".

v1.2.0

tfy-local-ai-setup v1.2.0

Adds Claude Desktop (Cowork on 3P) as a third managed surface, alongside Claude Code and Codex.

What's new

• Claude Desktop MDM support via the native com.anthropic.claudefordesktop managed-preferences domain — macOS immutable plist under /Library/Managed Preferences/<user>/ and Windows HKLM\SOFTWARE\Policies\Claude. (Linux unsupported — Claude Desktop 3P does not run on Linux.)
• Auth token delivered in the X-TFY-API-KEY header via inferenceCustomHeaders — the same mechanism Claude Code uses via ANTHROPIC_CUSTOM_HEADERS. The token is authoritative: a --desktop-header that collides with it (any case) is dropped.
• Model discovery disabled — modelDiscoveryEnabled=false pins the picker to an explicit inferenceModels list; no GET /v1/models calls.
• Desktop model IDs inherit the Claude Code model flags (--opus-model / --sonnet-model / --haiku-model) unless overridden per-tier via --desktop-*-model.
• New flags: --claude-desktop, --claude-desktop-gateway, --desktop-opus-model, --desktop-sonnet-model, --desktop-haiku-model, and repeatable --desktop-header 'Name: Value'. Auto-detect now covers all three clients.

Assets

Four platform binaries are attached below. macOS/Linux users must chmod +x after download.

v1.1.0 — persist access & refresh tokens under ~/.tf/

What's new

• Token persistence to files. The setup binary now writes the obtained access token (JWT) and refresh token to separate files, stored under a ~/.tf/ directory in the logged-in user's home (created 0700, files 0600).
• New flags:
  • --access-token-file (default ~/.tf/access-token)
  • --refresh-token-file (default ~/.tf/refresh-token)
• Paths are forwarded through the sudo/scheduled-task re-exec, so tokens are written in the logged-in user's session. Defaults resolve against the user's home, and the ~/.tf/ directory is created automatically if missing.

Notes

• Default token location moved from ~/.tfy-refresh-token to ~/.tf/refresh-token. Machines with a cached token at the old path will do one fresh device login on next run.
• Enables downstream integrations (e.g. aitori browser governance) to read the same gateway token.

Binaries for macOS (arm64/amd64), Linux (amd64), and Windows (amd64) are attached.