# What Desktop Policies Can Be Configured Through OpenWork Den for Organizations?

> Explore eight desktop policies configurable with OpenWork Den. Manage AI providers, workspace limits, extensions, and updates to control user features in the OpenWork desktop app.

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: how-to-guide
- Published: 2026-08-09

---

**OpenWork Den allows administrators to configure eight granular desktop policies—including controls for custom AI providers, workspace limits, extension management, and update channels—that determine which features are available to users in the OpenWork desktop application.**

OpenWork Den functions as the organization-level control plane for the OpenWork ecosystem. Through its centralized policy engine, administrators can enforce security, compliance, and workflow standards by defining desktop policies that restrict or enable specific capabilities within the local OpenWork desktop client. These policies are defined in the shared types package and exposed through the Den API, allowing programmatic management of the end-user experience.

## Policy Catalog and Default Values

The canonical list of configurable desktop policies is defined in **[`packages/types/src/den/desktop-policies.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/den/desktop-policies.ts)** (lines 14-67). Each policy is represented as a boolean flag with a safe default value of `true`, meaning features are opt-out by default. Organizations can override these defaults to restrict specific functionality.

The eight available policy controls are:

- **`allowCustomProviders`** — Controls whether users may add AI models that are not deployed through OpenWork Cloud. When disabled, users are restricted to organization-approved providers only.
- **`allowZenModel`** — Governs access to the built-in OpenCode Zen models shipped with the desktop application.
- **`allowMultipleWorkspaces`** — Determines if users can create or configure more than one workspace on a single machine.
- **`allowControlSettings`** — Regulates permission to open the desktop application's **Settings** UI and modify local configuration.
- **`allowManageExtensions`** — Controls the ability to install, update, or remove local extensions.
- **`allowBuiltInExtensions`** — Manages visibility and use of OpenWork's built-in extensions, including the browser, image processing, and local provider tools.
- **`allowAlphaUpdates`** — Controls opt-in access to experimental Alpha desktop releases.
- **`showWelcomePage`** — Toggles the display of the "Getting Started" splash page for new users.

Each policy definition includes an identifier, human-readable name, description, user-facing notice, and default value as implemented in the [`desktop-policies.ts`](https://github.com/different-ai/openwork/blob/main/desktop-policies.ts) schema definitions.

## Policy Schema and Effective Evaluation

Policy values are validated against a Zod schema (`desktopPolicyValueSchema`) that maps each policy ID to an optional boolean. The system calculates **effective policies** for individual users by merging organization defaults with specific assignments.

The default policy state is derived from the `defaultValue` field of each policy definition (`desktopPolicyDefaults`). When computing the effective policy for a user, the system uses the `calculateEffectiveDesktopPolicy` function (lines 311-339 in [`desktop-policies.ts`](https://github.com/different-ai/openwork/blob/main/desktop-policies.ts)) to perform a three-way merge:

1. Initialize all flags to `false`.
2. Apply the organization's **default policy** (or a generated "all true" policy if no organization policies exist).
3. Overlay any **assigned policies** (member, team, or role-specific), where a single `true` value from any assignment enables the feature for that user.

This permissive overlay model ensures that if any assigned policy grants a permission, the user retains that capability, while explicit restrictions in higher-priority policies can disable features.

## Den API Endpoints for Policy Management

The Den API implements full CRUD operations for desktop policies in **[`ee/apps/den-api/src/routes/org/desktop-policies.ts`](https://github.com/different-ai/openwork/blob/main/ee/apps/den-api/src/routes/org/desktop-policies.ts)**. All mutation endpoints require the `desktopPolicies` Enterprise plan entitlement and enforce strict role-based permissions.

| Method | Endpoint | Permission | Description |
|--------|----------|------------|-------------|
| `GET` | `/v1/desktop-policies` | `orgRoleRoute(["admin"])` | Lists all policies for the organization, including the definition catalog and current assignments. |
| `POST` | `/v1/desktop-policies` | `orgRoleRoute(["super-admin"])` | Creates a new policy with specific boolean values, priority, and assignments to members, teams, or roles. |
| `PATCH` | `/v1/desktop-policies/:desktopPolicyId` | `orgRoleRoute(["super-admin"])` | Updates policy name, enabled status, priority, values, and assignments. |
| `DELETE` | `/v1/desktop-policies/:desktopPolicyId` | `orgRoleRoute(["super-admin"])` | Soft-deletes a policy. The default policy cannot be deleted. |

Input validation is performed against `desktopPolicyDocumentWriteSchema`, ensuring that only valid policy IDs and boolean values are persisted.

## Assignment Model and Permissions

Policies support granular assignment to specific principals within the organization. The assignment model, stored in the `DesktopPolicyMember` table (defined in **[`ee/packages/den-db/src/schema/desktop-policies.ts`](https://github.com/different-ai/openwork/blob/main/ee/packages/den-db/src/schema/desktop-policies.ts)**), supports three target types:

- **Specific members** — Individual users identified by `memberIds`.
- **Teams** — Groups identified by `teamIds`.
- **Roles** — Organizational roles including `owner`, `admin`, and `member`.

The `loadDesktopPolicies` helper joins policy records with their assignments to build comprehensive response objects. Priority values determine evaluation order when multiple policies apply to a single user, with higher-priority policies evaluated last to ensure their settings take precedence.

## Implementation Examples

### Creating a Restrictive Policy

To create a policy that limits workspace creation and custom providers for specific members:

```bash
curl -X POST https://api.openworklabs.com/v1/desktop-policies \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "policyName": "Restricted Workspaces",
    "policy": {
      "allowMultipleWorkspaces": false,
      "allowCustomProviders": false
    },
    "memberIds": ["member_abc123"],
    "roles": ["member"]
}'

```

This request follows the `desktopPolicyWriteSchema` defined in the types package and requires super-admin privileges.

### Updating Policy Values

To modify an existing policy to additionally disable Alpha updates:

```bash
curl -X PATCH https://api.openworklabs.com/v1/desktop-policies/dp_456def \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "policyName": "Restricted Workspaces – Updated",
    "policy": {
      "allowMultipleWorkspaces": false,
      "allowCustomProviders": false,
      "allowAlphaUpdates": false
    },
    "isEnabled": true
}'

```

### Calculating Effective Policies in Client Applications

Desktop applications fetch effective policies at startup and use the shared calculation logic to determine feature visibility:

```ts
import { calculateEffectiveDesktopPolicy } from "@openwork/types/den/desktop-policies";

const effective = calculateEffectiveDesktopPolicy({
  orgPolicyCount: desktopPolicies.length,
  defaultPolicy: desktopPolicies.find(p => p.isDefault)?.policy,
  assignedPolicies: desktopPolicies.flatMap(p => p.assignments.map(a => ({
    id: a.id,
    priority: p.priority,
    createdAt: a.createdAt,
    policy: p.policy,
  }))),
});

if (!effective.allowCustomProviders) {
  // Hide UI for adding custom providers
  console.log("Custom providers disabled by organization policy");
}

```

### Fetching Policies via API

To retrieve the current policy set for an organization:

```ts
async function getEffectivePolicy(orgId: string, token: string) {
  const res = await fetch(`https://api.openworklabs.com/v1/desktop-policies?org=${orgId}`, {
    headers: { Authorization: `Bearer ${token}` },
  });
  const { desktopPolicies, definitions } = await res.json();
  // Merge definitions with policy values to compute effective permissions
  return calculateEffectiveDesktopPolicy({
    orgPolicyCount: desktopPolicies.length,
    defaultPolicy: desktopPolicies.find(p => p.isDefault)?.policy,
    assignedPolicies: desktopPolicies.flatMap(p => p.assignments.map(a => ({
      id: a.id,
      priority: p.priority,
      createdAt: a.createdAt,
      policy: p.policy,
    }))),
  });
}

```

## Summary

- **Eight boolean policies** control core desktop functionality, including AI provider access, workspace management, extensions, and application settings.
- **Default values** are defined in [`packages/types/src/den/desktop-policies.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/den/desktop-policies.ts) with all features enabled (`true`) unless restricted.
- **Effective policies** are calculated using `calculateEffectiveDesktopPolicy`, merging defaults with member, team, and role assignments.
- **API access** requires Enterprise entitlements, with super-admins managing policy CRUD operations and admins viewing configurations.
- **Assignment granularity** supports targeting individual members, teams, or organizational roles with specific policy overrides.

## Frequently Asked Questions

### How does OpenWork Den resolve conflicts when a user has multiple policy assignments?

OpenWork Den uses a permissive evaluation model where the `calculateEffectiveDesktopPolicy` function initializes all flags to `false`, applies the default policy, then overlays assigned policies in priority order. If any assigned policy sets a flag to `true`, the user retains that permission. This ensures that explicit grants override restrictions unless carefully prioritized.

### What permissions are required to manage desktop policies in OpenWork Den?

Viewing desktop policies requires **admin** role membership (`orgRoleRoute(["admin"])`), while creating, updating, or deleting policies requires **super-admin** privileges (`orgRoleRoute(["super-admin"])`). Additionally, the organization must have the `desktopPolicies` Enterprise plan entitlement enabled to access policy management features.

### Can desktop policies restrict users from accessing the OpenWork desktop settings?

Yes. The **`allowControlSettings`** policy specifically controls access to the desktop application's Settings UI. When set to `false`, users cannot open or modify application configuration through the graphical interface, allowing organizations to enforce standardized deployments and prevent configuration drift.

### Where are desktop policy assignments stored in the OpenWork architecture?

Policy assignments are persisted in the `DesktopPolicyMember` table within the Den database schema, defined in **[`ee/packages/den-db/src/schema/desktop-policies.ts`](https://github.com/different-ai/openwork/blob/main/ee/packages/den-db/src/schema/desktop-policies.ts)**. This table links policies to members, teams, or roles, and is joined with policy definitions by the `loadDesktopPolicies` helper in the Den API routes to generate effective policy responses.