🐞 Keyboard shortcuts stop working while OS X Secure Input is active

[wolph]

Bug Description

Loop shortcuts completely stop working while OS X Secure Input is active. The radial menu still opens, but the regular key event never reaches Loop and the window doesn't move.

This started out of nowhere after a reboot for me. Re-adding Accessibility permissions, logging out, rebooting, and even upgrading OS X made no difference. Rectangle worked immediately with the same shortcuts though. I can now reproduce it every time with the helper below :)

Affected Scope

Other

Steps to Reproduce

1. Configure a Loop shortcut such as ⌘⌥←.
2. Confirm that it moves the focused window.
3. Run this in Terminal:

swift -e '
import Carbon.HIToolbox
import Darwin
import Foundation

func stopSecureInput(_: Int32) {
    _ = DisableSecureEventInput()
    exit(0)
}

signal(SIGINT, stopSecureInput)
signal(SIGTERM, stopSecureInput)

let status: OSStatus = EnableSecureEventInput()
guard status == noErr else {
    fputs("EnableSecureEventInput failed: \(status)\n", stderr)
    exit(1)
}

print("Secure Input enabled: \(IsSecureEventInputEnabled())")
print("Press Control-C to disable it and exit.")
fflush(stdout)
RunLoop.current.run()
'

4. Confirm that it prints Secure Input enabled: true.
5. Retry the Loop shortcut.
6. Stop the helper with Control-C and retry it once more.

Reproducibility

Always

Expected vs Actual Behavior

Expected: the shortcut moves the window, just like it does in Rectangle.

Actual: Loop sees the modifiers and can show the radial menu, but it misses the regular action key. The window doesn't move. Stopping the helper makes the shortcut work again immediately.

Screen Recordings / Screenshots

Not applicable; the only visible result is that the window doesn't move.

Severity

Major (workaround exists)

macOS Version

26.5.2 (25F84)

Loop Version

1.4.2 (1755); also reproduced on build 1714

Did You Try the Development Build?

Yes

Additional Context

I'm not sure what suddenly enabled Secure Input on this machine. Bitwarden is a likely real-world trigger because of bitwarden/clients#21964, but the helper above reproduces the problem without Bitwarden.

#1127 already contains the fix I tested. Since the project requires an accepted issue first, I'm filing this now. If the approach looks good, please reopen that PR and I'll update it with the AI disclosure.

AI Assistance Disclosure

OpenAI Codex (GPT-5) assisted with diagnosis/implementation/tests/documentation/reproduction-helper/pr-drafting.

I personally reproduced and tested the complete behavior. I also manually reviewed every line of the proposed code and verified that it does only what is necessary to address this bug and as far as I can judge, nothing outside that scope.

I'm an experienced open source developer and wouldn't have submitted the PR if I wasn't confident in the code, it's signed with my name after all so my own reputation is at stake too ;)

Final Checks

• My issue is written in English.
• My issue title is descriptive.
• This is a single bug (multiple bugs should be reported individually).
• I have looked to see if this is a duplicate of another bug report.
• I can help with further investigation.
• I can help with developing a fix for this issue.

[SenpaiHunters]

Secure Input is a system-wide privacy feature that prevents other apps from reading certain keyboard input while it is enabled. It is not intended to be readable by application key events or by anything trying to sniff out a password. It is typically used in terminal apps such as Ghostty, where you can enable Secure Input because it stops all apps from reading keyboard input (a-z).

Loop will not work while Secure Input is active, and this is by design. However, we also have gestures and, soon, trackpads. That gives you two backups, and I can confirm that both work as a workaround. Bypassing Secure Input is not something we wish to do, as this seems to be isolated to Bitwarden. I tested 1Password and Proton, and they do not exhibit this behaviour. It would be best to wait for an update from Bitwarden’s side instead of us adding a manual way to bypass Secure Input.

I know this is not what you want, but as it’s not a specific Loop issue and because of the nature of the request, we will not currently look at changing this.

Also, for a bit of info, we typically don't accept heavily AI-generated pull requests. That is why I closed your item without saying anything. It takes us a while because we manually review the code, test the app for hours or days, and then accept the PRs. Unless it is a small one-liner, your PR was about ~1.1k lines. Yes, it added a lot of comments, but you incorrectly changed the build version from Release to Debug, which is not allowed, and you also added a full test case.

In this case, the PR was far beyond the scope of the issue, changed the build configuration from Release to Debug, and added a full test case that was not requested. I understand that contributors have different levels of experience, but from the review, it did not appear that the generated output had been properly checked before submission.

We welcome contributions, but they must follow the templates and stay tightly within scope. If you want to discuss an issue further, you can do so in Discord or by opening a focused issue. Please keep future PRs small, reviewed, and aligned with the exact problem being solved.

If you have further questions or need any clarification, please feel free to comment below.

[wolph]

Even if it's broken by design, it would still be very useful if loop would indicate why it's suddenly broken instead of not indicating anything. So perhaps there should be an indicator on the about page or a separate debug page so you can see what's going wrong?

As I said, Rectangle still worked like a charm and there was no clear indication that something was broken and why it was broken, odds are that I never would have found the cause without having AI to debug the issue since diving deep into the Loop code is something that would take too much time otherwise. So the alternative options were creating a (most likely) useless bug report or it would take both of us a lot of back-and-forth time to diagnose the cause. Or... I would have switched to a different app that does work.

I fully understand you apprehension of AI generated pull requests... the difference in quality between pull requests that all look great at first glance is huge and it takes a lot of time and effort to differentiate.
As for the Release versus Debug, that was intentional to add the LoopTests to the scheme, so xcodebuild test -scheme Loop actually executes the created tests. I was doubtful about including that but otherwise the tests wouldn't have run...

[SenpaiHunters]

Loop normally displays a failure or notification explaining why it failed, and full logs are generated for all builds. Developer builds should expose them in the console. If it does not return anything, you would typically investigate from there. However, due to how Secure Input is controlled by macOS, it may fail to output anything meaningful and simply return nothing. As this is an extremely rare test case, only now seen in Bitwarden after they changed something, I don’t see a reason to add a UI indicator for this. It might be better handled in documentation or in a file, like we have with defaults, to indicate that it won’t work. That would make it clearer, and I agree with that.

Kai and I have also spoken about adding debug options to test and validate things. But it always comes back to how much we want to add to Loop for cases like these, because the average user will use it and call it a day. And we’re not anti-AI; it’s a very helpful tool. When used, reviewed, and acted upon within reason, it’s useful. Letting it run wild on the codebase can do more harm than good.

As for your notation of debug vs. release, Loop is set to partial release and debug, so if you need a specific setting, you’ll need to change it. It should not directly impact the test cases. Swift-testing and XCTest should work regardless of the selection; that is how the actual tests are made.

I'll tag @mrkai77 if he'd prefer to place a note in a file or somewhere else, but we don't change UI states in Loop to show an issue. It’s either in the defaults, in a linked comment like this, or part of the normal context we include for standard advice.