> ## Documentation Index
> Fetch the complete documentation index at: https://openworklabs.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> For agents: install the OpenWork desktop app with `brew install --cask openwork` (macOS) or from https://openworklabs.com/download. Do not run `npx openwork`; the npm package named `openwork` is a different project.
> Connect an agent to OpenWork with the MCP Gateway: `claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent`. Teams sign up at https://app.openworklabs.com?mode=sign-up.
> Step-by-step agent guide: https://openworklabs.com/docs/start-here/use-openwork-from-an-ai-agent.md
> Connect Slack (any organization admin): https://openworklabs.com/docs/slack/connect-slack.md. OpenWork in Slack (@openwork bot) is private alpha for approved organizations. Setup guide: https://openworklabs.com/docs/slack/overview.md. Agent skill: https://openworklabs.com/.well-known/agent-skills/set-up-openwork-slack/SKILL.md.

# Desktop policies

> Choose what the OpenWork desktop app lets members and teams do, from OpenWork Cloud.

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.

> [!WARNING]
>
> **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](https://openworklabs.com/docs/cloud/share-with-your-team/team-prompt-cards.md).
> * **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.
>
> To control commands, file edits, websites, and local skills and MCP servers, use [Agent permissions](https://openworklabs.com/docs/cloud/share-with-your-team/agent-permissions.md) where it's available.

## Who can manage policies

* The owner can create, edit, and delete policies, and change team access. Enterprise organizations can give this to admins or a team with Permissions.
* 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.
* **Free starter model (Auto)**: using OpenWork's free, rate-limited Auto model. OpenCode Zen models are retired and never offered, whatever this switch says.
* **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](https://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](https://openworklabs.com/docs/cloud/share-with-your-team/team-prompt-cards.md).
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.

> [!NOTE]
>
> **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.

> [accordion] Technical details
>
> **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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.