feat(server): admins set managed policy from a Group Policy template#27340

🟠 High policy/policyTemplates.ts:318

t3 policy templates --policy ... throws and writes no templates when a valid policy contains a nullable setting such as worktreeCleanup: { value: null, locked: true }. plistValue falls through to Object.entries(value) for null; handle null using a representation the macOS policy reader can round-trip.

No longer relevant as of 0271d7cd9c31b9a6577ba4c0570fe97f8e8eea9e

Fixed in 0271d7cd9c: a null value is refused with an error naming the setting instead of crashing. A plist has no null, so there is no representation to round-trip.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

A policy can lock a setting that can be empty, e.g. {"defaultModelSelection": {"value": null, "locked": true}}, since setting values are Schema.Unknown. null reaches this line and Object.entries(null) throws a TypeError, so the command crashes. A plist has no null, so refuse with a clear error naming the setting, e.g. "settings.defaultModelSelection is null, which a configuration profile cannot hold; deploy this policy as a file."

Fixed in 0271d7cd9c. macosProfile now refuses a policy with a null anywhere in it, and the CLI prints "settings.defaultModelSelection is null, which a configuration profile cannot hold; deploy this policy as a file." It writes no files in that case. There is a test for it.

If an admin enables, say, "Broadest permission mode" without the Organization policy, every machine refuses to start. That is fail-closed, as intended, but the error is a schema miss at ["organization"], which a Windows admin will not connect to a Group Policy setting. Suggest returning { error: "set the Organization policy whenever another T3 Code policy is set" } here when document.organization is missing, with a row in the fail-closed table.

Fixed in 0271d7cd9c. The reader now returns "set the Organization policy whenever another T3 Code policy is set", with a row in the fail-closed table. Checked on a Windows 10 PC: with Organization removed, t3 policy show refuses with that message.

For policies with elements, Disabled makes Group Policy delete their values, so Disabled means no restriction. "Allowed providers: Disabled" reads like "no providers allowed". One line in this help text and in the Clients (78) and Updates (142) ones would fix it: "Disabled or Not Configured: no restriction."

Added "Disabled or Not Configured: no restriction." to Allowed clients, Allowed providers and Updates, and to Broadest permission mode, which has the same problem.

Worth a two-minute check on your Windows PC: when reg.exe output is piped it is likely written in the console code page rather than UTF-8, and Stream.decodeText() decodes it as UTF-8. Set Organization to "Société Générale" and run t3 policy show. If it comes back garbled, a non-ASCII environment value in ProviderInstances would also arrive changed without any error. #27197 has the same exposure through its single value.

Checked on the PC: it is garbled. The machine runs code page 437, piped reg query wrote é as 0x82, and Société decoded as Soci�t�. Characters outside that code page were dropped entirely. The reader now uses reg export, which writes UTF-16 to a temp file that is read and deleted. With Société Générale 日本 ✓ as Organization and an accented gateway URL in a ProviderInstances environment variable, t3 policy show on the PC printed both unchanged. cmd /c chcp 65001 also worked, but I left it out because "Prevent access to the command prompt" can block cmd.exe and T3 Code would then refuse to start. Since this PR removes the single JSON value, it covers the #27197 exposure too.

🟠 High src/managedPolicyFile.ts:322

A failed reg export returns undefined here, so readManagedPolicy treats the machine as unmanaged and skips administrator restrictions even when the policy exists. Exit code 1 also means export failure, not only a missing key; distinguish absence from export failure and propagate the latter as ManagedPolicyFileError.

No longer relevant as of 6329fd94c4840e000c8e83ebf482a5b2b32b6a91

Fixed in 6329fd94c4. The reader now runs reg query on the policy key first: exit 1 there means no policy, since the Policies root query already showed the registry is readable. Once the key exists, any reg export failure refuses to start with "the registry cannot be read". The new test fails on the previous commit.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟡 Medium src/managedPolicyFile.ts:221

A valid export with the subkey clients and an enabled desktop value is rejected as an unknown policy key, causing startup to fail instead of applying the allowed-clients policy. Object.hasOwn compares value.key case-sensitively, unlike Windows registry key names; normalize the subkey to its canonical policy-key name before checking and storing it.

No longer relevant as of fe8b263a90e54ca2795fa61faec1ef9f772b3681

If the only configured T3 Code policy is a multi-control one set to Disabled, for example Allowed providers, the key holds just AllowedDrivers=0 and its unchecked boxes. The built document is { schemaVersion: 1 }, so this returns "set the Organization policy…" and every machine refuses to start. Disabled is documented as "no restriction", and setting a policy to Disabled is a common way to undo it. I checked this against your head with the export AllowedDrivers=dword:0 plus AllowedDrivers\\codex=0 and AllowedDrivers\\claudeAgent=0. Suggest: when the document has nothing besides schemaVersion, return no policy, the same as an empty key. Require Organization only when settings or limits remain. One row in the existing table would cover it.

Fixed in 16ac6a47a0. After validating the registry values, the reader now treats a document containing only schemaVersion as no native policy. Active settings or limits still require Organization; unknown values still fail.

Extended the existing test for disabled provider/client/update groups, including coexistence with a JSON policy file and the fail-closed cases. The regression failed before the fix. vp run check:changed HEAD^ passes.

Verified in the retained Windows Enterprise VM: set only Allowed providers to Disabled in Group Policy Editor, with Organization Not configured, then ran gpupdate. The old CLI exited 1 with the Organization error; the fixed CLI exited 0 and reported no managed policy. Returned the control to Not configured afterward.

🔴 Critical src/managedPolicyFile.ts:347

A non-admin can make T3 treat the protected HKLM policy as absent or remove its restrictions by replacing policy.reg before it is read. makeTempDirectoryScoped uses os.tmpdir(), which can point to a user-controlled TEMP/TMP directory, so the export file is not a trustworthy transport; read the policy through a channel the user cannot modify, such as a registry API or pipe.

No longer relevant as of 786cc08a851fe781623c5b6c362c9173211a3a85

Fixed in 786cc08a851fe781623c5b6c362c9173211a3a85. The reader no longer exports or reads a policy file in TEMP. It reads HKLM through the .NET registry API in system Windows PowerShell and sends UTF-8 JSON directly through stdout. Profiles and module autoloading are disabled; the JSON module loads by its absolute system path. Nonzero exits and malformed output fail closed.

The regression test failed on the old reader with a forged empty export and now retains the restrictions. vp run check:changed HEAD passed before the commit.

I also ran the actual policy CLI in the retained Windows 11 Enterprise VM from an unelevated process. It could not write HKLM, but it read the policy correctly with a forged export in TEMP and a fake PowerShell module on the search path. Unicode, quotes, newlines, and trailing spaces survived. The missing/empty/disabled-only cases and the invalid-value cases passed, and cleanup returned the VM to unmanaged state.

This fixes the reported writable-file transport. It does require system Windows PowerShell to be allowed; if it cannot run, policy reading fails closed. It does not claim to prevent every bypass available to a user who controls the T3 Code process.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.