[juliusmarminge]

Companies that want to roll T3 Code out to their teams have no way to configure it centrally. Every setting belongs to whoever runs the app, so an IT team can't require approvals, keep phones and T3 Connect off a machine, pin providers to a company gateway, or control updates.

Docs: https://github.com/pingdotgg/t3code/blob/t3/managed-policy/docs/user/managed-policy.md

This adds a managed policy, which an administrator deploys with their usual device management tool, in one of these places:

OS	Native	File
macOS	Configuration profile for com.t3tools.t3code	/Library/Application Support/T3Code/policy.json
Windows	Policy (REG_SZ, JSON) under HKLM\SOFTWARE\Policies\T3Tools\T3Code	C:\ProgramData\T3Code\policy.json
Linux		/etc/t3code/policy.json

A machine with both a native policy and a file refuses to start rather than merging them.

The server on that machine enforces it for every client: desktop, browser, mobile, MCP agents, scheduled tasks and the CLI.

What a policy can do

• settings: a default or a lock for any server setting, by path. Locked controls show "Managed by ⟨org⟩" on web and mobile. Policy values are never written into the user's settings.json, so removing the file brings back what users had chosen. Locks also apply inside per-project overrides.
• limits.maxRuntimeMode: the broadest permission mode allowed. It's enforced in the orchestrator for every command, including turn start, MCP agent sign-in, scheduled tasks and ACP session modes. A thread already above the cap is refused new turns, with a one-click switch down, and is never silently lowered. Under a cap, provider launch settings and the provider environment come from the policy only, because wrapper binaries, launch flags or NODE_OPTIONS could otherwise turn off a provider's approvals.
• limits.clients (desktop, local-browser, remote) and limits.connect: the server refuses to bind wider than allowed, stops issuing pairing links, and revokes earlier pairings at startup. Without remote, T3 Connect is off too.
• limits.webhookTasks, browserCookieImport and telemetry: turn each one off. Telemetry off covers product analytics and the server's and desktop's relay traces.
• limits.providers: an allowed driver list, plus fields set on every instance of a driver (env vars, base URL, binary path, launch args), locked or as defaults. This is how an admin routes Claude through Bedrock or a gateway.
• limits.updates: mode: "off", a desktop feedUrl mirror, and allowNightly: false.
• t3 policy show and t3 policy check <file>.

Any problem in the file stops the server: invalid JSON, an unknown key, or a wrong type. A key this build can't enforce would otherwise look enforced. Admin docs are in docs/user/managed-policy.md.

Not covered yet

• Providers still read their own config homes (~/.claude, ~/.codex). The docs point admins to each provider's managed settings.
• Environment variables set where the server is started still reach providers.
• feedUrl only redirects the desktop app; t3 update still goes through npm and GitHub.
• Browser relay tracing isn't controlled by the policy.
• With Connect off, the server unlinks at startup without telling the relay. Phones show the environment as offline rather than explaining the policy.

Verification

vp run check:changed passes: format, lint, knip, typecheck of 36 packages, and 75 test files (893 tests). It includes new tests for the settings overlay, lock vetting, the mode cap in the orchestrator, auth and Connect refusals, webhook tasks, provider hydration and update policy.

Nothing has been checked in a running client yet, so there are no screenshots. Still to check by hand: the managed rows in web and mobile settings, the disabled mode options and switch-down button in the composer, and the provider environment editor locking.

Built with Claude Opus 5.5 in Claude Code, inside T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

🟠 High policy/managedLimits.ts:106

When tailscale is missing or its path produces ENOTDIR, closeTailscaleServeTo treats the lookup as an empty mapping list and lets the server bind while a persistent Tailscale Serve mapping may still expose it to remote clients. Fail closed on these spawn errors instead of treating them as proof that no forwarding exists.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/policy/managedLimits.ts around line 106:

When `tailscale` is missing or its path produces `ENOTDIR`, `closeTailscaleServeTo` treats the lookup as an empty mapping list and lets the server bind while a persistent Tailscale Serve mapping may still expose it to remote clients. Fail closed on these spawn errors instead of treating them as proof that no forwarding exists.

[macroscopeapp]

🟠 High chat/ChatComposer.tsx:922

A persisted auto draft on Pi remains sendable under an auto-accept-edits ceiling, but the server rejects its submissions because useComposerSend dispatches the original auto mode. compatibleRuntimeMode has already normalized that mode to approval-required, so the ceiling check misses the violation; check and clamp using runtimeMode instead.

-  const runtimeModeCeilingDenial = managedRuntimeModeDenial(managedPolicy, compatibleRuntimeMode);
+  const runtimeModeCeilingDenial = managedRuntimeModeDenial(managedPolicy, runtimeMode);
   const runtimeModeCeilingFallback =
     runtimeModeCeilingDenial === undefined
       ? undefined
-      : clampManagedRuntimeMode(managedPolicy, compatibleRuntimeMode, compatibleRuntimeModes);
+      : clampManagedRuntimeMode(managedPolicy, runtimeMode, compatibleRuntimeModes);

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/chat/ChatComposer.tsx around lines 922-926:

A persisted `auto` draft on Pi remains sendable under an `auto-accept-edits` ceiling, but the server rejects its submissions because `useComposerSend` dispatches the original `auto` mode. `compatibleRuntimeMode` has already normalized that mode to `approval-required`, so the ceiling check misses the violation; check and clamp using `runtimeMode` instead.

[macroscopeapp]

🟠 High policy/managedSettings.ts:30

A lock on automaticGitFetchInterval (or providerHealthRefreshInterval / backgroundActivityProfile) is accepted but does not enforce the effective setting: with backgroundActivity.profile: "performance", resolveServerBackgroundActivitySettings ignores the legacy interval, so VcsStatusBroadcaster continues fetching every 15 seconds despite a lock of 60000. Reject these legacy paths in favor of the canonical settings, or enforce their effective equivalents.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/policy/managedSettings.ts around line 30:

A lock on `automaticGitFetchInterval` (or `providerHealthRefreshInterval` / `backgroundActivityProfile`) is accepted but does not enforce the effective setting: with `backgroundActivity.profile: "performance"`, `resolveServerBackgroundActivitySettings` ignores the legacy interval, so `VcsStatusBroadcaster` continues fetching every 15 seconds despite a lock of `60000`. Reject these legacy paths in favor of the canonical settings, or enforce their effective equivalents.

[macroscopeapp]

🟠 High policy/managedProviders.ts:319

With limits.maxRuntimeMode set, applyLimits deletes administrator-locked launch settings unless they are duplicated in limits.providers.instances, so effective settings no longer honor accepted settings locks; for example, a locked Claude binaryPath and gateway environment are replaced with no binary path and an empty environment. This branch builds its config rule from the provider pin (which can be absent) and sets environment: "all", overwriting values already applied by managed.applyLocks; preserve those locked values or reject the conflicting policy combination.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/policy/managedProviders.ts around line 319:

With `limits.maxRuntimeMode` set, `applyLimits` deletes administrator-locked launch settings unless they are duplicated in `limits.providers.instances`, so effective settings no longer honor accepted settings locks; for example, a locked Claude `binaryPath` and gateway environment are replaced with no binary path and an empty environment. This branch builds its config rule from the provider pin (which can be absent) and sets `environment: "all"`, overwriting values already applied by `managed.applyLocks`; preserve those locked values or reject the conflicting policy combination.

[macroscopeapp]

🟡 Medium settings/ProviderSettingsForm.tsx:690

Local ACP instances under maxRuntimeMode still expose editable commandArgs, even though the server marks config.commandArgs as managed, so policy rejects the edits without explaining why. managedReason reaches only the schema-derived rows; pass the lock reason to ProviderCommandArguments and disable its Add, edit, and Remove controls when locked.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/settings/ProviderSettingsForm.tsx around line 690:

Local ACP instances under `maxRuntimeMode` still expose editable `commandArgs`, even though the server marks `config.commandArgs` as managed, so policy rejects the edits without explaining why. `managedReason` reaches only the schema-derived rows; pass the lock reason to `ProviderCommandArguments` and disable its Add, edit, and Remove controls when locked.

[macroscopeapp]

🟠 High src/serverSettings.ts:757

Policy-provided inline secrets are copied into the user secret store and can remain active after the policy is removed. Because loadSettingsFromDisk starts from managed.defaults, its migration path treats those values as user settings, redacts them, and persists the changed settings; keep policy-derived secrets out of that path or compare against equivalently transformed defaults without storing them.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/serverSettings.ts around line 757:

Policy-provided inline secrets are copied into the user secret store and can remain active after the policy is removed. Because `loadSettingsFromDisk` starts from `managed.defaults`, its migration path treats those values as user settings, redacts them, and persists the changed settings; keep policy-derived secrets out of that path or compare against equivalently transformed defaults without storing them.

[macroscopeapp]

🟡 Medium settings/ProviderInstanceCard.tsx:437

A user-created or renamed variable disappears from the editor when its name matches a managed variable, leaving it impossible to correct or remove. This check hides rows based on their current draft name, and reconcileRowsDraft retains that draft when the environment is unchanged; reject managed names before updating the draft or distinguish policy-provided rows from user rows.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/settings/ProviderInstanceCard.tsx around line 437:

A user-created or renamed variable disappears from the editor when its name matches a managed variable, leaving it impossible to correct or remove. This check hides rows based on their current draft name, and `reconcileRowsDraft` retains that draft when the environment is unchanged; reject managed names before updating the draft or distinguish policy-provided rows from user rows.