Server-managed settings

Ordinary settings in Syntic Code are layered: built-in defaults sit at the bottom, a user’s home-directory file overrides them, and a project’s .syntic/settings.json overrides that. This is exactly right for developers tailoring their own experience, but it means any individual can change any value. Server-managed settings invert that model for the choices an organization must control. They are distributed by the administrator and take precedence over both user and project files, so a developer cannot weaken them.

What they are for

Use server-managed settings to enforce, not merely suggest, the rules your organization requires. Common uses include forcing the CLI to talk to your gateway rather than the public endpoint, denying dangerous shell commands everywhere, restricting which model tiers are permitted, and disabling features that conflict with policy. Because these values win over local files, a project cannot re-enable a tool you have banned, and a curious developer cannot edit their home directory to route around them.

How they are applied

Place a managed settings file at the system-level path Syntic Code reads before any user or project file. On a managed fleet this file is delivered by your device management tool or provisioning script and owned by an administrator account so that ordinary users cannot rewrite it:

{
  "permissions": {
    "deny": ["Bash(curl:*)", "Bash(rm -rf:*)"]
  },
  "env": {
    "SYNTIC_BASE_URL": "https://gateway.internal.example.com/syntic"
  }
}

Precedence and verification

When Syntic Code resolves a setting, managed values are applied last and cannot be overridden by anything below them, while deny rules from every layer are combined so no scope can loosen another’s prohibitions. After deploying a managed file, confirm it took effect by inspecting the resolved configuration on a test machine. Keep the file under version control in your infrastructure repository so changes are reviewed and every fleet update is auditable.