claude.ai/code artifact viewer: HTML artifacts don't scroll in Safari (Chrome has ~1s dead zone)

Summary

Published HTML artifacts on the claude.ai/code artifact viewer cannot be scrolled in Safari. In Chrome, scrolling is dead for ~1 second after load and then starts working — suggesting scrollability depends on a post-load handshake that never completes in Safari.

Environment

• macOS (Darwin 25.5.0), Apple Silicon
• Safari: broken (content never scrolls)
• Chrome: works, but only after a ~1 s dead zone post-load
• Artifacts published from a Claude Code CLI session via the Artifact tool

Repro

1. From Claude Code, publish any HTML artifact taller than the viewport. A zero-CSS file reproduces it — literally <title> plus 80 <p> elements, no styles at all.
2. Open the artifact's claude.ai/code/artifact/<id> page in Safari.
3. Try to scroll (trackpad/wheel/keyboard).

Observed (Safari): the first viewport of content renders; scrolling never moves it.
Observed (Chrome): same page scrolls fine, but input is ignored for about a second after load.
Expected: content scrolls in all evergreen browsers as soon as it renders.

Diagnostics gathered (Chrome, via extension automation)

• The artifact renders in a sandboxed cross-origin iframe (sandbox="allow-scripts allow-same-origin allow-forms").
• The iframe is pinned to viewport height (960px, overflow: clip on the iframe, ancestors position:absolute/overflow:hidden), and the outer document's html/body are overflow:hidden with scrollHeight == clientHeight — the outer page can never scroll, so all scrolling must happen inside the iframe and appears to depend on the viewer's runtime wiring (the Chrome ~1 s delay looks like that handshake completing; Safari looks like it never does).
• Minor related quirk: while the one-time "Artifacts are private by default" onboarding popover is open, wheel input over the artifact produces broken rendering (content viewport blanks / snaps) until the popover is dismissed.

Impact

Any HTML artifact taller than one viewport is unreadable for Safari users it is shared with — no workaround inside the page itself (a zero-CSS page reproduces it, and a content-side height:100vh; overflow-y:auto wrapper did not help).