> ## 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.

# Network diagnostics

> Diagnose DNS, TLS, proxy, catalog, and Den outbound issues in locked-down OpenWork deployments.

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](https://openworklabs.com/docs/start-here/troubleshooting/diagnostic-prompts.md).

## 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:

```powershell theme={null}
powershell -NoProfile -ExecutionPolicy Bypass -Command "`$p=Join-Path `$env:TEMP 'openwork-doctor.ps1'; Invoke-WebRequest -UseBasicParsing 'https://raw.githubusercontent.com/different-ai/openwork/dev/scripts/support/openwork-doctor.ps1' -OutFile `$p; & `$p -WebUrl 'https://openwork.example.com' -ApiUrl 'https://api.openwork.example.com' -ExpectedIssuerMatch 'DigiCert'"
```

If raw download is blocked, copy `scripts/support/openwork-doctor.ps1` to the machine through your approved offline channel and run:

```powershell theme={null}
powershell -NoProfile -ExecutionPolicy Bypass -File .\openwork-doctor.ps1 -WebUrl 'https://openwork.example.com' -ApiUrl 'https://api.openwork.example.com' -ExpectedIssuerMatch 'DigiCert'
```

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

| Verdict | What it usually means | First fix to check |
| - | - | - |
| `LIKELY TLS INTERCEPTION` | The leaf issuer is an internal or proxy CA instead of the expected public issuer. | Allowlist the OpenWork hosts through the proxy, or install the enterprise root in every OpenWork trust surface that needs it. |
| `LIKELY MISSING INTERMEDIATE OR UNTRUSTED ROOT` | The server may be serving a leaf without the intermediate, or the machine lacks the issuing root. | Fix the server `fullchain`/certificate bundle first, then verify client trust. |
| `MISSING INTERMEDIATE CONFIRMED BY OPENSSL` | OpenSSL could not build the served chain. | Replace the server certificate bundle with a complete chain. |
| `LIKELY DNS ISSUE` | The hostname does not resolve on that machine. | Check VPN state, split-horizon DNS, and whether the internal hostnames exist. |
| `PROXY DETECTED` | WinHTTP or .NET routes the URL through a proxy. | Verify proxy authentication, host allowlisting, and expected system proxy behavior. |

## 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:

```bash theme={null}
OPENWORK_AGENT_DIAGNOSTICS_TRUSTED_ORIGINS=https://openwork.example.com
```

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.

```dotenv theme={null}
DEN_DIAGNOSTICS_ORIGIN=https://diagnostics.example.internal
DEN_DIAGNOSTICS_BEARER_TOKEN=<24-or-more-character-synthetic-token>
```

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](https://openworklabs.com/docs/start-here/certificate-trust-and-proxies.md).

## Related diagnostics

* [Outbound network access](https://openworklabs.com/docs/start-here/outbound-network-access.md) lists the destination inventory and what breaks when a host is blocked.
* [Private network deployment](https://openworklabs.com/docs/start-here/private-network-deployment.md) explains the common VPN/private Den topology and internal MCP policy switch.
* [Diagnostic prompts](https://openworklabs.com/docs/start-here/troubleshooting/diagnostic-prompts.md) covers non-network runtime, MCP, and stale-tool debugging.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.