🐞 Resizing the Hammerspoon window is laggy

[Caffeine19]

Bug Description

When trying to resize the Hammerspoon console window using Loop, Loop becomes very laggy and takes a long time to respond.

Affected Scope

Performance

Steps to Reproduce

1. Open the Hammerspoon console
2. Use Loop to resize the Hammerspoon console window

Reproducibility

Always

Expected vs Actual Behavior

Expected: should be smooth
Actual Behavior: pretty laggy

Screen Recordings / Screenshots

Recording.at.2026-03-02.10.03.36.mp4

Severity

Critical (major functionality broken)

macOS Version

Sequoia 15.7.4

Loop Version

Version 1.4.2 (1693)

Did You Try the Development Build?

No

Additional Context

No response

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]

Hey, @Caffeine19 I can't repo this, can you try updating to the latest dev build and see if this issue persists.

[Caffeine19]

Hey, @Caffeine19 I can't repo this, can you try updating to the latest dev build and see if this issue persists.

Thanks, just update to the latest dev build with Version 🧪 1.4.3 (1709)
Still laggy:

Recording.at.2026-03-02.10.47.40.mp4

[SenpaiHunters]

Can you send me a few scripts to test, i wonder if its something due with your hammerspoon config, or its just another lovely stage manager issue.

[Caffeine19]

merspoon config, or its just another lovely stage manager issue.

Thank you for your notice. I reloaded Hammerspoon with a blank and clean config, and it’s smooth now. I will try to find out which part of my scripts caused this issue and reply later. 😘

[Caffeine19]

Can you send me a few scripts to test, i wonder if its something due with your hammerspoon config, or its just another lovely stage manager issue.

Hi, find the codes, I subscribed to the window created event in hammerspoon, and this cause the problem:

local wf
-- Initialize the window management functionality
function windowManager.init()
	-- Subscribe to window creation events
	wf = hs.window.filter.default

	-- this line
	wf:subscribe(hs.window.filter.windowCreated, function() end)
end

And after turning off the stage manager, the issue still exists.

[SenpaiHunters]

I will look into this to see if there is anything related to Loop, or if we could fix it. If not, it may just be a purely Hammerspoon issue, as Hammerspoon, of course, is its own scripting tool which is hard to isolate and/or fix.

[SenpaiHunters]

Okay, given what you found with hs.window.filter.default and the windowCreated subscription, this really looks like it’s coming from how Hammerspoon is handling windows and accessibility events, rather than from Loop itself. Having looked at the code and how we handle everything, there are no specific lines of code that would, from what I can see, affect how Hammerspoon would work or, subsequently, how Loop would resize and handle windows.

That filter setup ends up watching pretty much every window on the system and reacting whenever something changes. When Loop is actively resizing a window (especially something like the Hammerspoon console), Hammerspoon is constantly receiving events and trying to do its own work at the same time. That back-and-forth is likely causing the lag you’re seeing. At least, I suspect this to be the case, as you said the specific line causes the lag, and I can observe this too on my own machine.

Loop doesn’t do anything special for Hammerspoon’s console - it just sees it as a normal window - so my suspicion is that this is primarily a Hammerspoon behavior/permissions issue.

If you have the time, it would be really helpful to try the same setup with another window manager (Rectangle, etc.) while keeping the exact same Hammerspoon config:

• If you see the same lag there, we can safely say it’s not specific to Loop and is down to Hammerspoon.
• If other window managers are smooth with the same config, I’ll go back and take another look at how Loop is handling that window (or entirely) to see if there’s something we can improve.

Given the current issue scope, I may close this as non-completed, or something that can't be easily fixed, but I'll maintain the issue and see if there is anything else we can do from a coding side to make sure it doesn't clash.

[Caffeine19]

Okay, given what you found with hs.window.filter.default and the windowCreated subscription, this really looks like it’s coming from how Hammerspoon is handling windows and accessibility events, rather than from Loop itself. Having looked at the code and how we handle everything, there are no specific lines of code that would, from what I can see, affect how Hammerspoon would work or, subsequently, how Loop would resize and handle windows.

That filter setup ends up watching pretty much every window on the system and reacting whenever something changes. When Loop is actively resizing a window (especially something like the Hammerspoon console), Hammerspoon is constantly receiving events and trying to do its own work at the same time. That back-and-forth is likely causing the lag you’re seeing. At least, I suspect this to be the case, as you said the specific line causes the lag, and I can observe this too on my own machine.

Loop doesn’t do anything special for Hammerspoon’s console - it just sees it as a normal window - so my suspicion is that this is primarily a Hammerspoon behavior/permissions issue.

If you have the time, it would be really helpful to try the same setup with another window manager (Rectangle, etc.) while keeping the exact same Hammerspoon config:

• If you see the same lag there, we can safely say it’s not specific to Loop and is down to Hammerspoon.
• If other window managers are smooth with the same config, I’ll go back and take another look at how Loop is handling that window (or entirely) to see if there’s something we can improve.

Given the current issue scope, I may close this as non-completed, or something that can't be easily fixed, but I'll maintain the issue and see if there is anything else we can do from a coding side to make sure it doesn't clash.

Thanks, I just tried rectangle and it can works:

Recording.at.2026-03-05.20.24.49.mp4

[Caffeine19]

And raycast's window management:

Recording.at.2026-03-05.20.26.07.mp4

[SenpaiHunters]

With Loop, can you try with both keybinds and using the radial menu?

[Caffeine19]

Keybinds:

Recording.at.2026-03-05.20.56.30.mp4

Radial menu:

Recording.at.2026-03-05.20.57.37.mp4

[Caffeine19]

And this is messages from console, I saw some errors inside:

Text.txt

[MrKai77]

@Caffeine19 try this build: https://github.com/MrKai77/Loop/actions/runs/22880604604/artifacts/5840643187, from PR #1065

[Caffeine19]

@Caffeine19 try this build: https://github.com/MrKai77/Loop/actions/runs/22880604604/artifacts/5840643187, from PR #1065

Works great, really smooooooooth 😘

Recording.at.2026-03-10.11.08.34.mp4