Skip to content

macOS: disable verification code autofill in windows - #10250

Closed
alexasa79 wants to merge 1 commit into
kovidgoyal:masterfrom
alexasa79:macos-disable-verification-code-autofill
Closed

alexasa79 wants to merge 1 commit into
kovidgoyal:masterfrom
alexasa79:macos-disable-verification-code-autofill

Conversation

@alexasa79

Copy link
Copy Markdown

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

  • git diff --check
  • clang syntax-only compilation of glfw/cocoa_window.m against the installed macOS SDK

A full debug build was not run because the system Python is 3.9.6 while kitty requires Python 3.12 or newer.

@kovidgoyal

Copy link
Copy Markdown
Owner

What does one have to do to have a verification code autofill suggestion
pop up in kitty? And doing this will almost certainly have other
implications, like say breaking dictation or IME or something.

@alexasa79

Copy link
Copy Markdown
Author

What does one have to do to have a verification code autofill suggestion pop up in kitty? And doing this will almost certainly have other implications, like say breaking dictation or IME or something.

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

@kovidgoyal

Copy link
Copy Markdown
Owner

That sounds more reasonable, although if this is system wide behavior I
dont think we should be opting out of it by default. Does it happen in
Terminal.app for instance? I can certainly imagine someone running a TUI
that requires one time codes.

@alexasa79

Copy link
Copy Markdown
Author

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:
ghostty-org/ghostty#11351

Perhaps make it configurable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants