Skip to main content
Use this page when OpenWork reaches the wrong server, cannot complete TLS, is blocked by a proxy, or needs proof that Den can reach an approved diagnostic origin. For non-network runtime, MCP, and stale-tool problems, use Diagnostic prompts.

Windows desktop network doctor

scripts/support/openwork-doctor.ps1 is a Windows PowerShell 5.1-compatible, no-admin, read-only report for customer IT. It checks DNS, TCP 443, the live TLS certificate chain with SslStream, served certificates with openssl when available, WinHTTP/.NET proxy settings, PowerShell/OS version, and NODE_EXTRA_CA_CERTS. Run it directly from the raw repository URL when the machine can reach GitHub:
If raw download is blocked, copy scripts/support/openwork-doctor.ps1 to the machine through your approved offline channel and run:
Use your Den web origin for -WebUrl. Use the separate Den API origin only if your deployment publishes one; in a single-origin deployment, the API path is usually behind the web origin’s /api/den proxy.

Interpreting common verdicts

Cloud catalog diagnostic trust

Settings → Debug includes a cloud catalog diagnostic that probes the managed openwork-cloud MCP entry and verifies that Cloud exposes exactly search_capabilities and execute_capability. For self-hosted Den origins, set OPENWORK_AGENT_DIAGNOSTICS_TRUSTED_ORIGINS before OpenWork launches:
The value is a comma-separated list of bare origins: scheme, host, and optional port only. Entries must use https: except loopback origins, which may use http:. If the Den origin is not trusted, the diagnostic is skipped and sends no credentialed request to that untrusted origin. Cloud MCP itself is unaffected; this variable only controls the diagnostic probe. Set it in the launcher, MDM profile, service wrapper, or shell environment before launch because the in-app environment store strips OPENWORK_* and OPENCODE_* keys.

Den outbound diagnostic

Den can run an optional, admin-triggered outbound diagnostic from the Den process. It exercises the real container DNS, proxy, TLS trust, firewall, service mesh, and NetworkPolicy path.
  • The default diagnostics origin is https://diagnostic.openworklabs.com.
  • A workspace owner or super-admin starts the check; it is not a background dependency for Den.
  • The diagnostic token must be synthetic and at least 24 characters. Do not use provider or customer credentials.
  • To use an internal diagnostics origin, deploy the diagnostics app at an internally reachable supported runtime/origin, then set DEN_DIAGNOSTICS_ORIGIN and DEN_DIAGNOSTICS_BEARER_TOKEN for Den. The service README currently documents its runtime and retention model; do not assume a generic Kubernetes package unless your deployment path has been validated.
On Node.js 24.5 or newer, Den proxy configuration belongs in process-start environment such as NODE_USE_ENV_PROXY=1, HTTPS_PROXY, and NO_PROXY. Use NODE_EXTRA_CA_CERTS or Helm customCa when TLS inspection uses a private root. See Certificate trust and proxies.