You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Open a thread in the Android client.
Open the terminal view.
Tap into the terminal input so the keyboard comes up.
The system autofill service activates (Bitwarden, in my case) and the keyboard shows its incognito/private icon.
Expected behavior
The terminal input is not a credential field, so focusing it should not engage the password manager / autofill service at all, and the keyboard should not switch into incognito mode.
Actual behavior
Every time the terminal input is focused, the Android autofill service (Bitwarden) is triggered, and the keyboard displays the incognito icon. Presumably the terminal input is being flagged as a secure/sensitive field (that flag is also what makes the keyboard show incognito mode), or it exposes input/hint metadata that makes the system treat it as a login field.
Suggested fix: mark the terminal view with importantForAutofill = no / noExcludeDescendants so autofill services never engage there, and make sure the input's inputType/autofill hints don't resemble a username/password field. If the sensitive-input flag is intentional, the autofill engagement is still unwanted.
Impact
Minor bug or occasional failure
Environment
Device: Xiaomi 15 on HyperOS 4 beta 3 (CN ROM)
Autofill provider: Bitwarden
Platform: Android client (current build as of 2026-09-20)
Android thread terminal: focusing the input engages the system autofill service (Bitwarden in the report) and puts the keyboard into incognito/private mode. Confirmed in current main — this is a real native input-flag bug, not a Bitwarden-only quirk.
What we think is going on
The Android terminal IME is a hidden 1×1 EditText in T3TerminalView.configureInputView() (apps/mobile/modules/t3-terminal/android/src/main/java/expo/modules/t3terminal/T3TerminalView.kt). It is configured as:
TYPE_TEXT_VARIATION_VISIBLE_PASSWORD is the usual “disable suggestions but still show characters” trick. Autofill and password managers treat that variation as a credential field, so Bitwarden (and Google Password Manager, etc.) fire on every focus. importantForAutofill is unset, so it stays AUTO.
IME_FLAG_NO_PERSONALIZED_LEARNING is the other half of the incognito keyboard icon. That flag can be intentional for a terminal (commands / sudo passwords should not train the IME). Autofill engagement is not.
This landed with Android terminal support in #3579 and has not been revisited. iOS (autocorrectionType = .no, keyboardType = .asciiCapable) and the JS fallback TextInput (autoCorrect={false}) do not mark the field as a password. The Android composer already uses TYPE_TEXT_FLAG_NO_SUGGESTIONS without a password variation.
Not the same bug as
#12756 — same reporter/surface, slow per-keystroke echo. Different bug.
Keep this open as an Android terminal autofill bug.
Drop TYPE_TEXT_VARIATION_VISIBLE_PASSWORD. Keep TYPE_CLASS_TEXT | TYPE_TEXT_FLAG_NO_SUGGESTIONS (no CAP_*).
Set importantForAutofill = IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS on the hidden input (and the terminal container if descendants still get scanned). Do not set autofill hints.
Decide whether to keep IME_FLAG_NO_PERSONALIZED_LEARNING. If it stays, the incognito icon may remain after autofill is gone; that is a product call. Autofill must still be opted out.
Native Kotlin change — needs a store/native build, not an OTA. Report + source are enough; no more reporter info required.
Workaround: disable the autofill service for this app, or type from desktop/web.
Activity
juliusmarminge commentedon Sep 20, 2026
Triage
Android thread terminal: focusing the input engages the system autofill service (Bitwarden in the report) and puts the keyboard into incognito/private mode. Confirmed in current
main— this is a real native input-flag bug, not a Bitwarden-only quirk.What we think is going on
The Android terminal IME is a hidden 1×1
EditTextinT3TerminalView.configureInputView()(apps/mobile/modules/t3-terminal/android/src/main/java/expo/modules/t3terminal/T3TerminalView.kt). It is configured as:TYPE_TEXT_VARIATION_VISIBLE_PASSWORDis the usual “disable suggestions but still show characters” trick. Autofill and password managers treat that variation as a credential field, so Bitwarden (and Google Password Manager, etc.) fire on every focus.importantForAutofillis unset, so it staysAUTO.IME_FLAG_NO_PERSONALIZED_LEARNINGis the other half of the incognito keyboard icon. That flag can be intentional for a terminal (commands / sudo passwords should not train the IME). Autofill engagement is not.This landed with Android terminal support in #3579 and has not been revisited. iOS (
autocorrectionType = .no,keyboardType = .asciiCapable) and the JS fallbackTextInput(autoCorrect={false}) do not mark the field as a password. The Android composer already usesTYPE_TEXT_FLAG_NO_SUGGESTIONSwithout a password variation.Not the same bug as
No existing autofill / Bitwarden duplicate found.
Next step
Keep this open as an Android terminal autofill bug.
TYPE_TEXT_VARIATION_VISIBLE_PASSWORD. KeepTYPE_CLASS_TEXT | TYPE_TEXT_FLAG_NO_SUGGESTIONS(noCAP_*).importantForAutofill = IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTSon the hidden input (and the terminal container if descendants still get scanned). Do not set autofill hints.IME_FLAG_NO_PERSONALIZED_LEARNING. If it stays, the incognito icon may remain after autofill is gone; that is a product call. Autofill must still be opted out.Native Kotlin change — needs a store/native build, not an OTA. Report + source are enough; no more reporter info required.
Workaround: disable the autofill service for this app, or type from desktop/web.