Skip to main content
Desktop policies are rules you set in OpenWork Cloud for the OpenWork desktop app. They apply to members after they sign in to your organization. You can set a default for everyone, give specific members or teams their own policy, and choose what each team can do from the team’s Access tab.
Most desktop policy controls are paused while they are redesigned. You can still create and save policies and team access settings in Cloud, but the desktop app doesn’t apply most of them yet.The desktop app applies these today:
  • Model access: whether members can add their own AI providers. Set it in AI Gateway › AI Providers › Who can use models. Choose Only models you provide to limit members to your organization’s models. The Custom providers switch in a policy and Add AI providers on a team’s Access tab also affect model access.
  • Organization prompt suggestions: see Team prompt cards.
  • Required sign-in: this depends on how your organization’s desktop app is installed, not on a policy.
  • Allowed Desktop Versions: set it in Settings › General.
Everything else is saved but not applied. This includes the other switches (including Welcome Page), Restricted mode, computer-command rules, approved websites and other browsing limits, and blocking uploads and form submissions. Don’t rely on these to block anything today.

​
Who can manage policies

  • Owners and super-admins can create, edit, and delete policies, and change team access.
  • Admins can view policies and team access, but can’t change them.
  • Desktop policy management is part of the Enterprise plan.

​
What policies control

Each switch in the policy editor is designed to control one part of the desktop app. Apart from Custom providers, they don’t take effect yet.
  • Custom providers: adding and using models your organization didn’t set up in OpenWork Cloud.
  • Enable OpenCode Zen Models: using the built-in models from OpenCode.
  • Multiple workspaces: creating more than one workspace on a computer.
  • Control Settings: opening and changing the desktop app’s settings.
  • Manage Extensions: installing local extensions, skills, and MCP servers.
  • Built-in Extensions: using OpenWork’s built-in extensions, such as the browser, image, and local-provider extensions.
  • Alpha updates: choosing to get experimental Alpha updates.
  • Welcome Page: showing the Getting Started page to new users.
The Commands & browser section will control:
  • Run OS commands and Blocked command patterns: whether the agent can run commands on the computer, or which commands it can’t run.
  • Restrict browsing to approved sites and Approved websites: which websites the built-in browser can open.
  • Block browser uploads and form submissions: stopping the built-in browser from sending files or form data.
When a member matches more than one policy, switches combine: a switch is on if any matching policy turns it on. A Blocked choice on a team’s Access tab wins over any policy that allows the same thing.

​
Configure a policy

  1. Open app.openworklabs.com and choose your organization.
  2. Go to Manage › Desktop policies.
  3. Click New policy, or click Edit on an existing policy. The policy marked Default applies to everyone.
  4. Enter a Policy name and a Priority. When more than one policy matches a member, the higher priority decides which prompt suggestions they see.
  5. Under Policy mode, choose Custom or Restricted.
  6. Turn switches on or off, and fill in Commands & browser if you need it.
  7. To show your own suggested prompts, turn on Organization prompt suggestions. See Team prompt cards.
  8. Under Members and Teams, choose who the policy applies to.
  9. Click Create policy, or Save changes for an existing policy.
A few things to know:
  • You can’t rename the default policy or give it a priority. It always applies to everyone.
  • To pause a policy without deleting it, open it and click Disable. Click Enable to turn it back on.
  • To remove a policy, click Delete next to it in the list. You can’t delete the default policy.
  • Policies created from a team’s Access tab show Team access in the list. Click View team access to change them on the team’s page.

​
Restricted mode

Restricted turns off every switch except Welcome Page and locks them until you switch back to Custom. It is designed to give members a simple OpenWork: they can chat and use organization-approved skills, but can’t change settings, add providers, add workspaces, or install extensions. Because switches combine across policies, Restricted only locks members down when you apply it to the default policy. A targeted policy in Restricted mode doesn’t take anything away from other policies. Today, the only part of Restricted that takes effect is that it turns off Custom providers.

​
Approved websites

Approved websites are designed to limit the built-in browser to sites you choose. This control is paused and doesn’t block anything yet. To set approved websites for a team:
  1. Go to Members › Teams, open the team, and choose the Access tab.
  2. Expand Browse websites.
  3. Set Website access to Approved sites only.
  4. Enter a full website address, such as https://portal.example.com, and click Add site. Repeat for each site.
  5. Click Review changes, then Save permissions.
In the policy editor, turn on Restrict browsing to approved sites under Commands & browser, then enter one address per line in Approved websites. Keep these rules in mind:
  • Enter whole websites only, with no page paths.
  • Add subdomains and sign-in sites separately. https://portal.example.com doesn’t include https://docs.portal.example.com.
  • You can add up to 100 sites.
  • Blocked, or an empty list, blocks all browsing.
Approved web origins in Settings › General is a different feature. It lets websites you approve use a member’s OpenWork sign-in. It doesn’t limit which sites members can browse.

​
Team access

Each team has an Access tab where you choose what its members can do. To open it, go to Members › Teams, open the team, and choose Access. Under What this team can do, set each option to Allowed or Blocked:
  • Browse websites: Website access (All websites, Approved sites only, or Blocked) and Upload files & submit forms.
  • Run computer commands: Computer commands. To block only some commands, open Advanced: block specific commands.
  • Tools & connections: Add local tools, skills & MCP servers and Use built-in extensions.
  • AI setup: Add AI providers and Use OpenCode models.
  • Settings, workspaces & updates: Create more workspaces, Change app settings, and Try experimental updates.
Click Preview member experience to see a summary of what members of the team will be able to do. When you’re done, click Review changes, check the list, and click Save permissions. Allowing something here doesn’t override a block from another team or from your organization. Of these options, only Add AI providers takes effect today, as part of model access. Members can see their permissions in the desktop app under Settings › Account › App permissions. The list is read-only. It shows what the app applies right now, so paused controls show as Allowed. The Plugins & connections list lower on the same tab shows which plugins and connections the team can use. That list is separate from desktop policies and works today.
Enforcement switch. Enforcement is controlled by DESKTOP_POLICY_ENFORCEMENT_ENABLED in packages/types/src/den/desktop-policies.ts, currently false. Den still stores and resolves every policy. Before the desktop app uses the config, desktopCapabilityConfig() removes execution and every policy key except allowCustomProviders and showWelcomePage. Prompt suggestions and allowedDesktopVersions pass through. The desktop app does not currently read showWelcomePage. Model access never blocks startup, sign-in, or chat: the app uses the last known setting, and allows providers when no setting is known.Model access storage. Only models you provide is stored as allowCustomProviders: false in the default desktop policy. Admins may still add their own keys on their device is stored as a policy for the admin role.How switches combine. If an organization has no policies, every switch is on. Otherwise every switch starts off, and any true in the default policy or a matching member, team, or role policy turns it on. Explicit false values from a team’s access settings (access.capabilities) are applied afterward and win.Commands and browsing. Stored under execution in the policy document:
  • commands is allow or deny. Any matching policy with deny blocks commands.
  • blockedCommands are patterns that use * for any text. Patterns from all matching policies are added together, up to 100 per policy.
  • browserOrigins: if the field is left out, there is no website restriction. An empty list ([]) blocks every website. Lists intersect across the default policy and all matching member, team, and role policies, so a site must appear in every list that exists.
  • blockBrowserUploads: any matching policy with true turns it on.
Approved website format. Each entry is an exact HTTP or HTTPS origin: scheme, hostname, and port. Default ports normalize, so https://portal.example.com:443 equals https://portal.example.com. http://portal.example.com and https://portal.example.com:8443 are different origins. Paths, credentials, queries, and fragments are rejected. Wildcards are not supported.Designed behavior when enforcement resumes. Website rules cover every built-in browser request, including navigation, redirects, frames, scripts, and images. A resource from an unapproved origin is blocked even on an approved page. While approved sites are set, the engine’s built-in websearch and webfetch tools are denied; third-party MCP search or fetch tools are not filtered. Block browser uploads and form submissions blocks WebSocket (ws:/wss:) connections, requests with upload data, and methods other than GET, HEAD, and OPTIONS. GET-based forms can still send data to approved sites. None of these controls are device-wide data-loss prevention: allowed computer commands and third-party connections can use other network routes.Refresh. The desktop app caches the last config it received and applies it on launch. It fetches a fresh config when the member signs in, when the Cloud account or active organization changes, and every hour.