Repository navigation
[Bug]: Mobile request_user_input card overflows the viewport and cannot be scrolled #5009
Description
Activity
Confirming this on iOS. The screenshot above is a 10-question
request_user_input. There's no scroll mechanism, and because the card is anchored to the bottom of the composer overlay, the first questions are pushed off the top of the screen entirely — so you're stuck any time you're asked more than a couple of questions. You can reduce the font size to fit a bit more in, but that's not a real solution.Root cause matches the report: the
questions.map()inapps/mobile/src/features/threads/PendingUserInputCard.tsx. Desktop already solves this —ComposerPendingUserInputPanel.tsxrenders one question at a time offderivePendingUserInputProgress, with a progress counter and Previous/Next.I have a working fix that brings mobile to parity by reusing that existing web helper: no new backend surface, no contract changes, and no review screen. It's ~550 non-test lines, mostly the card rewrite, though it does touch web for import updates. #2046 attempted something similar but was closed unmerged — it was 267 files against a non-main base branch.
Happy to submit the PR if that'd be useful, or leave it alone if you'd rather own this one internally.
Same issue here. Concrete case: with 3 questions in one interactive card, the first question is pushed entirely off-screen and there is no way to scroll back to it, so the whole request becomes unanswerable. +1 for per-question navigation or at minimum making the card scrollable.
Can we fix this it breaks an entire thread for the t3 app making that thread useless until I can get back to PC. Can I send a vibe PR for this ? @t3dotgg @juliusmarminge
Before submitting
Area
Not sure — this affects
apps/mobile, which is not currently listed in the Area dropdown.Steps to reproduce
request_user_inputwith several questions containing long prompts and multiple options.Expected behavior
The pending-input UI should remain within the available viewport. Questions should be presented one at a time with Previous/Next navigation, or the question content should at minimum be vertically scrollable while keeping the actions reachable.
Actual behavior
Every question is rendered in a single card inside the keyboard-sticky composer overlay. The card grows beyond the viewport, but the overlay is not scrollable. Parts of the questions become inaccessible and the composer overlaps the UI, making the thread effectively unusable until the request can be resolved elsewhere.
The native implementation currently maps all entries from
pendingUserInput.questionsinto a plainViewinapps/mobile/src/features/threads/PendingUserInputCard.tsx. That card is mounted inside the absolutely positionedKeyboardStickyViewinThreadDetailScreen.tsx, with no viewport height constraint or scroll container around the pending questions.Impact
Blocks work completely
Version or commit
main@2448212367b4Environment
iOS native mobile app, iPhone-sized viewport, Codex provider in Plan mode using
request_user_input.Logs or stack traces
Screenshots, recordings, or supporting files
Workaround
Open the same thread in the web client, which already presents pending questions one at a time, or avoid multi-question
request_user_inputcalls on native mobile.