Hydrogen Desktop

Summary

HD's in-container screenshot capture is completely broken while HD simultaneously reports itself healthy. Both capture backends fail on every panel/target, even though probe says the browser SSE is alive and screenshot status says sharing is active. Observed 2026-07-10, control port 127.0.0.1:64338, window_mode: webview, sse_connections: 1.

pup (adom-desktop browser_screenshot) works perfectly against the same laptop at the same time — so the relay, the laptop, and Chrome are all healthy. The failure is isolated to HD's own capture pipeline.

Reproduction

# HD reports healthy:
$ adom-cli hydrogen probe
  browser_connected: true, sse_connections: 1, window_mode: "webview"
$ adom-cli hydrogen screenshot status
  sharing: { active: true, displaySurface: null }, availableScopes: ["panel","workspace"]

# SSE element-capture path — fails on EVERY scope/panel:
$ adom-cli hydrogen screenshot workspace --reason "..."
  error: Failed to capture workspace
$ adom-cli hydrogen screenshot panel --name "VS Code" --reason "..."     # a NATIVE panel, not a webview
  error: Failed to capture panel
$ adom-cli hydrogen screenshot panel --name "Wiki" --reason "..."         # a webview tab
  error: Failed to capture panel

# CDP path (POST /screenshot on the control port) — fails on EVERY target:
$ curl -s -X POST "$CTRL/screenshot" -d '{"target":"full","b64":true,"silent":true}'
  { "ok": false, "error": "No CDP page target matching '1420'", "path": "C:\\Users\\drew\\AppData\\Roaming\\hydrogen-desktop\\shots/full.png" }
$ ... -d '{"target":"shell",...}'   ->  same: "No CDP page target matching '1420'"

What's notable

1. Both independent backends fail — the SSE element-capture path ("Failed to capture ") AND the CDP path ("No CDP page target matching '1420'"). A capture-surface/sharing problem alone wouldn't take out the CDP path with a target-not-found error.
2. Not webview-specific — a native VS Code panel fails identically to a webview tab, so it isn't the OOPIF/background-tab class of issue.
3. HD's own health signals are green — probe (browser_connected true, sse_connections 1), screenshot status (sharing active), and capture/availability (recommended: sse, no recording) all say "safe to capture." So the health signals are misleading: they report ready while every capture fails.
4. The CDP error is the smell — No CDP page target matching '1420' looks like HD is attaching CDP to a stale/missing page target id (1420). The SSE path may be failing for a related reason (the frontend that would Element-Capture is gone/disconnected while sse_connections still counts 1 — a possibly-zombie connection).

Impact

Any AI/automation flow that verifies a UI in-container via adom-cli hydrogen screenshot is dead in the water and, worse, gets no actionable error — the health probes say everything's fine. Workaround is to fall back to pup (adom-desktop browser_screenshot), which requires the desktop bridge and doesn't cover HD-shell/VS-Code surfaces.

Suggested angles

• Investigate why the CDP target registry points at a non-existent page target ('1420') — stale target after a webview/window-mode transition?
• Make probe/screenshot status/capture/availability reflect the actual capturability (a health signal that says "safe to capture" while every backend fails is the core reliability bug here).
• If the SSE Element-Capture frontend is disconnected, sse_connections shouldn't report a live session.

Filed from a container build session (adom-delegate UI verification) where pup was the working fallback.