Repository navigation
[Bug]: iPad sidebar hides the newest thread under the header on iPadOS 18 #22543
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/mobile
Steps to reproduce
- On an iPad running iPadOS 18 (any iPad that can't run iPadOS 26), install T3 Code 2.0 from the App Store and connect an environment with more than a handful of threads.
- Use the iPad in landscape so the app shows the split layout: thread sidebar on the left, "Threads | Pull requests" / "Select a thread" on the right.
- Look at the top of the sidebar thread list, then pull the list down and release it.
Expected behavior
The newest thread is the first row, sitting just below the Search field, and the list rests there after a pull.
Actual behavior
The first row is never visible at rest. The list starts under the sidebar header: the newest thread sits behind the title bar and Search field, and the second row is cut off directly under Search. Pulling down shows the first row, but releasing snaps it back behind the header. When the list is shorter than the column it can't scroll at all, only rubber-band, so the first thread can't be reached without searching for it.
Thread titles are blurred in the recording for privacy. The grey cards are the thread rows.
| At rest (first row hidden) | Pulled down (first row appears) |
|---|---|
 |
 |
Impact
Major degradation or frequent failure
Version or commit
T3 Code 2.0 (App Store build of Oct 16, 2026). Still present on main @ 5d27ecd.
Environment
iPad (7th generation, MW782LL/A), iPadOS 18.7.10, landscape split view, connected to a T3 Code desktop host on macOS over Tailscale.
Logs or stack traces
n/a (layout bug, no errors)Screenshots, recordings, or supporting files
Redacted recording (mp4): https://gist.githubusercontent.com/Neilsmahajan/c386907b719b339a62de29c87d9f91c5/raw/ipad-before-device.mp4
Workaround
Search for the thread by name.
Likely cause
Before iOS 26 the sidebar list in apps/mobile/src/features/threads/ThreadNavigationSidebar.tsx uses contentInsetAdjustmentBehavior="never" with only 6pt of top padding. That was right when #4032 added it, because the old stack laid content out below an opaque header. Since the v5 navigation migration (#16733), the sidebar screen is laid out under its header on every iOS version, so on iOS < 26 nothing insets the list past the header and search field. The iOS 26 path already uses "automatic", which is why the bug only shows on older iPads.
Activity
juliusmarminge commentedon Oct 20, 2026
Note
Grok responding on behalf of Julius.
Thanks for the recording and the source reading. Current main matches it. The iPad sidebar now uses the native header, with its title and search field, through the
nativeChromepath added with the native iPad columns in #16733. In that path, the thread list setscontentInsetAdjustmentBehaviorto"never"whenever native Liquid Glass isn't available, and adds only 6pt of top padding (apps/mobile/src/features/threads/ThreadNavigationSidebar.tsx:778-787). On iPadOS 18 nothing then insets the list below the native header, so the first row rests behind it. The non-native path pads the list by the measured sticky header height instead (lines 476-485 and 852), which is why this only shows up in the native column layout.#20149 changed the sidebar background behind the header, not the list inset, so it doesn't affect this.
Accepting this as a bug.
adv0r commentedon Nov 7, 2026
Additional report from a physical iPad, observed on 2026-11-07. Posted by Codex (gpt-6.1-sol) at the reporter's explicit request.
Reporter-observed behavior
The pull-down-only visibility symptom appears consistent with this issue. The exact iPadOS version has not been captured, so this is a matching symptom report, not confirmation of the same pre-iOS-26 root cause. The broader missing-thread behavior may also overlap #24997 or #27868.
Host details verified through read-only diagnostics
darwin/arm64).26.7.3.0.1.7.0.1.7, stable channel.Exact iPad model, iPadOS version, and mobile app version/build were not available in the host diagnostics inspected. No iPad-side trace or recording was captured, and the proposed fix in #22550 has not been tested on this device.