Ghostty holding SecureInput when losing focus in 1.3.1 - does not do so in 1.2.3

[chrissearle]

Issue Description

In ghostty 1.3.1 - with secure input enabled - it keeps it even when it loses focus.

• Work requirement - all terminal apps must have secure input enabled.

Expected Behavior

I expect ghostty to release secureinput when it is not the active window - just as it did in 1.2.3 and earlier and as both iterm and terminal.app do.

Actual Behavior

It keeps secureinput active

Reproduction Steps

Setup

First up - I set up 3 terminal apps to test (these are basically the settings my employer requires me to set):

iterm:

"Automatically enable secure keyboard entry at password prompts" -> True

ghostty:

macos-auto-secure-input = true
shell-integration-features = sudo

Terminal.app

Menu: Terminal > Secure Keyboard Entry

Testing

Testing what process has SecureInput if any:

ioreg -l -d 1 -k SecureInput | grep SecureInput

Then check what PID is in the kCGSSessionSecureInputPID field and see what that is via ps

Ghostty 1.3.1

If ghostty 1.3.1 is running at all - then this will show the PID of ghostty in all 3 different terminal windows. Regardless of the order of starting them up.

If ghostty is not running - the in the iterm window it shows the iterm PID and in terminal.app it shows the terminal.app pid.

Ghostty 1.2.3

I grabbed ghostty 1.2.3 and repeated the test.

• In ghostty 1.2.3 - it shows the PID of ghostty.
• In iterm it shows the iterm PID
• in terminal.app it shows the terminal.app pid.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

Mac Tahoe 26.5.1

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

macos-auto-secure-input = true

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[jkarmel]

I’m also seeing this on macOS with Ghostty 1.3.1.

Symptom: Ghostty enables macOS Secure Input and does not reliably release it. When this happens, global hotkey tools that depend on keyboard event taps stop seeing normal keypresses. In my setup that breaks my Karabiner/Windows/MouseLayer workflow: . + T, . + G, Super+C, and Super+X stop working.

What I observed:

• IsSecureEventInputEnabled() returns true
• ioreg -l -w 0 | rg kCGSSessionSecureInputPID reports Ghostty’s PID as the owner
• Ghostty > Secure Keyboard Entry appears unchecked
• My config has macos-auto-secure-input = false
• Toggling Secure Keyboard Entry in the Ghostty menu changes the checkmark but does not clear Secure Input
• Quitting Ghostty can leave Secure Input stuck on the old/dead Ghostty PID until the login session is reset

I switched to Kitty as a workaround.

This is disruptive because once Secure Input gets stuck, global hotkeys stop working and the only reliable recovery seems to be logging out/back in or otherwise resetting the macOS session. I hope I can go back to Ghostty soon as I really love it.

[TyceHerrman]

Possibly related issue I'm having:

When Ghostty is foreground with Secure Input active, launching another app opens it behind Ghostty and at end of App Switcher stack. I only reproduce this when opening another app while Ghostty with Secure Input is foregrounded.

related - #2270 disables Secure Input only after NSApplication.didResignActive. If Ghostty never relinquishes focus, that callback may never run.

another possible downstream impact:

sudo -v reaches the Touch ID/SecurityAgent prompt, but the prompt opens behind Ghostty. I have to click the prompt window before Touch ID will work

related to #5358, but my case is narrower in that Touch ID is not missing, it just backgrounds behind Ghostty.

A/B I tested:

Case	Result
Fresh Ghostty launch, persisted SecureInput=1	Touch ID prompt backgrounds
Fresh Ghostty launch, persisted SecureInput=0	Touch ID prompt foregrounds
Change SecureInput to 0 while Ghostty is already running	still backgrounds
--macos-auto-secure-input=false with persisted SecureInput=1	still backgrounds

PAM/session setup is not the issue because pam_reattach runs before pam_tid and Touch ID is reached reliably.

So I think this is within this discussion's Secure Input/focus realm as a second symptom - SecurityAgent/LocalAuthentication doesnt foreground