Conversation
|
What does one have to do to have a verification code autofill suggestion |
On macOS, the Secure Code Autofill feature (introduced in Mojave and refined in later versions) automatically detects six-digit one-time verification codes received via SMS in the Messages app and offers to autofill them into active text input fields. This is very convenient in web browsers for 2FA login forms, where a suggestion bar or popup appears above the field. For some reason this mechanism also works in Kitty terminal, and it is disruptive and annoying. This behavior is specific to macOS 26: Apple now offers verification codes detected by Messages or Mail in every active text-input experience for up to three minutes. You were right to question the implications. After checking Apple’s current documentation, my NSTextContent/nil approach is not the correct opt-out. Any thoughts on how to fix this? Perhaps NSAutoFillRequiresTextContentTypeForOneTimeCodeOnMac (https://developer.apple.com/documentation/bundleresources/information-property-list/nsautofillrequirestextcontenttypeforonetimecodeonmac). Thanks |
|
That sounds more reasonable, although if this is system wide behavior I |
|
I don't know if Terminal.app has this problem. It's tricky to reproduce. It looks like Ghostty had this problem and applied the NSAutoFillRequiresTextContentTypeForOneTimeCodeOnMac fix: Perhaps make it configurable? |
Summary
Explicitly make the Cocoa content view an NSTextContent provider on macOS 11 and newer and report a nil content type. This tells AppKit that kitty terminal input has no semantic text classification, preventing verification-code AutoFill suggestions from appearing in terminal windows.
The protocol conformance and methods are guarded by MAC_OS_X_VERSION_MAX_ALLOWED so builds using older SDKs are unchanged.
Testing
A full debug build was not run because the system Python is 3.9.6 while kitty requires Python 3.12 or newer.