Skip to main content
Desktop policies let organization owners and admins manage what the OpenWork desktop app allows after a member signs in to Cloud. Policies can apply to the whole organization through the default policy, or to specific members and teams through assigned policies. Policies can also provide team prompt cards. The desktop app caches the effective policy, applies it on reload, and refreshes it when the active Cloud organization changes, the Cloud account changes, or the hourly desktop-config refresh runs.

​
What policies control

Current desktop policy keys map to concrete product capabilities:
  • Custom providers: allow or block locally added model providers that were not deployed through OpenWork Cloud.
  • Enable OpenCode Zen Models: allow or block built-in OpenCode models.
  • Multiple workspaces: allow or block creating or configuring more than one local workspace.
  • Control Settings: allow or block desktop settings. When blocked, the desktop app hides every settings page except the Cloud account page, and hides the settings shortcuts in the command palette and account menu. Members can still see their account, switch organizations, and log out.
  • Manage Extensions: allow or block installing and managing local extensions and MCP servers. When blocked, the Library hides the workspace MCP and GitHub import flows and marks third-party directory entries as Disabled by organization; organization-approved skills, connections, and built-in OpenWork extensions still work.
  • Built-in Extensions: allow or block OpenWork-provided built-in extensions, including browser, image, and local-provider extensions.
  • Alpha updates: allow or block opting into experimental Alpha desktop updates.
  • Welcome Page: show or hide the getting-started page for new users.
Legacy desktop policies combine grants from the default policy and every assigned policy: any grant can allow a capability. Explicit Team Access blocks are applied afterward and take precedence over those grants. Restrict members by turning capabilities off in the default policy, then grant more to specific members or teams with assigned policies.

​
Restricted mode

Every policy has a mode selector at the top of its editor:
  • Custom lets you choose each capability.
  • Restricted gives members a vanilla OpenWork: they can chat and use organization-approved skills, but cannot change desktop settings, add providers or use models outside the organization, add workspaces, use built-in extensions, install extensions or MCP servers, or opt into Alpha updates. The locked capabilities stay off until you switch the policy back to Custom. The Welcome Page preference stays editable in both modes.
Because the effective policy is a union of grants, apply Restricted to the default policy to lock members down. A targeted policy in Restricted mode grants nothing on its own.

​
Configure a policy

  1. Open app.openworklabs.com and choose your organization.
  2. Go to Desktop policies.
  3. Create a new policy or edit the default policy.
  4. Pick Restricted, or stay in Custom and turn capabilities on or off.
  5. Assign the policy to members or teams when it should not apply to everyone.
  6. Save the policy, then have members reload, refresh their Cloud account, switch the active organization, or wait for the hourly desktop-config refresh.
The desktop app explains blocked capabilities as organization-controlled. For example, a built-in extension disabled by policy is hidden from the normal catalog and can appear in hidden views with a Disabled by organization explanation, and the account page lists effective capabilities in its App permissions tab.

​
Team access

Open Members → your team → Access to choose Locked or Custom and save permissions. Owners and super-admins can change these controls; other administrators can review them. Locked blocks app customization, including adding tools and MCP servers, changing settings, adding providers and workspaces, using built-in extensions and OpenCode models, and opting into experimental updates. Members can still chat and use available connections. Existing installed tools are not removed, Cloud authoring still follows member roles, and this does not suspend accounts. Custom lets you block individual app capabilities. Switching to Locked and back preserves the Custom choices. A block applies even when the default policy or another team grants that capability. Allowing a capability does not override another restriction. Existing policies without explicit access limits retain their grant behavior. Open Account → App permissions in the desktop app to see which capabilities are Allowed or Blocked and how to request changes from your administrator. These permissions are read-only in the desktop app. The Library explains how to ask an administrator for an MCP server when local tool management is blocked. Updates arrive when the app refreshes, including on reload or its periodic configuration refresh.