# iwck: lock the keyboard while you eat, write or clean a laptop > iwck is a small AutoHotkey utility for Windows that blocks keyboard input, and since 2025 mouse input as well, so you can put a bowl of instant noodles on the keyboard without triggering stray keystrokes. The interesting part is the ten-year arc of its interface, which has moved from the native AutoHotkey widgets through GDI+ and a third-party library to a WebView, and the fact that it ships a pinned Microsoft DLL with a published checksum. **Nigh/I-wanna-clean-keyboard** — Block the keyboard input while you were eating instant noodles on your laptop keyboard. - Repository: https://github.com/Nigh/I-wanna-clean-keyboard - Stars: 1,184 · Forks: 41 - Language: AutoHotkey - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/nigh-i-wanna-clean-keyboard ## A keyboard lock, aimed at one specific problem The pitch in the repository description is short enough to be the whole product statement: block the keyboard input while you were eating instant noodles on your laptop keyboard. The README expands it slightly, listing eating, writing and cleaning the key on your laptop keyboard as the situations the tool is for. The origin story is in the Behind the Code section and it explains the design. The author conceived the software during university, when eight people shared one narrow dormitory desk, and in winter they used laptops on their beds because the small foldable tables left no room for anything beyond the laptop. The two frustrations that stuck were wanting to write assignments directly on the keyboard, and wanting to place a cup of instant noodles safely without triggering accidental keystrokes. The third, added later, is crumbs: eating next to a keyboard gets debris between the keys, and nobody wants to pause a game, a job or a film to go and clean it. That history explains a design choice that would otherwise look odd. The tool does not attempt to solve cleaning, it removes the reason you would have to stop. If no input reaches the machine, the bowl can sit on the keyboard, the cloth can go over the keys, and the game keeps running. The operating model is a single toggle. Clicking the keyboard button blocks keyboard input immediately, and clicking it again restores it. There is no configuration file, no schedule, no per-key rule and no whitelist in the documented usage. The tool answers one question, which is whether input should reach the machine right now, and it answers it with a button. The project is written in AutoHotkey, and the repository holds main.ahk, meta.ahk and distribution.ahk at the top level, along with an html directory for the WebView interface, a webview2 directory for the Microsoft runtime pieces, a logo directory, the icon file, an ahk-compile-toolset directory and a .gitmodules file for the submodules it depends on. ## The mouse lock needs a ready state and a second keystroke Mouse support arrived in the 2025.09.28 release, and it was designed differently from the keyboard lock, for a reason that is easy to miss until you read the usage notes carefully. Clicking the mouse button does not block anything. It puts the tool into a ready state, and the README is explicit that mouse input is not blocked yet. Pressing Esc then starts the block, and pressing Esc again restores mouse input. If you have not pressed Esc yet, clicking the mouse button again cancels the ready state and nothing happens at all. The reason for the extra step is obvious once stated. With the keyboard, one click on a button is a complete action, because a keyboard lock is harmless to start by accident: you press a key, you notice nothing happened, you click again. A mouse lock is not harmless, because blocking the pointer removes the very means you would use to undo it. If the mouse button both armed and engaged the lock, and the button were under the cursor, clicking it a second time would be impossible, because the click would not reach the button. So the design routes the confirmation through the keyboard. Esc is the key that is still working, and it is a key you can always press. A ready state followed by a deliberate key press is a two-step commit that ends with the pointer still under your control, which is what keeps the release gesture reachable. The interaction is also forgiving about the ordering. Pressing Esc a second time restores mouse input, and clicking the mouse button again while still in the ready state cancels without any blocking having occurred. The exit button is the final safety net, described as restoring all input before the program exits, which is the behaviour that matters most in a tool that can otherwise leave a machine with a dead keyboard and a dead mouse. ## One lock at a time, and a window you can move The two modes are mutually exclusive, and the README is explicit about what happens when you switch: keyboard lock and mouse lock cannot be active together, and selecting one mode disables the other first. That ordering is the sensible one, and it follows from the mechanics rather than from a preference. The mouse lock's escape hatch is the keyboard, since Esc has to keep working. If a keyboard lock were already active when you went for the mouse, the confirmation key would be dead, and the mouse lock would be impossible to release. Unlocking the keyboard first keeps that path open. The window itself is minimal to the point of being a control rather than a panel. Pressing and dragging the iwck title moves the window, which is the only positioning gesture described. There is no system tray icon, no keyboard shortcut to toggle, no menu. The buttons on the window are the keyboard button, the mouse button and the exit button, and the README's screenshots and the visual style come from a web interface rather than from native controls, which is where the history section becomes relevant. Taken together, the interaction is a two-button device with a commitment step. The design assumes the person using it is at the machine, hands near the keyboard, and is about to do something with a bowl or a cloth. The complexity is low on purpose, and every extra gesture would be a chance to leave the keyboard blocked by accident. ## Three interface generations, from AHK widgets to a web view The history section is the most interesting thing in the README, because it records a decade of the author trying to make an AutoHotkey program look like something other than a script. The first version used AutoHotkey's native GUI. That was later rebuilt with GDI+, and the project went open source at that point. The 2020.05.25 entry records a migration to AHK v2-alpha, the switch to a new GDI+ library for the v2 branch instead of the old one, and a change to a dark style. The 2023.07.26 entry records the migration to AHK v2.0.4 and a switch away from GDI+ to a third-party library, Neutron.ahk, linked in the README from another author's repository. The 2025.09.28 entry, which is also the release that added mouse blocking, replaced the text in the interface with graphics. And the current interface is a WebView, with an html directory at the repository root and a webview2 directory holding the Microsoft pieces it loads. The author's stated motivation for the whole sequence is worth quoting in spirit: a belief that AutoHotkey can transcend the ugly system controls stereotype, and a hope that more AHK developers build software that is both functional and good looking. The Behind the Code section says the interface has had three major aesthetic upgrades, and the pattern of the history matches, moving from native widgets to a themed drawing library to a web interface. The practical consequence for a user is that the tool now needs a web runtime on the machine, which is what the requirements section is about, and that the source tree has grown a submodules relationship, since the tree carries a.gitmodules file and keeps the compile toolset in its own directory. ## The WebView2 requirement and the pinned Microsoft DLL The requirements are short and unforgiving. The tool supports Windows 10 or Windows 11, x64 only, and the README states that x86 and ARM64 are not supported. The Microsoft Edge WebView2 Evergreen Runtime must be installed, and Windows 11 normally includes it. The failure mode is handled deliberately. If the runtime is missing, or WebView2 cannot initialize, iwck shows a startup error and exits instead of displaying a blank window. That is a good decision, because a blank window with a dead keyboard and a dead mouse would be indistinguishable from a working lock, and the person at the machine would have no way to tell that nothing was being blocked at all. The third-party dependency is documented with unusual care. The file webview2/64bit/WebView2Loader.dll comes from Microsoft's Microsoft.Web.WebView2 NuGet package, version 1.0.2957.106, under that package's own licence, and the README publishes its SHA-256: ```text WebView2Loader.dll SHA-256: 271b57e3ec03c436a15d80cafeb9fd1618a43793233d8b05c9446f8de0a51be4 ``` Publishing a checksum for a binary you did not compile is a small thing that more projects should do. It lets a user who downloads the release verify that the file in webview2/64bit is the file from the named NuGet package, and it lets a packager check their own copy. The path it sits at is: ```text webview2/64bit/WebView2Loader.dll ``` The licence situation is the other detail in that section. The DLL is Microsoft's, under the NuGet package's licence, and the project itself is MIT. A tool that ships a Microsoft binary has to be clear about whose terms apply to which file, and the README does that in one sentence. ## Where a keyboard lock stops being the right tool The first limitation is scope. iwck blocks everything, which is the point, and also the constraint. There is no documented way to block only some keys, to keep a function key pair working for a media control, or to set a timer that releases the lock after ten minutes. If you need to type a command, you have to release the lock, and releasing it is a click. The second is the platform. Windows 10 and 11 on x64 only, with no x86 and no ARM64. The tool is a Windows program written in AutoHotkey, so there is no macOS or Linux version, and the WebView2 runtime requirement ties it to the Microsoft web stack. The third is what it does not do. It does not clean the keyboard, it does not remind you to clean it, and it does not tell you whether food is present. It is a way to make yourself stop caring about the keyboard for a few minutes, and if the real problem is that a machine lives in a kitchen, a lock is a mitigation rather than a fix. The fourth is the failure recovery. The exit button restores all input and exits, which handles the ordinary case. The README does not document what happens if the process is killed from outside, or if the machine is rebooted while the lock is active, so a user who wants to be certain that their keyboard will come back should treat the exit button as the only reliable way out and leave the tool in the foreground. There is also the question of what a comparable tool looks like. A hardware keyboard lockout switch on a laptop, or a KVM-style input isolation device, does the same job without software, but those are physical purchases and physical failure modes. A software lock is free, reversible and immediate, and for the narrow case this project addresses, that is the right trade. ## Licence, release rhythm and a decade of small increments The licence is MIT, with the LICENSE file at the repository root, so the script can be read, modified and redistributed with the notice preserved. The project also carries an ahk-compile-toolset directory and a distribution.ahk file, which together suggest the releases are compiled rather than distributed as loose scripts, and the .github directory is where the release automation lives. The release record is steady and recent. Version 3.12 was published on 2026-09-25, 3.11 on 2026-09-18, and 3.10 on 2025-09-28, the same day as the mouse lock release, which suggests the recent pace has picked up around the WebView work. The repository is not archived and the last push was on 2026-09-25. The history entries are dated precisely, which makes the project's shape easy to read: the first release on 2014.10.25, the GDI+ rebuild and the AHK v2-alpha migration on 2020.05.25, the AHK v2.0.4 migration and the switch to Neutron.ahk on 2023.07.26, and the mouse lock plus the graphics interface on 2025.09.28. A twelve-year project with four dated turning points is a good example of a hobby tool that keeps being rewritten rather than abandoned. One thing to know before contributing is that the tree depends on submodules, with .gitmodules at the root and the compile toolset in its own directory, so a clone that skips the submodule step will not build. The Windows-specific path, the WebView2 pinning and the AutoHotkey version are the three things a fork inherits, and each is a maintenance commitment rather than a one-time setup cost. ## Conclusion Adopt iwck if you work on a laptop keyboard with food or a cloth nearby and want one keystroke-proof mode without installing anything heavy, since it is a single AutoHotkey script with a WebView interface. It is the wrong tool for a KVM-style input isolation, for blocking a single key or a subset, for anything that must keep some input working, and for any platform other than 64-bit Windows 10 or 11. Before running it, check that the Microsoft Edge WebView2 Evergreen Runtime is present, and if you are packaging the tool yourself, verify the bundled WebView2Loader.dll against the SHA-256 the README publishes. ## FAQ ### What does iwck actually block? It blocks keyboard input when you click the keyboard button, and restores it when you click again. Since the 2025.09.28 release it can also block mouse input, which takes a ready state, a press of Esc to engage, and another Esc to restore. ### Can keyboard lock and mouse lock be active at the same time in iwck? No. The README states that the two modes cannot be active together, and selecting one mode disables the other first, which keeps the keyboard free so that Esc can still release the mouse lock. ### What are the system requirements for iwck? Windows 10 or Windows 11 on x64, since x86 and ARM64 are not supported, and the Microsoft Edge WebView2 Evergreen Runtime must be installed. If the runtime is missing or fails to initialize, the tool shows a startup error and exits instead of a blank window. ### What third-party binary does iwck ship? The file webview2/64bit/WebView2Loader.dll, taken from the Microsoft.Web.WebView2 NuGet package version 1.0.2957.106 under that package's licence. The README publishes its SHA-256 as 271b57e3ec03c436a15d80cafeb9fd1618a43793233d8b05c9446f8de0a51be4. ### How do I exit iwck and get my keyboard back? The exit button restores all input and exits the program. The README also documents pressing Esc again to release the mouse lock, and clicking the mouse button a second time to cancel the ready state before anything is blocked. ## Sources - [Issues](https://github.com/Nigh/I-wanna-clean-keyboard/issues) - [License: MIT](https://github.com/Nigh/I-wanna-clean-keyboard/blob/master/LICENSE) - [Nigh/I-wanna-clean-keyboard on GitHub](https://github.com/Nigh/I-wanna-clean-keyboard) - [README](https://github.com/Nigh/I-wanna-clean-keyboard/blob/master/README.md) - [Releases](https://github.com/Nigh/I-wanna-clean-keyboard/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nigh-i-wanna-clean-keyboard