Skip to main content
OpenWork works best when customer IT approves outbound access by component. The canonical machine-readable source is docs/enterprise/outbound-access.json. CI guards that file with node scripts/check-outbound-access.mjs; this page is the published human-readable summary.

Minimum hosted desktop allowlist

For a practical OpenWork Cloud desktop install, allow TCP 443 to these hosts:
Common misses:
  • GitHub release downloads redirect away from github.com. Allow release-assets.githubusercontent.com, which is the current verified GitHub release-asset host, and objects.githubusercontent.com, which is kept for older clients and rollback paths.
  • registry.npmjs.org is used when packaged desktop builds start npx -y openwork-ui-mcp. If it is blocked, the desktop can still open, but UI-control MCP is unavailable.
  • models.openworklabs.com is the default OpenCode model catalog. Set OPENCODE_MODELS_URL to an approved internal mirror if the public catalog is blocked.

Desktop and local runtime destinations

code.claude.com and schemas.agentskills.io appear in source or schema metadata. They are findable in the manifest, but OpenWork does not fetch them for normal runtime behavior.

Before enterprise activation

An OpenWork Enterprise install that has not yet been linked to your organization makes no request outside the machine. Until the person enters the workspace address, the desktop does not probe app.openworklabs.com for runtime configuration, does not send analytics to us.i.posthog.com, does not check github.com for updates or downloads (the one exception is an install whose architecture does not match the machine, which looks up the correct download), does not fetch OpenWork Cloud inventory, and on Windows and Linux does not download the Chromium spellchecker dictionary from redirector.gvt1.com. The first outbound request goes to the workspace address that was entered. Analytics and update checks start only after activation completes and your desktop policy has been read once.

Den runtime destinations

Approve Den separately from desktop clients. A self-hosted Den behind VPN or inside Kubernetes uses the server network, not the user’s laptop network. For Google Workspace, Den calls oauth2.googleapis.com for token exchange and refresh, www.googleapis.com for profile, Calendar, and Drive APIs, and gmail.googleapis.com for Gmail APIs. These are Cloud server destinations, not local Google Workspace API requirements on the desktop. The client manifest keeps only the browser destinations accounts.google.com and mail.google.com. Set up Google through Connect your services, not local OAuth environment variables.

Deployment and image-pull destinations

For fully isolated deployments, also mirror installer artifacts, npm packages used by npx, and the model catalog. See Air-gapped deployment and Installer delivery.

Opt-in provider and connection hostnames

These hosts are only needed when the corresponding feature, provider, connection, or import path is enabled: The JSON manifest remains the ownership point for exact host metadata, requirement level, override name, and blocked effect. Use this page for review conversations and the JSON file for automation.