[juliusmarminge]

On the iPhone Duo, the header blur stopped short of the vertical bar on every screen, leaving a hard edge before the rail. System Settings carries the blur all the way across.

In iOS 26 the header's blur is the scroll view's own scroll-edge effect, drawn inside the scroll view. Duo columns pad their content away from the vertical bar, so every scroll view, and its blur, stopped there.

Change

The fix lives in one place, so no screen can get it wrong:

• Content: columns keep padding everything away from the bar, so nothing a screen renders can sit under it.
• Blur: NativeScrollViewMarker, the one way to register a header scroll view, now wraps it in a native view (T3ScrollEdgeBleedView). Where the view sits flush against a side safe area its column padded away, it widens the native UIScrollView under that band. On the right, the content stays exactly where React Native laid it out. It never touches JS, so folds move the blur and the content in one UIKit layout pass.
• Enforcement: lint rejects importing ScrollViewMarker from react-native-screens anywhere but the wrapper. A new screen gets the blur just by registering its scroll view, which it needs for header behavior anyway.
• Lists: the new t3code/require-registered-list-scroll rule reports a LegendList, AnimatedLegendList or KeyboardAwareLegendList without a scroll component, so a screen's list can't silently skip registration. Archived threads, open source licenses, pull request files, the file tree and the new-task picker now render through NativeScrollView. Lists nested in another scroll surface, in sheets, or in the non-native sidebar suppress the rule with a reason.

The Chats, Pull requests and PR reviewers screens moved from the raw marker to the wrapper. The Usage account page and the unavailable-thread screen now use ScreenScrollView, so their main scroll view is registered too. docs/internals/mobile-navigation.md records the constraint.

This needs a native build. Older builds without the view fall back to the previous behavior.

Stacked on #24644, which touches the same Settings files.

Before	After

How it stays out of React Native's way

• React Native sizes the scroll view's component view, and the UIScrollView inside follows it by autoresizing, so the widened frame survives React Native's layout updates.
• The component view's clipping is turned off while bleeding (the scroll view still clips its content). React Native only rewrites that when the overflow style changes.
• Fabric recycles scroll views, so the view puts everything back when it leaves the window, when its content is unmounted, and on dealloc.
• It searches only the few levels down to the scroll view and never walks into a scroll view's content.

Verification

iPhone Duo simulator, native build with the view:

• Folded and unfolded: Chats, the Pull requests list, pull request detail, a thread, and Settings pages.
• The blur reaches under the rail and the content stays inset. The theme grid layout is unchanged.
• Stress run: three cycles through all four tabs, scrolling the thread feed, pull-to-refresh, and folding and unfolding repeatedly. The app stayed up and logged no crash reports.

vp run check:changed passes, along with the React Compiler coverage, native, home and pull-request tests. swiftlint --strict is clean, and the lint rule was checked against a probe file.

Not checked:

• A bar on the left (a rotated Duo; the simulator doesn't rotate its panels). That path offsets the content with an inset, so a programmatic scrollTo could leave the content under a left-side bar until the next layout pass.
• iPad and iPhone with this native build. The view does nothing there, since no side safe area is padded away.

Claude Opus 5.5 in Claude Code, running in T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

🟡 Medium src/Stack.tsx:233

On iOS, SettingsArchive and SettingsOpenSourceLicenses render their LegendList rows beneath the Duo rail because this shared option removes their horizontal column padding without replacing it. Their lists do not use ColumnInsetContent, and automatic inset adjustment does not add the needed horizontal inset for these vertical lists; keep these routes padded until their list content applies the horizontal safe-area inset.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/mobile/src/Stack.tsx around line 233:

On iOS, `SettingsArchive` and `SettingsOpenSourceLicenses` render their `LegendList` rows beneath the Duo rail because this shared option removes their horizontal column padding without replacing it. Their lists do not use `ColumnInsetContent`, and automatic inset adjustment does not add the needed horizontal inset for these vertical lists; keep these routes padded until their list content applies the horizontal safe-area inset.

[juliusmarminge]

Outdated: the per-route nativeContentInsetHorizontally: false option (LISTS_UNDER_DUO_BAR) this points at is gone. Columns pad every screen again, so no content sits under the rail. The blur now reaches the rail through a native wrapper on NativeScrollViewMarker that only widens the scroll view (ff6615d). Archived threads and open source licenses also now register their lists through NativeScrollView, and the new t3code/require-registered-list-scroll lint rule reports any list that doesn't (b74ff40).

[macroscopeapp]

b74ff40757e resolves this, but it is not yet on this PR’s branch. At ff6615d9aef, these two lists still do not use NativeScrollView, so the finding remains until that commit is included.

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — This PR adds a new native iOS wrapper that changes existing scroll-view frames, insets, offsets, and clipping across multiple screens, and it introduces a lint suppression for the wrapper import. An unresolved Medium finding also reports Settings rows rendering beneath the Duo rail, so the change warrants human review.

Needs human approval because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.9 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	2	—	8	✅
Claude	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	21.2 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: ff6615d · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.