Set up Syntic Code for a team

This page is for the person who rolls Syntic Code out to other people: an engineering lead, a platform team, or IT. It walks through the choices you make once, before your developers start: how people sign in, how your rules reach their machines, what you lock down, and how you check it worked.

Each section ends with a link to the page that covers that topic in full.

Everyone signs in with their own Syntic account. There is no shared team key to hand out.

A developer runs syntic login (or picks Sign in on first launch).
The browser opens on syntic.ai, where they log in and approve the request.
The CLI receives a short-lived access token and a refresh token, and keeps renewing the access token in the background.

The CLI never creates a long-lived API key during this flow. It also learns the person’s plan and their role in your organization (for example owner, admin or member) at sign-in, so plan limits and role-based actions work without extra setup.

Signed-in credentials are stored in ~/.syntic/credentials.json, a file only that user can read. They are not written into any project folder, and a repository’s settings can never choose the credential or the API address. The full user flow, including headless machines, is on Sign in.

Which credential wins

A machine can hold more than one credential. The CLI takes the first one it finds, in this order:

Order	Source	Typical use
1	`SYNTIC_API_KEY` in the environment	CI jobs and scripted runs
2	`apiKey` in the user’s own settings file (written by `syntic setup-token`)	A server that cannot open a browser
3	The saved browser sign-in	Everyday use on a laptop
4	The `apiKeyHelper` command in user settings	A secrets manager that prints a credential

For unattended machines, SYNTIC_OAUTH_REFRESH_TOKEN lets the CLI swap a refresh token for an access token at start, so you do not need to store anything else on disk.

Credentials in the CLI’s environment are removed from every process it starts: shell commands, hooks, MCP servers and git. A tool the agent runs cannot read the user’s sign-in.

Keep sign-ins inside your organization

If developers have personal Syntic accounts as well as a work one, you can make sure a work machine only ever uses the work organization. Put this in a managed policy file:

{ "forceLoginOrgUUID": "your-organization-id" }

With it set, syntic login refuses to save a sign-in for any other organization, and a session will not start with one. A credential that is not tied to any organization is refused too. The message tells the person to sign in again and pick the right organization. Only managed policy files count for this key; a user or project file cannot set it.

Decide how your rules reach machines

Rules you enforce for everyone are called managed settings (or policy). They sit above every user and project setting. You can deliver them in three ways, and you can combine them.

Delivery	Where it lives	Good when
Policy files	`/etc/syntic/` on Linux, `/Library/Application Support/Syntic/` on macOS, `%ProgramData%\Syntic\` on Windows	You already push files with a device management or config tool
macOS configuration profile	The preference domain `ai.syntic.code`	Your Macs are enrolled in device management
From the Syntic service	Fetched at start, cached in `~/.syntic/remote-managed-settings.json`	You want one policy for every machine a person signs in on, without touching devices

When more than one source is present, they stack in this order, later ones winning: policy files, then service-delivered settings, then the configuration profile.

Full details: Managed settings and Settings from the service.

Decide what to enforce

Most teams start small and tighten later. These are the levers people reach for first.

Goal	Key	Page
Keep secrets away from the model	`permissions.deny` with rules like `Read(.env)`	Permission rules
Only your rules can approve tools	`allowManagedPermissionRulesOnly`	Managed settings
No prompt-free mode	`permissions.disableBypassPermissionsMode`	Permission modes
Control or switch off auto mode	`autoMode`, `permissions.disableAutoMode`	Configure auto mode
Approve which MCP servers may run	`allowedMcpServers`, `deniedMcpServers`	Managed MCP servers
Approve plugin sources	`strictKnownMarketplaces`, `blockedMarketplaces`	Plugins for your organization
Restrict the network for shell commands	`sandbox`	Shell sandbox
Keep everyone on a supported version	`minimumVersion`, `maximumVersion`	Managed settings
Control which models people can choose	`availableModels`, `deniedModels`, `modelPicker`	Models
Route every command through your own launcher	`processWrapper`	Managed settings

A small first policy might look like this:

{
  "forceLoginOrgUUID": "your-organization-id",
  "permissions": {
    "deny": ["Read(.env)", "Read(*.pem)"],
    "disableBypassPermissionsMode": "disable"
  },
  "minimumVersion": "0.1.0",
  "companyAnnouncements": ["Questions about Syntic Code? Ask in #dev-tools."]
}

What admins do on the Syntic service

Some things are tied to your organization’s account rather than to a machine:

Plans and seats. Each person needs a paid plan. A free account is refused at sign-in. See Plans and models.
Usage credits. Owners and admins can switch usage credits on or off from inside the CLI with /usage-credits. See Usage and billing.
Service-delivered settings. Policy kept on the service reaches every machine a person signs in on. See Settings from the service.

Plan for usage and data

Before a wide rollout, decide how you will watch spend and what data may leave developer machines.

Manage costs covers budgets, caps on scripted runs and per-agent spend limits.
Monitor usage covers exporting usage events and metrics to your own monitoring tools.
Data usage and privacy lists what is sent where, and how to switch off optional traffic.
Network configuration covers proxies, custom certificates and the hosts the CLI contacts.

Check that it worked

On a developer machine, run:

syntic doctor

Near the end, the report lists the managed keys in force:

Managed policy
  minimumVersion = 0.1.0
  forceLoginOrgUUID = your-organization-id
  permissions.disableBypassPermissionsMode = disable

If no policy reaches the machine, it says Managed policy: none. The same report shows where the sign-in is stored and which privacy level is active.

A policy file that exists but cannot be read stops the CLI before a session starts, and names the file. That is deliberate: a typo should never silently remove your rules.

Onboard your developers

Once the policy is in place:

Share the Quickstart and Sign in pages.
Tell people what you have locked down and why, so a refused command does not come as a surprise.
Ask each team to commit a project SYNTIC.md and a .syntic/settings.json with their own test and lint commands allowed.
Collect questions in one place for the first few weeks.

The Adoption pages have ready-to-adapt messages and a plan for internal champions.

Next steps

Managed settings: every key, file location and merge rule.
Settings from the service: policy without touching devices.
Managed MCP servers: which tool servers may run.
Configure auto mode: the reviewer, its rule lists, and switching it off.
Security: how the safety model fits together.

Managed settings