macOS: Secure Input lock icon remains visible after password prompt completes

[rkp-ubona]

On macOS, Ghostty occasionally shows the Secure Input lock icon even after a password prompt has completed.

Any ideas as to how to fix this?

--

Ghostty version:
ghostty +version
Ghostty 1.2.3

Version

• version: 1.2.3
• channel: stable
  Build Config
• Zig version : 0.14.1
• build mode : builtin.OptimizeMode.ReleaseFast
• app runtime : apprt.Runtime.none
• font engine : font.main.Backend.coretext
• renderer : renderer.generic.Renderer(renderer.Metal)
• libxev : kqueue

[jannschu]

Not sure if this is related, but if I run this

python3 -c '__import__("getpass").getpass()'

then paste something via CMD+V, then ENTER, the secure input doesn't go away. Tested on 1.2.3 and tip.

Ghostty 1.3.0-main+da10707f9

Version
  - version: 1.3.0-main+da10707f9
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

[injust]

I can't reproduce on tip, on macOS Sequoia 15.7.3.

[injust]

@rkp-ubona Could you please edit to include the full issue triage template?

[rkp-ubona]

@injust , sure thing, let me do it tomorrow.

[rkp-ubona]

@injust , not able to reproduce it now. will update once i do.

[jannschu]

I spent quite some time on this now, with multiple tests, debug outputs added etc., I struggle to reliably reproduce this unfortunately.

After many experiments, my current feeling is, that this is related to using an external screen… It works using the internal screen of the macBook, but if I move the window to the external display (5K, 2560x1440, Thunderbolt), I see the hanging or just huge delays. No issues when using the macOS Terminal.app in the same setup though. Sometimes the delay is short for a couple of trials, then my impression is the delay increases, quite strange.

I created a spindump during the block, and while idle. Then asked Claude Code to have a look, not sure if that is convincing or helpful at all, but just in case, see below.

Claude Opus interpretation of spindump and logs

The password_input=false state change flows through the main thread via DispatchQueue.main.async { appTick() }. During paste operations, the main thread is blocked 80% of the time in CA::Render::Context::wait_for_synchronize — Core Animation waiting for the WindowServer to composite layer updates.

Spindump evidence (during paste):

746/928 samples (80%): CA::Render::Context::wait_for_synchronize → mach_msg2_trap

vs idle baseline:

3/972 samples (0.3%): CA::Render::Context::wait_for_synchronize

This starves appTick(), which processes the mailbox containing the password_input=false message and ultimately calls DisableSecureEventInput.

From the debug output: DisableSecureEventInput() itself is not hanging; it runs quickly once reached.

Reproduction

python3 -c '__import__("getpass").getpass()'
# Paste ~128 alphanum chars via CMD+V, press Enter
# Observe secure input indicator persists for several seconds

• Reproduces on external LG 5K displays (5120×2880)
• Worse with scaled resolutions
• Does not reproduce on internal MacBook display
• macOS 26.2, Ghostty 1.3.0-main+2868677af

[rkp-ubona]

After many experiments, my current feeling is, that this is related to using an external screen…

umm, not quite right. i faced this on a macbook with a single screen.

[jannschu]

Hm, that is unfortunate. I just tried it with another setup, macBook + Apple Studio Display, same issue. Maybe different issues then.

[jannschu]

Out of curiosity I vibe coded a NSLock based coalesced tick scheduling, as mentioned here:

ghostty/macos/Sources/Ghostty/Ghostty.App.swift

Lines 427 to 431 in 13e8d85

	// Wakeup can be called from any thread so we schedule the app tick
	// from the main thread. There is probably some improvements we can make
	// to coalesce multiple ticks but I don't think it matters from a performance
	// standpoint since we don't do this much.
	DispatchQueue.main.async { state.appTick() }

and it works for me! :) Maybe that helps someone, my Swift experience is quite dated to properly evaluate if this is reasonable.

Vibe coded explanation

wakeup can be called very frequently from non-main threads. Previously each wakeup did DispatchQueue.main.async { appTick() }, which can pile up many pending appTick blocks while the main thread is busy.

That causes two problems:

1. Main queue backlog grows.
2. Important mailbox messages (password_input=false) wait behind a flood of redundant tick blocks.

The patch fixes this by:

1. Coalescing wakeups: only one pending tick is allowed (wakeupPending gate).
2. Scheduling on the main runloop (CFRunLoopPerformBlock + CFRunLoopWakeUp) instead of spraying GCD async blocks.

So if 100 wakeups happen while the main thread is busy, you no longer enqueue 100 tick blocks. You enqueue one, and when it runs, ghostty_app_tick drains mailbox messages in bulk. That cuts starvation and greatly reduces the delay before secure-input off is processed.

[jannschu]

Setting macos-secure-input-indication = false also fixed it for me, as discussed here: #9617 (comment).

I tried to create macOS window compositor load to make this effect more reliable to reproduce, but it remains irregular. What did help though was turning of the indicator animation by commenting it out in code.