[Due for payment 2026-10-12] Agents - Custom instructions field is blocked by the keyboard

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.53-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #98380
Email or phone of affected tester (no customers): jose.sat94+10jul@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung Galaxy S21/Android 15, iPhone 13/18.6.2
App Component: Other

Action Performed:

1. Launch Expensify app.
2. Log in with valid credentials.
3. Go to Account > Agents.
4. Click New agent, then Build custom agent.
5. Tap the Custom instructions field.
6. Try to enter text.

Expected Result:

The Custom instructions field should remain fully accessible above the keyboard, allowing the user to enter and edit instructions.

Actual Result:

The keyboard overlaps the Custom instructions field, preventing the user from typing. As a result, the agent cannot be created and the test cannot continue.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7232149_1786571781978.BUG.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7232149

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022087766009921103773
• Upwork Job ID: 2087766009921103773
• Last Price Increase: 2026-08-13

Issue Owner

Current Issue Owner: @brunovjk

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/0765123269c68d863173a3f59e0f9b087b695d9e1bf252033b4d9efffe3fec6c

[MelvinBot]

Proposal

Please re-state the problem

On native (Android/iOS App), opening the keyboard in the Custom instructions field of the Build custom agent flow leaves the field covered by the keyboard, so the user can't see what they're typing and can't finish creating the agent.

What is the root cause?

The "Build custom agent" screen is AddAgentPage. Its ScreenWrapper gates keyboard/height handling on landscape only:

shouldEnableMaxHeight={shouldUseScrollableLayout}

AddAgentPage.tsx:169 — shouldUseScrollableLayout is only true in landscape/wide, so in normal portrait it is false.

ScreenWrapper only bounds its KeyboardAvoidingView when shouldEnableMaxHeight is set — otherwise maxHeight is undefined:

const maxHeight = shouldEnableMaxHeight ? windowHeight : undefined;

ScreenWrapperContainer.tsx:128

With maxHeight unset, the flex1 markdown input fills 100% height and the KeyboardAvoidingView can't shrink the content when the keyboard opens, so the keyboard overlaps the field.

Every comparable full-page markdown-input RHP screen sets shouldEnableMaxHeight unconditionally and does not hit this bug — e.g. RoomDescriptionPage.tsx:102, WorkspaceOverviewDescriptionPage.tsx:76, TaskDescriptionPage.tsx:105, PrivateNotesEditPage.tsx:134.

The sibling edit screen EditPromptPage.tsx:75 uses the same shouldEnableMaxHeight={shouldUseScrollableLayout} gating, so it is very likely affected the same way and should be fixed together.

Note: The bug was found during QA of #98380, but that PR only changes markdown rendering on the profile page and is not the cause.

What changes do you think we should make?

Enable shouldEnableMaxHeight unconditionally on the ScreenWrapper for both agent instruction screens, matching every other markdown RHP page:

• AddAgentPage.tsx: shouldEnableMaxHeight={shouldUseScrollableLayout} → shouldEnableMaxHeight
• EditPromptPage.tsx: same change

The existing shouldUseScrollableLayout gating on shouldUseScrollView / submitFlexEnabled / minHeight42 should stay as-is — only the shouldEnableMaxHeight prop needs to be always-on. Verify the flex1 input still fills the screen in portrait and that the keyboard no longer overlaps the field on Android and iOS native.

What alternative solutions did you explore?

Wrapping the form body in a ScrollView on portrait as well (like RoomDescriptionPage) would also work, but it's a larger change; toggling shouldEnableMaxHeight is the minimal fix that brings this screen in line with the established pattern.

Confidence & scope

Confidence: Medium. Root cause is backed by direct code evidence and a consistent contrast against 4+ analogous screens. Not runtime-verified on a native device (this is a native-only bug — it does not repro on web/mWeb per the report), so please validate the fix on Android and iOS native before merge.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/98529) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @brunovjk (External)

[j3ffffff]

VERDICT: POST
ROOT_CAUSE_ONELINER: Both AddAgentPage.tsx and EditPromptPage.tsx only enable keyboard avoidance (shouldEnableMaxHeight + shouldUseScrollView) in landscape mode, so in portrait mode the keyboard overlaps the "Custom instructions" input with no scroll or avoidance.
PROPOSAL_TYPE: FIRST
AUTOPOST_SAFE: YES

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022087766009921103773

[skrohan5016-coder]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On iOS and Android portrait layouts, focusing the full-height Custom instructions markdown field in the agent create/edit flow leaves part of the editor behind the software keyboard. The user must be able to see and edit the focused text and reach the submit action without changing the existing desktop/landscape layout.

What is the root cause of that problem?

Both agent instruction screens use the same layout combination:

• ScreenWrapper.shouldEnableMaxHeight is enabled only for the landscape/scrollable variant;
• FormProvider.shouldUseScrollView is also landscape-only;
• the markdown field and every container around it use flex1.

In portrait, shouldEnableMaxHeight is therefore false while the form body expands to the available flex height. ScreenWrapperContainer only applies the window-height bound to its KeyboardAvoidingView when shouldEnableMaxHeight is true. Without that bound, the keyboard-avoiding container does not get a finite height to shrink against, so the flex-filled editor remains under the keyboard.

The same pattern exists in both:

• AddAgentPage.tsx;
• Agents/Fields/EditPromptPage.tsx.

Fixing only the create screen would leave the edit flow with the identical native bug.

This is separate from whether the form itself uses a ScrollView. The portrait design intentionally keeps the instruction editor stretched to fill remaining space; the missing requirement is a bounded outer keyboard-avoiding viewport.

What changes do you think we should make in order to solve the problem?

1. Enable max-height handling unconditionally on both agent instruction screens:

<ScreenWrapper
    // ...
    shouldEnableMaxHeight
>

Replace shouldEnableMaxHeight={shouldUseScrollableLayout} in AddAgentPage and EditPromptPage.

2. Keep the existing landscape-only form behavior unchanged:

• retain shouldUseScrollView={shouldUseScrollableLayout};
• retain the current submitFlexEnabled behavior;
• retain styles.minHeight42 only for the scrollable layout.

That preserves the intended large/landscape form while allowing KeyboardAvoidingView to resize the portrait flex editor correctly.

3. Do not add a fixed editor height or keyboard-specific magic offset. Those approaches would be fragile across device sizes, safe-area insets, predictive-text bars, hardware keyboards, and split/floating keyboards. The shared ScreenWrapper is already responsible for those platform differences.

4. Apply the fix to the sibling edit page in the same PR because it has the same structure and otherwise remains a guaranteed regression surface.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Portrait native create-agent screen renders ScreenWrapper with shouldEnableMaxHeight=true while FormProvider.shouldUseScrollView=false.
2. Portrait native edit-prompt screen has the same contract.
3. Landscape native keeps shouldUseScrollView=true and the current minimum-height behavior.
4. Web/wide behavior remains unchanged.
5. A focused multiline instruction field remains visible when the keyboard height changes, including the submit/footer area.
6. Rotate portrait → landscape → portrait while focused and verify the editor retains its text and recalculates layout without overlap.
7. Test both iOS and Android native because their KeyboardAvoidingView behavior and safe-area handling differ.
8. Hardware-keyboard/no-soft-keyboard mode does not leave unnecessary bottom space.

A component-level test can assert the prop composition, while the overlap itself should be covered by the native interaction/QA test because JSDOM cannot model the software keyboard.

What alternative solutions did you explore? (Optional)

• Make the portrait form scrollable: viable but broader than necessary and changes the intended full-height editor UX.
• Apply keyboard padding directly to the TextInput: rejected because the keyboard belongs to the screen layout, not the field, and offsets vary by platform/device.
• Fix only AddAgentPage: rejected because EditPromptPage contains the same bug-producing layout.

[truph01]

@GCyganek It looks like we already have PR #97782 to address this issue, right?

[GCyganek]

@truph01 not really, my PR only fixes landscape mode, I tried not to change portrait mode behaviour on it and from what I just tested this issue is still reproducible on my PR