hydrogen.adom.inc/<user>/<env>/edit        <- top page (browser-extension reachable)
  └─ iframe  <user>-<env>-....adom.cloud    <- CROSS-ORIGIN (accessible:false)
       └─ iframe  (VS Code / code-server)    <- another layer
            └─ webview  (Claude Code panel)   <- the "ctrl esc to focus" input lives here

---
name: hydrogen-web-control
description: >
  What you CAN and (mostly) CANNOT drive in the Hydrogen web editor
  (hydrogen.adom.inc/<user>/<env>/edit) from the cloud, and why its embedded Claude
  Code panel input is unreachable by automation. Read before trying to type into a
  Hydrogen Claude tab. Trigger words: hydrogen editor, hydrogen web control, type
  into the claude tab, drive hydrogen, galliaApril editor, claude panel input.
---

# Hydrogen web control

The Hydrogen editor (`https://hydrogen.adom.inc/<user>/<env>/edit`) is a web app the
user runs in Chrome or Edge. You can reach its **top frame** via the browser extension
([native-browser-control](../native-browser-control/SKILL.md), remember
`"browser":"edge"` if it's in Edge). But its embedded **Claude Code panel input is
buried in nested cross-origin webviews and is NOT reachable by any automation** we have.
This skill exists so you don't burn a session rediscovering that.

## The structure (why the Claude input is unreachable)

```
hydrogen.adom.inc/<user>/<env>/edit        <- top page (browser-extension reachable)
  └─ iframe  <user>-<env>-....adom.cloud    <- CROSS-ORIGIN (accessible:false)
       └─ iframe  (VS Code / code-server)    <- another layer
            └─ webview  (Claude Code panel)   <- the "ctrl esc to focus" input lives here
```

What the top frame exposes: a single `textarea` with placeholder **"Plan/Build your
project"** (Hydrogen's own launcher), NOT the Claude chat input. The Claude input is
several cross-origin frames down.

## What FAILS (all tested, all dead ends)

- **nbrowser/CDP eval** (Chrome AND Edge): top-frame only. It can't cross into the
  cross-origin iframe, and nbrowser has **no frame-targeting** (allFrames/frameUrl/frame
  params are ignored). `iframe.contentDocument` -> `accessible:false`.
- **OS SendInput** (`desktop_click` + `desktop_type` + `desktop_press_key`, and the
  "ctrl esc to focus Claude" shortcut): reaches the browser and Edge's NATIVE UI (your
  text lands in Edge's *search box*, not Claude) but does NOT register in the webview
  editor. Always screenshot, you'll see the placeholder unchanged.
- **UIA** (`desktop_find_control`): the webview's shadow DOM isn't exposed; returns the
  document fallback, not the input.

## What WORKS

- Reading/driving the **top frame** (the "Plan/Build your project" textarea, page chrome)
  via `nbrowser_eval`. Set a textarea value with the native setter:
  `Object.getOwnPropertyDescriptor(HTMLTextAreaElement.prototype,'value').set.call(ta, text)`
  then dispatch `input`.
- **Screenshotting** the Hydrogen window (`desktop_screenshot_window`, background).
- Navigating the top page.

## If you need the Hydrogen Claude to run a prompt

You can't type it in programmatically. Options:
1. **Ask the user to paste the prompt** into that Claude tab (it's the one case where
   asking is correct, you genuinely cannot do it). If it's a galliaApril-env Claude in
   bypass mode, it has relay access and will drive Fusion/the browser itself, see
   [claude-control](../claude-control/SKILL.md).
2. **Do the work yourself** instead of delegating to that sibling, you have the same
   relay access it does.

The real unlock (flag it to whoever owns `adom-browser-extension`): **frame-targeted
eval** so CDP can address a nested webview's execution context.