Adom Hydrogen (macOS)

ah 0.1.429 on macOS (build 5c34edd9, WKWebView) · Claude Code extension 2.1.319 (preferredLocation: panel) · adom/core 4.15.3

@kyle investigation below. The root cause is narrowed but not proven. I could not observe the live panel, because /eval-in and /eval return CDP not available on Mac.

Symptom

Scroll up in a Claude session to read older messages. When Claude posts a new response, status or command, the view gets pulled back to the bottom, so you have to keep fighting it to read.

Findings

1. No Adom code touches this. webview/index.js has no Adom references, and neither adom.adom-vscode nor adom.adom-agent-bar contains scroll code. All the scroll logic is Anthropic's. What Hydrogen adds is the engine (WKWebView).

2. Plain new output should not yank. 2.1.319 keeps a "scrolled away" flag, set by wheel, touch, keys or upward scroll. While that flag is true, the follow logic does nothing. I ran the extension's real J7t and V8e functions, extracted verbatim, against a fake scroller:

3. Prime suspect (code path confirmed, not confirmed as what's happening here): the scroll handler runs n.current = !T || S === "up", where T means "at bottom". If the transcript shrinks enough to clamp the view to the bottom, with no upward input in the last 300ms, the flag is cleared and the panel goes back to following. Any status or tool row that collapses or disappears could do this, which would fit "status/command" being the trigger. What I have not shown is whether the transcript shrinks that far in real use, especially when reading far up.

4. Other paths that deliberately force the bottom:

• Sending a prompt (claudeCode.scrollToBottomOnSend, default true).
• A permission or question prompt appearing, and again after answering it.
• The first message load. This setup auto-approves tool permissions, so prompts are unlikely to explain it here.

5. Untested WebKit factor: the extension's CSS sets no overflow-anchor and has its own anchoring only in some paths. It may be relying on Chromium's built-in scroll anchoring, which WebKit may not provide, so transcript changes above the viewport could behave differently in Hydrogen on Mac. This is from what I know of WebKit, not from a test here. The harness uses a fake scroller, so it says nothing about WebKit either.

6. Version caveat: 2.1.319 was installed today at 16:01 (it was 2.1.317 earlier this week), and an open panel may still be running an older build until reload. The complaint may partly predate this logic.

Tests that would settle it

1. Same session in Chrome versus Hydrogen on Mac. If only Hydrogen yanks, it's WebKit. If both do, it's the extension logic.
2. Web Inspector on a dev build: log scrollTop, scrollHeight and the flag on each scroll event while streaming. A scrollHeight drop right before the jump confirms finding 3.
3. Far up versus just a little up. A yank from far up with no large shrink would rule out finding 3.

Upstream

This looks like a long-running upstream family, so a fix may belong with Anthropic if test 1 implicates the extension: #76350, #72117, #66833, #58767 (blames the 50px near-bottom threshold, which is still i0=50). I only saw these through search results and did not read each thread or confirm its current status.

The harness is a short Node script that extracts those two functions from webview/index.js at runtime. Drew can share it privately if it would help.