Tab-scoped recording resolved to monitor capture; require explicit source receipt and fail-closed scope

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed bug report

John Lauer · 1mo ago ·closed by Colby Knox

Environment at incident: adom-cli 0.5.16; Hydrogen 1.0.316 (development build 9ddcc472ed3ade811ae52126edd4e1fe60da871a-dirty); Adom Bridge 2.1.95; Windows host with WSL2 workspace. The current restarted Bridge is 2.1.96, not the incident version.

During a linked-board recording, adom-cli hydrogen recording start --share tab was intended to capture the work tab. The subsequent native recorder state reported monitor:primary, and the recorded file was a desktop monitor capture. We stopped and excluded that take from all shared edits. We are not attaching the recording or a monitor screenshot because it may contain unrelated desktop work.

A later direct /recording/native/start with an explicit Hydrogen window source returned and recorded that window successfully. This separates the requested share scope from the actual capture source. Please inspect the CLI-to-Hydrogen recording source selection path; the root cause has not been established.

Expected: a tab-scoped request either records that exact tab with a supported engine or refuses with an explicit capability hint. It must never silently widen to a monitor. The returned start receipt should state requested scope, resolved source, engine, and whether any fallback occurred. Recording skills and AI callers must inspect that receipt before proceeding, and keep wrong-target takes out of final videos.

This issue is distinct from adom/adom-cli#5, which concerns accepted webview navigation and panel snapshot lookup. No foreground change was requested for either action.

1 Reply

Colby Knox · 1mo ago

Shipped: adom-cli 0.5.18 (GH v0.5.18, wiki package 4.1.6). The CLI half of your expected behavior, exactly as specified:

Start receipt: every recording start response now carries _receipt with the requested share scope, the resolved capture surface (read back from the live sharing state after the accepted start, the same never-trust-the-accept doctrine as the navigation read-back), match, and fallback. The hint tells callers to inspect it before proceeding.
Fail-closed, never silently widen: on any mismatch (your exact case: requested tab, live surface reads monitor) the CLI STOPS the recording immediately, marks the partial take as excluded-from-use, exits non-zero, and names the re-request path (sharing request --share tab, then start again). If the stop itself fails, the output says to stop it manually NOW rather than pretending.
The honest gap: when the capture runs through the native engine, the browser sharing state can be unreadable from the CLI's vantage; the receipt then says resolved_surface null / match null and demands manual verification (screenshot the first seconds) before the take is used. That path cannot fail closed without a native-engine status surface to read.

Verification framing: this is code-level verified only. Exercising it live from this container would pop recording approval dialogs on the user's screen, so your next recording session is the real test; the receipt appears on every start either way.

Root cause routing: the source selection itself (tab request resolving to monitor:primary) spans Hydrogen's recording API and the native recorder engine, which is Adom Bridge's, so half of this one is in your own back yard: the incident's native state string is ab's recorder, ab 2.1.95 at the time. Added as item 5 to the Hydrogen-side bundle from #4/#5 (already handed to Colby): Hydrogen's recording surface should refuse a tab-scoped start it can only satisfy with a monitor source, and ab's native start should carry an explicit source receipt of its own. The CLI now guards the gap from its side either way.

Closing the CLI half; reopen if the receipt or the fail-closed stop misbehaves on your build.