Managed settings · Plexus Docs

Managed settings let an organization set a value once so that every member holding a seat receives it on every machine they sign in on — recommended and theirs to change, enforced and locked, or merely measured to see what enforcing it would do.

It is the fourth thing a plan unlocks, and the second one that reaches across a team rather than across your own machines. Like shared workspaces it needs a seat, and like them it is something somebody else can put on your machine — which is why this page spends most of its words on what that does and does not let them do.

What one is, once it reaches you

A managed setting is an ordinary row on an ordinary settings page. It is not a separate list you have to consult: Let the agent work without asking permission looks the same on Settings → Agent whether you set it or your organization did. What differs is the side panel's Where this comes from, naming where the value came from, and — for an enforced one — a lock on the row.

The organization owns exactly one thing about it: the value, at the level it chose. Everything else stays yours. Your own value is kept underneath an enforced one and comes back the day the organization stops managing the row; a recommended value is written once and never rewritten over a change you made; and nothing about your settings — what you set, where you set it — is ever sent back to the organization.

The whole surface lives in Settings → Organizations, in the Managed settings row. The page shows one organization at a time — pick it from the organization picker at the top — and the row's side panel is about that one: what it manages on this machine, when the list was last checked, Refresh, and Manage for the administrator half.

The three levels

Every managed setting is published at one of three levels, and the level is shown beside it in the list.

Level	What it does on a member's device	What the member can do
Recommended	Set once on each member's device as their global value.	Change it afterwards. A recommendation is never written over a value the member has since changed.
Enforced	Applies on every device, above every layer — session, project, workspace and global alike. The row is read-only.	Nothing, until the organization stops enforcing it. Their own value is kept and returns when it does.
Evaluate	Changes nothing on any device. Each device reports one yes or no — would this change here? — and the administrator sees counts.	Everything they could before. Nothing is applied.

The app states the same three in one line each, above every table that uses the words: Set once on each member's device; they can change it afterwards. — Applies on every device and members can't change it. — Changes nothing; shows how many devices would change. On the web the third is called Dry run.

Recommended is the level that respects a change you made. The organization's value lands in your global layer once, exactly as if you had set it there, and from then on it behaves as your global value: your workspace and project overrides win over it as usual. If the organization later changes its recommendation, the new value arrives only if you never touched the first; and if it withdraws the recommendation, the value is removed only if it is still the one the organization planted. A value you changed is yours, and stays.

Enforced is the level that wins. It sits above all four of the layers, so a project override cannot get out from under it, and it applies everywhere the setting is read — not only on the settings page, but wherever the app consults that value: a lifecycle hook, a session start, a review. Your own value is not deleted; it is shadowed, and the row's hover shows both.

Evaluate is the level for finding out before deciding. Nothing changes anywhere; what the organization gets is a count of how many devices would change, and it never gets names — see The dry run.

What you see on a managed row

A row your organization manages looks like any other row in the list, with one difference for an enforced one:

An enforced row shows a lock in place of its arrow. Select it and the side panel's Where this comes from says Set by Acme. Ask an admin to change it. Every control in the side panel is read-only, on every settings page — global, workspace, project and session — and there is no Reset to default or Use workspace value, because there is nothing there you could change.
A recommended row is editable exactly as before. While its global value is still the one the organization planted, its side panel says so; the note goes away the moment you change it, because from then on the value is yours.

The side panel tells you both halves. On an enforced row: "Acme sets this to Sonnet. Your own value, Opus (set at Project), returns if Acme stops managing it." — or "You have no value of your own." if you never set one. On a recommended row: "Acme recommended Sonnet. It was set once on this device, and you can change it."

The lock is a statement, not merely a disabled control: a write to an enforced setting is refused by the app whatever screen it comes from, so the lock is the app telling you what it would do rather than the only thing stopping you.

A managed row updates live. An administrator enforcing a setting locks the row on your open settings page without a restart, and withdrawing one unlocks it the same way — with your own value back in place.

Which settings can be managed

Exactly the settings that can follow you between your own machines: the ones cross-device sync carries. Anything that describes a preference about how Plexus behaves qualifies — the agent's model and effort, whether sessions start automatically, the review prompts, the lifecycle-hook settings, the copied files, the keybindings.

What an organization can never manage:

The fifteen settings that describe the machine — the shell, the path to the Claude program, the port range, the diagnostics settings, the warm-session cap, the hook timeout, Gravatar avatars, the merged-PR cleanup, the pre-reshape fetch and the two sync switches. They are listed with the reason for each in What stays on this machine, and the same reason applies here: a path or a port range pinned organization-wide means nothing on the next laptop. This also means an organization can never pin how often your machine checks in with it.
Anything in your keychain. No credential, no token, no sign-in.
Everything on the Appearance page, and your custom notification sound — those were never layered settings to begin with.

If an organization publishes a setting this version of Plexus does not have — a newer version added it, or the value is not one this version accepts — the row is listed under Managed settings with "This version of Plexus doesn't know this setting." and nothing is applied. It starts applying the day you update to a version that knows it, without anybody having to publish it again.

Setting them up

Everything below needs a role that grants it. Three permissions sit under Shared settings in the role editor: View settings, Edit settings and Enforce settings. Owner and Admin hold all three by default; Maintainer, Member and Restricted hold View settings only, so every member can read what their organization manages and see the dry-run counts, and a role that should also publish is a copy with the other two ticked.

Enforcing is a separate act from publishing, on purpose. Edit settings lets somebody publish a recommendation, change a value, run a dry run and withdraw a setting; Enforce settings is what locks a row on other people's machines. An organization that wants a wide circle proposing values and a narrow one imposing them ticks the two boxes on different roles.

There are two places to do it, and they are the same list.

In the app

Pick the organization on Settings → Organizations and open its Managed settings row and press Manage. A control you may not use is absent rather than disabled, so the buttons you see are the ones you can press.

Manage a setting opens a dialog: pick a setting from the list of ones that can be managed and are not yet published, grouped as they are on the settings pages; give it a value with the same control the setting has on its own page; choose Recommended or Evaluate; press Publish. The dialog says the rest: every member's device receives this on its next check; enforcing is a separate switch on the policy once it is published.
Each published row shows the setting, its level, who last changed it, and the value — as an editable control while the row may be re-valued, so changing a recommendation is one edit in place. A Level picker swaps a row between Recommended and Evaluate.
Enforce is a switch on the row, shown only to somebody holding Enforce settings. On, the row locks on every member's machine; off, it unlocks everywhere and the setting stays published as a recommendation. An enforced row shows its value as text rather than a control: change the value by stopping enforcement first, or edit it on the web.
Withdraw takes the setting out of the organization's list entirely. The dialog says exactly what that does: Acme stops managing this setting on every member's device. A locked row unlocks and the member's own value returns; a recommended value they never changed is removed. Nothing a member set themselves is touched.

On the web

The same list is a tab in your account panel: open the organization, then Shared settings, between Workspaces and Billing. Publish a setting, Change value, Enforce, Stop enforcing and Withdraw do exactly what their app counterparts do, and the table carries a Dry run column with the same counts. You get there from Settings → My account → Manage on the web in the app, or from the Sign in link in this site's header.

Reaching the members

A published setting reaches a member's machine on that machine's next check — the same check that fetches the organization's shared workspaces: when Plexus starts, when you switch back to its window, a couple of seconds after you change something, and on the schedule set by Check for changes every (minutes) on the Sync page. Refresh under Managed settings asks immediately, and the list carries its own clock per organization — Checked 4 minutes ago, or Not checked yet.

That check does not require Sync this machine to be on. A managed setting is a value arriving from your organization, not anything of yours leaving, so it needs only that you are signed in, hold a seat, and the organization's plan includes it. An enforced setting reaches every member with a seat, including one whose role holds no permission at all — a rule that could be dodged by holding the wrong role would not be a rule.

The dry run, and what it sends

Evaluate exists so an organization can find out what enforcing a value would do before it does it, without turning anybody's machine into the experiment.

While a setting is under evaluation, each member's device works out one thing — whether its own value for that setting differs from the one proposed — and reports the answer as a yes or a no, with the same check that fetched the list. That is the whole of what leaves: not the member's value, not their overrides, not which layer they set it at, and nothing about any other setting.

The administrator sees the answers as counts, never as people: "Would change on 3 of 12 devices." Below five devices the split is withheld — "Fewer than 5 devices reporting." — and it is withheld on both sides, because printing a total beside one hidden number discloses the other by subtraction. A single device reporting alone is the one case that prints exactly, since there is nothing to hide it among.

Move the setting to Recommended or Enforced and the counts disappear with the evaluation; the value then goes out at the new level like any other.

Offline, lapses and leaving

The values your organization manages are held on your machine, and the app reads them from there — never from a live connection. So the rule for every kind of trouble is the same one.

Managed settings are dropped from a machine in exactly one case: the organization confirms you are no longer in it — you left, or you were removed. On the next successful check the organization's values go, your own settings come back untouched, and no other organization's values are affected. A seat taken back is not that case: you are still a member, so what the organization enforces stays enforced until it withdraws it or you leave.

Withdrawing one is never blocked. An administrator can withdraw a setting and stop enforcing one on a plan that has lapsed, with too few seats, or with the organization's plan no longer covering managed settings at all, and the app shows those two controls under the stale panel for exactly that reason — see below.

What needs a seat, and what never stops

A seat is what buys the receiving. Being handed a recommendation, being locked to an enforced value, reporting for a dry run, and every part of publishing need the organization's plan to cover managed settings and you to hold one of its seats.

Three things carry on regardless, and each is deliberate:

What is already enforced. A value your machine already holds keeps applying — see the callout above. What a lapse costs is updates, not the rule that was already in force.
Taking something back. An administrator can still withdraw a setting and stop enforcing one after a plan lapses, with a seat shortfall, and on a plan that no longer includes the feature. Otherwise a lapsed organization could not unlock a row it had locked on a departed colleague's machine, which is exactly backwards.
Your own values. A shadowed value is still yours; nothing about a lapse, a seat or a withdrawal deletes it.

If more seats are handed out than the plan pays for, the admin panel shows a warning naming both numbers and publishing and enforcing pause until it is fixed — the same rule as for shared workspaces. In the app Manage a setting and the on-side of Enforce are absent while it lasts; on the web Publish a setting is disabled. Withdraw and Stop enforcing stay. Press Manage seats on the banner — it opens the organization's Plan, seats and people row on the same page — or add seats, and it clears itself.

And nothing local is affected by any of it. Sessions, worktrees, the agent terminal, review, the explorer, the git client, hooks, pull requests and the dashboard are identical with a seat and without one, and always will be.

What sync does and does not carry

Cross-device sync carries your settings between your machines. An organization's managed values are not part of it: each of your machines receives them from the organization directly, on the check described above, and turning sync off does not stop them arriving. An enforced value never enters your settings at all — it sits above them — and a recommended one is planted on each machine by the organization rather than carried from one of your machines to the next.

Two organizations enforcing the same setting is rare and is settled deterministically: on a workspace one of them shares, that organization's value wins; elsewhere Plexus picks one and the row's side panel names it.

Settings — the four layers, and where an enforced value sits above them.
Shared workspaces and Prompts your organization publishes — the other two things an organization hands its members, on the same page in the app.
Roles and permissions — the three settings permissions and who holds them.
Plans, seats and billing — what a seat is, and how one is given.
Cross-device sync — the fifteen settings that stay on the machine, which are also the ones nobody can manage.
Privacy Policy — the field-by-field account of what a dry run sends and what we record.