> ## 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. # Installer delivery > Choose how the install page delivers standard OpenWork desktop installers. The install page (`/install`) helps members install the standard OpenWork desktop for their Den organization: they sign in, download, then sign in to the app with the same account. Den does not build a customer-specific installer or wrap the installer in a ZIP. The implementation and security details remain in the repository's [Desktop install guide](https://github.com/different-ai/openwork/blob/dev/docs/org-install-links.md#installer-delivery). ## Delivery matrix | Deployment style | Download behavior | Required client access | | - | - | - | | Internet-connected | Den checks the signed-in member's organization, then redirects the browser to the exact GitHub release asset under `OPENWORK_INSTALLER_RELEASE_REPO` for the resolved version (see [Which version is installed](#which-version-is-installed)). | Den web/API, `github.com`, `release-assets.githubusercontent.com`, and `objects.githubusercontent.com` for legacy or rollback paths. | | Semi-air-gapped installer delivery | Den streams the matching standard installer from `OPENWORK_INSTALLER_ARTIFACTS_DIR`. | Den web/API only for installer download. Desktop runtime dependencies may still need internet unless mirrored or disabled. | | Fully internal installer delivery | Same mounted-artifact path, with Den web/API and installer bytes available entirely inside the isolated network. | Internal Den web/API only for installer download. Full product isolation still requires the broader checklist in [Air-gapped deployment](https://openworklabs.com/docs/start-here/air-gapped-deployment.md). | ## Mounted artifact behavior When `OPENWORK_INSTALLER_ARTIFACTS_DIR` points at a mounted directory and the expected file exists, Den streams that file directly. It does not fetch from GitHub, cache on first request, rewrap, ZIP, or hold the whole installer in memory. The expected filename depends on the deployment. A self-hosted Den (single-org mode, the default) serves the enterprise distribution; the hosted multi-org OpenWork Cloud serves the cloud distribution. The install page never serves the public `openwork--` filenames. The version in the filename is the resolved release tag without a leading `v`: * `openwork-enterprise-mac-arm64-.dmg` * `openwork-enterprise-mac-x64-.dmg` * `openwork-enterprise-win-x64-.exe` * `openwork-enterprise-linux-x86_64-.AppImage` * `openwork-enterprise-linux-arm64-.AppImage` On hosted OpenWork Cloud the prefix is `openwork-cloud-` instead of `openwork-enterprise-`. A mounted file with any other name is ignored and the request falls through to the GitHub redirect. `OPENWORK_INSTALLER_RELEASE_REPO` controls the GitHub redirect path when Den does not find a mounted artifact. It is not an internal artifact registry setting. ## Which version is installed Den resolves one release version per download request, in this order: 1. If the organization's `allowedDesktopVersions` desktop policy is set, the highest listed version wins. This is the way to pin a fleet or to opt into a newer desktop than the Den itself. 2. Otherwise, if `OPENWORK_INSTALLER_RELEASE_TAG` is set on Den API, that tag wins. 3. Otherwise, a self-hosted Den running a published release image installs its own release version (the `version` reported by `GET /health` on Den API), so a self-hosted control plane never hands out a desktop newer than itself by default. Hosted OpenWork Cloud, and Den builds without a release version, install the latest published stable release instead. Mounted artifacts must match the resolved version. When you rely on the default in step 3, place the files for the Den release you run; when you set a policy or an override, place the files for that version. For multi-replica Den API deployments, mount the same read-only PVC at the same path on every replica. Installer bytes must be equally visible to each replica. ## One-origin steady state For normal signed-in desktop traffic, prefer one desktop-facing Den web origin. The desktop derives API and MCP paths through that origin's `/api/den` proxy. If `DEN_API_PUBLIC_URL` is configured as a separate API origin, browsers downloading from the install page and external MCP clients that use the published MCP URL must reach it. This does not mean every steady-state desktop request needs both origins in the single-origin topology. ## Managed fleets: enterprise binary + MDM This page covers install-link delivery of the standard installer. Managed fleets typically skip the install-link handoff entirely: deploy the **OpenWork Enterprise binary** through MDM and write `desktop-bootstrap.json` during provisioning so the first launch already targets your Den server. See [Enterprise desktop deployment](https://openworklabs.com/docs/start-here/enterprise-desktop-deployment.md) for the artifact names, bootstrap file reference, and what MDM does not need to push. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.