feat(connect): report desktop connection incidents

[reachjalil]

Value

The desktop currently collapses intermittent OpenWork Connect failures to “disconnected.” If the user was offline, behind a failing VPN/proxy, hitting TLS/DNS trouble, receiving an HTTP error, or losing the MCP during initialize/tools discovery, the evidence is gone by the time support joins them.

This PR gives users who explicitly opt in a bounded, user-visible incident reporter:

• records only failed Connect maintenance attempts and the later recovery transition
• keeps a maximum 24-hour / 500-event local retry queue when Den is unreachable
• extracts only allowlisted network classes, HTTP status, lifecycle phase, retryability, duration, versions, and opaque request IDs
• creates a stable random per-install client UUID only after opt-in
• adds the correlation UUID to the managed openwork-cloud MCP configuration only after opt-in
• forwards that correlation header on local server direct initialize/initialized/tools-list probes
• exposes reporting status and client UUID in Connect advanced diagnostics
• provides a Privacy preference that is disabled by default; disabling it clears the queue and client UUID
• mirrors sanitized queue/delivery events into the existing local inspector pattern

This makes failures supportable for consenting users without collecting prompts, tokens, URLs, tool payloads, or member identity.

Opt-in guarantee — disabled by default

A fresh install, an upgrade with no stored diagnostics choice, a missing preference, or malformed preference data all resolve to disabled. Until the user explicitly enables Share desktop Connect diagnostics, the desktop:

• creates no diagnostics client UUID
• stores no diagnostics queue or failure state
• adds no x-openwork-connect-client correlation header
• makes no diagnostics report request to Den

Only the exact stored value connectionDiagnosticsEnabled: true enables reporting. Turning the preference off immediately clears the local UUID, retry queue, and failure state. This behavior fails closed when local storage is unavailable or unreadable.

Scope

This is the desktop/local-server slice only. It does not modify Den, the diagnostics service, plugins, or OpenCode core. The MCP transport being diagnosed is Streamable HTTP over DNS/TCP/TLS; there is no UDP path here.

The small packages/types incident contract is identical to the contract in the diagnostics and Den sibling PRs so this branch independently builds from dev. Merge this after the diagnostics and Den slices; the identical contract patch then drops out.

Checks on the current opt-in revision

• desktop diagnostics reporter tests — 7 passed, including fresh/missing/malformed preference coverage proving zero identifier, queue, header, and request
• desktop typecheck — passed
• git diff --check — passed

Earlier feature-branch checks, before the opt-in follow-up commit:

• shared types build — passed
• local server Cloud MCP health tests — 16 passed
• local server typecheck — passed
• desktop production build — passed with existing use memo and chunk-size warnings

Manual verification

After the Den slice is deployed:

1. Open Preferences → Privacy and confirm Share desktop Connect diagnostics is off by default.
2. Confirm Connect → Advanced diagnostics shows reporting disabled and no client UUID.
3. Fault the managed Cloud MCP path and run Test now; confirm no diagnostics request or local diagnostics state is created.
4. Explicitly enable Share desktop Connect diagnostics, note the newly created random client UUID, fault the MCP path, and test again.
5. Restore the path and confirm the failure and recovery reach the diagnostics timeline under the same pseudonymous client.
6. Disable reporting and confirm the local client UUID and queued state disappear.

No production deployment or live on-prem customer verification is included.

Split 3 of 3. Merge after the diagnostics portal and Den relay.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 24, 2026 7:30am

[vercel]

@reachjalil is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[reachjalil]

PR chain: #3072 Diagnostics portal → #3073 Den relay → #3074 desktop client. Each PR targets dev and carries the identical small shared incident contract so it can build independently; runtime files do not overlap. After #3072 and #3073 merge, update/rebase this PR so the contract-only overlap disappears before review/merge.