Fix iTerm2 Global Hotkey Blocked by Secure Input on macOS

Context#

• Environment: macOS, iTerm2 3.6.11
• What I was doing: Using the iTerm2 Hotkey Window bound to Ctrl-T, which had worked globally for months
• Accessibility permission: already granted to iTerm

The Symptom#

The hotkey window only opened when iTerm2 already had focus.

• Press Ctrl-T while iTerm2 is frontmost — works.
• Switch to Finder or a browser, press Ctrl-T — nothing happens.

That asymmetry is the tell. A broken hotkey binding fails everywhere. This failed only in the background, which means the binding was fine and something was intercepting the key before iTerm2 could see it.

Root Cause#

Another app was holding Secure Keyboard Entry and never released it.

Secure Keyboard Entry is a macOS feature that stops other apps from listening to your keystrokes — the thing that protects a password field from a keylogger. While any app holds it, iTerm2’s global key monitoring is blocked too.

But a focused app still receives its own keystrokes directly. So iTerm2 keeps working when it’s frontmost and goes deaf the moment it isn’t:

Works only when the iTerm2 window has focus; stops working after switching to another app.

Worth ruling out first, in order of likelihood:

1. An app is holding Secure Keyboard Entry and hasn’t released it — most likely
2. Secure Input was released, but iTerm2’s global key listener never re-registered (needs a restart)
3. iTerm2’s Accessibility permission went stale after a system or app update
4. Ctrl-T now collides with a global shortcut from macOS or another background app
5. The Hotkey Window setting itself got disabled or rebound

Diagnosis#

Check the hotkey configuration#

iTerm2 → Settings → Keys, or iTerm2 → Settings → Profiles → Hotkey Window → Keys.

Confirm the Hotkey Window is enabled, the shortcut is still Ctrl-T, and it hasn’t been changed into an ordinary in-app shortcut.

Check Accessibility permission#

System Settings → Privacy & Security → Accessibility — confirm iTerm is enabled.

The toggle showing “on” isn’t proof. Permission state can go stale after a macOS or iTerm2 update while still appearing granted.

Find out who holds Secure Input#

ioreg -l -w 0 -c IOHIDSystem \
  | grep -o '"kCGSSessionSecureInputPID"=[0-9]*' \
  | head -1

No output means nothing holds Secure Input. Output means the named PID is holding it:

"kCGSSessionSecureInputPID"=94071

Identify the app behind the PID#

ps -p 94071 -o pid,comm,args

Or:

lsof -p 94071 | head

The executable path is the useful part:

/Applications/NeteaseMusic.app/Contents/MacOS/NeteaseMusic

Do both in one step#

PID=$(
  ioreg -l -w 0 -c IOHIDSystem |
  sed -n 's/.*"kCGSSessionSecureInputPID"=\([0-9]*\).*/\1/p' |
  head -1
)

if [ -n "$PID" ]; then
  echo "Secure Input owner PID: $PID"
  ps -p "$PID" -o pid=,comm=,args=
else
  echo "No Secure Input owner"
fi

The Fix#

1. Open the offending app’s window. Move off any password or login field, close any login dialog. The focus change is usually enough to make the app release Secure Input.

2. Re-run the ioreg check. kCGSSessionSecureInputPID should be gone.

3. If it’s still held, quit the app properly with Cmd-Q. Closing the window often leaves the process running.

4. If Secure Input is released but Ctrl-T still does nothing, quit iTerm2 completely and reopen it so the global key listener re-registers.

5. If there’s no Secure Input owner at all and the problem persists, toggle iTerm off and on in Accessibility. If that fails, remove it from the list and add it back.

6. Last resort — reset iTerm2’s Accessibility authorization:

   tccutil reset Accessibility com.googlecode.iterm2

   bash

   Then go back to System Settings → Privacy & Security → Accessibility and grant iTerm permission again.

7. If the same app keeps doing this, update or reinstall it, and report the unreleased Secure Input to its developers.

Confirming It Was Secure Input#

Change one thing at a time, or you won’t know which action fixed it.

1. When the problem occurs, run ioreg and record the SecureInputPID and the app it belongs to.
2. Perform one action: open the app’s window, leave the password field, dismiss the login dialog, or quit the app.
3. Re-run ioreg after each action.
4. Switch focus to Finder or a browser and test Ctrl-T.

You’ve confirmed the cause when all three line up: a SecureInputPID existed before, it’s gone after, and Ctrl-T works globally again.

What Happened in My Case#

The culprit was NetEase Music.

• iTerm2 3.6.11, Hotkey Window enabled, bound to Ctrl-T, Accessibility granted — all fine.
• First check returned "kCGSSessionSecureInputPID"=94071.
• lsof traced PID 94071 to /Applications/NeteaseMusic.app/Contents/MacOS/NeteaseMusic.
• I didn’t quit it. I just reopened its window.
• SecureInputPID disappeared and Ctrl-T started working in other apps again.

NetEase Music was most likely holding Secure Keyboard Entry after its window was hidden or its login state changed, and never released it. Reopening the window forced a focus change, which released it.

That makes this an input-focus lifecycle bug in NetEase Music, not a lost iTerm2 hotkey configuration.

Summary#

When an iTerm2 hotkey works only while iTerm2 is focused, look for another app sitting on macOS Secure Keyboard Entry before touching any iTerm2 setting.

References#

• Apple: Use secure keyboard entry in Terminal on Mac ↗
• iTerm2 issue: hot key no longer works in macOS ↗