[Feature] Enterprise managed configuration overrides

[rynorris]

We're currently blocked from using T3 Code at my workplace because there's no way to override configuration at the enterprise level. Examples of things they would want to hard-disable are all telemetry reporting, T3 Connect, incoming network connections on developer workstations, etc.

It would be great if T3 Code supported enterprise managed configuration overrides.

[rynorris]

I opened #16931 with the first piece: managed settings that override the server's settings.json, modeled on Claude Code's managed-settings.json and Codex's MDM config. The three examples above (telemetry, T3 Connect, incoming connections) aren't settings.json keys, so that PR doesn't cover them yet. I'd like to land the base first and get agreement on how to extend it before writing more.

Here's what I have in mind.

Policy shape. Settings keys stay at the top level of the policy. A reserved restrictions object holds switches that only tighten, so there's no "force T3 Connect on":

{
  "enableAgentBrowserAccess": false,
  "restrictions": {
    "disableTelemetry": true,
    "disableT3Connect": true,
    "disableNetworkAccess": true,
    "disabledProviders": ["opencode"]
  }
}

Each one would be enforced in the code path that already owns the feature:

• disableTelemetry makes AnalyticsService treat telemetry as off, even if T3CODE_TELEMETRY_ENABLED=true is set. As far as I can tell the server is the only place that sends product analytics. I'd also check whether anything in the desktop app uploads crash reports and cover it with the same switch.
• disableNetworkAccess makes the server refuse to start on a non-loopback host or with Tailscale serve enabled, whether that came from --host, T3CODE_HOST, --tailscale-serve, or the desktop app. The desktop app reports local-only and rejects turning network access or Tailscale HTTPS on, so it never asks the server for something it will refuse.
• disableT3Connect makes CloudLink refuse to link, publish agent activity, or reconnect a saved link at startup. t3 connect fails the same way. The saved link state stays on disk, so lifting the policy brings it back.
• disabledProviders makes the provider registry refuse instances of those providers, and hides them in "add provider". Today a policy can only disable instances it names, so a user could add a second instance of a disabled provider.

The Connections rows (Network access, Tailscale HTTPS, T3 Connect, Publish agent activity) would lock with "Managed by your organization", like settings rows do in the PR.

The PR already loads the policy before the server resolves its config, and the loader lives in @t3tools/shared so the desktop main process can read the same files. That's what makes the env-var-beating checks above possible. I'd also give the desktop app a proper error dialog for an invalid policy, instead of the backend failing to start.

Two questions for maintainers:

1. Does a restrictions object next to the settings keys work for you, or would you rather keep restrictions in a separate file?
2. For disableNetworkAccess, should the server refuse to start on an explicit --host 0.0.0.0, or quietly bind to loopback? I lean toward refusing, so whoever passed the flag learns why it didn't work.

I'd split this into one PR per restriction, unless you'd prefer to review it all at once.

🤖 Written by Claude

[jjliggett]

Hi! Opus here, on behalf of @jjliggett

For context: @jjliggett hasn't heard this requested by any company or organization at this time, but believes that this will matter, because some organizations will likely require these controls before authorizing T3 Code usage. Claude Code enables restrictions like these with its managed settings. So we wrote a design for the remote-access part and compared it with @rynorris's plan above and #16931. We think we can combine the two into one implementation that closes a few gaps we found in the code. Sharing it here so maintainers can decide on scope before anyone writes more code.

What #16931 gets right, and what we'd keep

• The loader in @t3tools/shared, the macOS sources (JSON file plus the com.t3tools.t3code configuration profile via plutil) and /etc/t3code/managed-settings.json on Linux.
• Reading policy once at startup, before config resolves, and never writing it into the user's files, so removing it gives the user their own values back.
• A restrictions block that can only remove capabilities.
• "Managed by your organization" on locked rows.

Gaps on main the plan should cover

1. WSL ignores Network access. The WSL backend always listens on all interfaces ([Bug]: WSL backend binds 0.0.0.0 while "Network access" is off and the UI says "Limited to this machine" #9056, apps/desktop/src/backend/DesktopBackendConfiguration.ts:584-589). A policy read on Windows can't reach the server inside WSL either. Today only the API, telemetry and OTEL variables cross WSLENV.
2. Loopback proxies get around a listen-address check. Tailscale Serve and the T3 Connect tunnel both reach the server from 127.0.0.1. Each needs its own switch, enforced where that feature lives.
3. A stored T3 Connect tunnel starts at launch whether or not cloud config exists (apps/server/src/server.ts:897-928). Unsetting T3CODE_RELAY_URL doesn't disable T3 Connect, because the relay URL is baked into the build.
4. t3 pair --tailscale leaves its Tailscale Serve mapping running after the server exits (apps/server/src/cli/pair.ts:415-426).
5. Windows, where most managed fleets live, needs HKLM policy keys and ADMX/ADML templates for Group Policy and Intune.

Proposed v1: restrictions only

{
  "restrictions": {
    "disableTelemetry": true,
    "disableT3Connect": true,
    "disableTailscaleServe": true,
    "allowedNetworks": ["10.0.0.0/8"]
  }
}

• allowedNetworks replaces disableNetworkAccess:
  • Absent: no restriction.
  • []: this computer only.
  • A list of CIDRs: only clients connecting from those networks, such as a corporate LAN or VPN (related to Bind the desktop backend to the selected interface instead of 0.0.0.0 when network access is on #12323).
  • Enforced on the server's single listener, which drops connections from other addresses before any HTTP or WebSocket handling. Startup fails if --host, T3CODE_HOST or the desktop asks to listen on an address the policy rules out.
• disableT3Connect: blocks link, publish and credential minting in CloudLink, its HTTP routes, t3 connect, the stored tunnel at startup, and webhook scheduled tasks. Saved link state stays dormant, so removing the policy restores it. t3 connect status, unlink and logout stay allowed, since they only reduce exposure.
• disableTailscaleServe: covers --tailscale-serve, the env var, the desktop toggle and t3 pair --tailscale. At startup it removes any stale mapping that points exactly at our port.
• disableTelemetry: product events and relay tracing are off, even if T3CODE_TELEMETRY_ENABLED=true.

Each of the four is restrict-only, so combining sources is simply "most restrictive wins". That's what makes forwarding the Windows policy into WSL safe: the desktop passes it in the startup message it already sends the backend, and nothing inside WSL can loosen it.

Precedence. Policy is a ceiling on the existing chain (CLI flag > env > desktop > saved setting), not another step in it. When a flag or env var conflicts with policy, the command fails and names the policy source, rather than silently ignoring it. That answers the second question above: refuse to start.

Invalid input. We'd suggest a change from #16931 here. An invalid restriction value applies the most restrictive value for that key. An unreadable source applies every restriction. An unknown key is logged and reported, not fatal. Refusing to start on any bad key leaves the desktop with a dead backend and no explanation, and it breaks rollouts while machines run mixed versions.

Sources (read at startup, no native module):

• Windows: HKLM\SOFTWARE\Policies\T3Tools\T3Code, read with reg.exe query, plus ADMX/ADML templates generated from the schema.
• macOS: the existing feat(server,web,desktop): enforce organization-managed settings #16931 sources.
• Linux: the existing feat(server,web,desktop): enforce organization-managed settings #16931 source.

Clients and visibility:

• One small optional field in ServerConfig drives locked rows on web, desktop and mobile. It's absent when there is no policy, and it doesn't include the policy's file path.
• t3 doctor gets a Policy section with the source, the raw and effective values, and any parse errors.

Changes mid-run. Policy applies at the next start. Admins should push a restart along with the policy.

Caveats the admin guide should state plainly. This is a guardrail for official builds, not a security boundary. It doesn't stop forks, older builds, local admins, root inside WSL, or other tools that forward loopback (ssh -R, a user's own tunnel). Firewall rules, egress blocking of the relay, tailnet ACLs and app allowlisting remain the real controls.

Suggested PR order

1. WSL respects local-only ([Bug]: WSL backend binds 0.0.0.0 while "Network access" is off and the UI says "Limited to this machine" #9056). It's a bug fix that stands on its own.
2. The policy loader with all three OS sources, the ServerConfig field, the t3 doctor section and disableTelemetry. This is the smallest end-to-end slice.
3. disableT3Connect.
4. allowedNetworks + disableTailscaleServe, including forwarding the policy into WSL.
5. Overrides for ordinary settings.json keys (feat(server,web,desktop): enforce organization-managed settings #16931, rebased), using MDM-over-file precedence.
6. Later, if requested: disabledProviders, live refresh, and pinning an org-run relay. An org-run relay also needs its own relay, Clerk and web/mobile builds, so that one waits for a real customer.

Questions for maintainers

1. Is an organization policy something you want in T3 Code? If yes, is "restrictions first, settings overrides later" the right scope?
2. Do the names work: T3Tools\T3Code in the registry, com.t3tools.t3code on macOS, /etc/t3code/?
3. Should an invalid key fail closed for that key, as proposed here, or should startup fail as in feat(server,web,desktop): enforce organization-managed settings #16931?
4. With only T3 Connect disabled, sessions paired earlier through the relay still work over LAN. Should startup revoke them, or should we just document it?

We're happy to help @rynorris build this, or to take on pieces, once the direction is approved.

[d1egoaz]

The managed policy from #27197 covers the inbound side for us: limits.clients without remote keeps the server on loopback and turns off pairing, Tailscale Serve, mobile, app.t3.codes, and T3 Connect.

One option we can't find is the outbound side: stopping T3 Code on a managed machine from connecting to a T3 server on another machine. Locking linkedEnvironmentsEnabled to false through settings covers server-side peer links and delegation. The clients have no policy check, though. In Settings → Connections → Add environment, a user can still pair by URL, add a machine over SSH, or pick one through T3 Connect, and saved remote environments reconnect on startup. ConnectOnboardingDialog.tsx notes that "reaching other devices still works" when Connect is off, so this looks intentional today.

Would you take a limit for it, following the connect / webhookTasks convention?

{ "limits": { "remoteEnvironments": false } }

With false, this machine's desktop app and npx t3 browser would connect only to the machine's own environments: the primary and local backends such as WSL. They'd refuse new remote ones before sending any request. Saved remote environments would show as blocked, without being deleted, so removing the policy brings them back. The server would treat linked environments as off under this limit. Mobile, and browsers opened on another machine's server, wouldn't pick it up.

If this direction works for you, I'm happy to open a PR scoped to just this limit.

Assisted-by: claude-opus-5-5 via Claude Code

[jjliggett]

Hi! Opus here, on behalf of @jjliggett.

A quick update to our comment above: we've since seen that managed policy shipped in #27197. Thank you to @juliusmarminge, @t3dotgg, @MatthewFeroz and everyone else who worked on it! It's a thorough piece of work and covers much more than either my suggestion or @rynorris' in this discussion, so please treat our proposal as superseded.

We especially liked:

• t3 policy check and t3 policy show, which give admins a clear way to validate a policy and see what's loaded.
• The care around bypasses, like the empty --host and stale Tailscale Serve routes.
• Reading the Windows registry through the API, so a blocked reg.exe can't leave a machine unmanaged.
• Revoking paired clients at startup, which settles the question we raised about relay sessions.

Thanks also to @rynorris for starting this discussion and #16931.

WSL support

The one area @jjliggett feels most strongly about is WSL, since many Windows developers do their day-to-day work there.

Today a managed Windows machine doesn't run the desktop's WSL backend (apps/desktop/src/wsl/DesktopWslEnvironment.ts:1046), because a server in WSL reads the Linux policy rather than the Windows one. The guide also explains that a server started by hand in WSL needs its own /etc/t3code/policy.json in that distro. That's a safe default, but it means organizations with WSL-based developers can't use the desktop's WSL backend once they deploy a policy.

Would you be open to managed machines running the WSL backend under the Windows policy? One approach is for the desktop to pass the policy it already read to the WSL server at startup, and for that server to enforce it the same way a native server does.

The hard part is the bind. A policy without remote requires a loopback address, but the WSL backend currently listens on 0.0.0.0 because loopback forwarding from Windows is unreliable on some hosts. So this likely depends on the same work as #9056 and #13745. Fixing that bind would also help unmanaged machines, where the backend listens on all interfaces even when Network access is off.

One smaller question

Is there interest in limiting remote to specific networks, such as a corporate LAN or VPN? We haven't heard this requested by an organization, so we're only flagging it in case it comes up.

Thanks again for all the work on this. We're happy to help with the WSL piece if you'd like it, once you've decided on an approach.

[rynorris]

I think the managed policy in #27197 covers most of what we need. For our policy we don't need to restrict outbound connections (in fact, we're using them heavily to run threads on centralized infrastructure), we are mainly focused on (1) restricting external control of developer workstations, and (2) preventing any data being sent to external public infrastructure (e.g. T3 Connect), which I think is all covered.

Thanks to the implementers!

[juliusmarminge]

Thanks @rynorris for the request and proposal. #27197 added managed configuration, including controls for telemetry, T3 Connect, and incoming connections, in d897d3f3f0. Further policy extensions can be discussed separately.