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:
scripts/support/openwork-doctor.ps1 to the machine through your approved offline channel and run:
-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 managedopenwork-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:
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_ORIGINandDEN_DIAGNOSTICS_BEARER_TOKENfor 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.
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.
Related diagnostics
- Outbound network access lists the destination inventory and what breaks when a host is blocked.
- Private network deployment explains the common VPN/private Den topology and internal MCP policy switch.
- Diagnostic prompts covers non-network runtime, MCP, and stale-tool debugging.