Clink brings Readline-style editing to cmd.exe

The cmd.exe editing gap Clink targets

The native Windows command interpreter has never offered much beyond a single-line buffer and a history that dies with the window. Clink's premise is that this is an editing problem, not a shell-language problem, and that the editing layer can be replaced without replacing cmd.exe itself. The README describes the project as combining "the native Windows shell cmd.exe with the powerful command line editing features of the GNU Readline library". That framing matters: Clink does not reimplement batch syntax, it reimplements the input line.

The audience follows from that. If your scripts are .bat or .cmd files, or if a build system, an installer or a corporate image assumes cmd.exe, switching to PowerShell is a migration project rather than an afternoon's work. Clink targets the person who wants to stay put and get tab completion, searchable history and a prompt that can run logic. The repository ships a complete/ directory of completion scripts and a lua/ directory, which indicates the intent is that users extend the tool rather than only consume it.

How the injection actually works

Clink is not a shell. It is a DLL that attaches to a running cmd.exe process. The README is explicit: "Starting Clink injects it into a cmd.exe process, where it intercepts a handful of Windows API functions so that it can replace the prompt and input line editing with its own Readline-powered enhancements." The repository layout supports this reading. There are detours/ and readline/ directories at the top level, and the project is written in C++.

The practical consequence is that Clink sits between you and the console. The prompt you see and the keystrokes you type are handled by Clink, then handed back to cmd.exe for execution. This is why the prompt can be generated by a Lua script and why the input line can be coloured by context-sensitive completion scripts: those features live in the intercepted layer, not in cmd.exe. It also explains the failure modes. Anything that depends on reading or writing the console buffer directly, or that spawns its own console handling, may not see what it expects. The README points to the issues page for known issues, which is the honest place to check before assuming a given console application will behave.

Installing Clink and a first session

The README lists four installation routes: the setup EXE from the releases page, winget, scoop, or extracting the ZIP to a directory of your choosing. The package manager route is the least ambiguous, so start there. Running the winget command below installs the package identified as chrisant996.Clink.

winget install --id chrisant996.Clink -e

With scoop the equivalent is a single install of the clink package.

scoop install clink

If you used the setup EXE, it offers an option labelled "Autorun when cmd.exe starts". If you did not use the setup EXE, or you want to change that decision later, the README gives the autorun commands directly. Installing autorun means every new cmd.exe window comes up with Clink already attached.

clink autorun install

To reverse it, the counterpart command is clink autorun uninstall. If the Clink install directory is not on your PATH, the README says to use install_dir\clink in place of clink. Once Clink is injected into a cmd.exe process it sets an alias, so inside that window the short form works.

For an existing window rather than a new one, clink inject attaches to the running process.

clink inject

You do not need to configure anything to get value. History is saved between sessions, Tab and Ctrl-Space perform match completion in two different ways, and Alt-h lists the current key bindings. Alt-Shift-/ followed by another key reports what command is bound to it, which is the fastest way to learn the default map before you start overriding it.

Where Clink is the wrong tool

The injection model is the limitation. Clink depends on intercepting API calls inside a specific cmd.exe process, so it is a Windows-only, cmd.exe-only tool by construction. If your work has moved to PowerShell, Windows Terminal profiles, or WSL, Clink adds nothing, because those environments already provide completion and history through their own mechanisms. Adopting it there is effort spent on a layer you are not using.

There is a second boundary around compatibility. The README notes that the new Clink tries to be as backward compatible with Clink v0.4.9 as possible, but that upgrading may in some cases require configuration work, with details in the documentation. That is a candid admission that configuration written against the old version is not guaranteed to carry over untouched. If you have a heavily customised setup, treat a major upgrade as a change to be tested rather than applied.

The build instructions carry their own constraint. The README states that only the VS toolset is supported, and that anyone trying MinGW must use the msvcrt version because setjmp does not link in the URT version. That is a narrow supported path for anyone intending to compile from source rather than install a release.

Clink against plain cmd.exe and PowerShell

The real alternative is not another add-on, it is not using cmd.exe at all. PowerShell differs in approach at the root: it is a shell with an object pipeline and its own parser, so completion and history are functions of the shell rather than of an injected editing layer. Clink leaves the batch language intact and swaps the input surface. If your scripts are already PowerShell, Clink cannot help you, and if they are batch files, PowerShell is a rewrite rather than an upgrade.

The closer comparison is stock cmd.exe. The difference is not cosmetic. Stock cmd.exe gives you a fixed prompt, no persistent history, and completion limited to path expansion. Clink adds saved history across sessions, an interactive completion list on Ctrl-Space, auto-suggestions drawn from history, files and completions, and a prompt that Lua can compute at render time. The README describes the scriptable prompt as something "never before possible in cmd.exe", which is accurate in the sense that cmd.exe offers no equivalent hook.

The cost of that difference is a dependency on an injected DLL inside your command interpreter. That is a real architectural commitment, and it is the thing to weigh against the convenience.

Upgrade cadence, licence and documentation build

The release history is dense. v1.9.34, v1.9.33 and v1.9.32 arrived on 2026-09-21, 2026-09-14 and 2026-08-24 respectively, and the last push to the repository was on 2026-09-22. That cadence means upgrades are frequent enough that pinning a version and reading the CHANGES file before moving is reasonable practice. The repository also carries CHANGES.older.md, so the changelog history is preserved rather than discarded.

Clink is licensed under GPL-3.0. For individual use on a workstation that is unremarkable. For redistribution inside a commercial product, the copyleft terms are the thing to examine with your own counsel; this article does not give legal advice and the LICENSE file is the authoritative text.

One build detail worth knowing if you ever rebuild the documentation: the README pins marked to version 2.0.1 and states that newer versions introduced breaking changes that the documentation build has not been rewritten to accommodate. It also notes the security fixes in newer marked versions are not relevant because marked is used only at build time with known inputs. The Python dependencies (fonttools, brotli, lxml) exist to subset the Caskaydia Cove nerd font, reducing the bundled woff2 from roughly 1220 kB to about 12 kB so it can ship inside clink.html.

Extending Clink with Lua

The Lua API is where Clink stops being a convenience and becomes infrastructure. The README says Clink "can be extended through its Lua API which allows easy creation of context sensitive match generators, prompt filtering, and more". The repository reflects that: there is a lua/ directory, an embed.lua file, a .luacheckrc for linting Lua sources, and a LUANOTES.md alongside it. The presence of a linter configuration suggests Lua scripts are treated as first-class source rather than as an afterthought.

Match generators are the part most teams will touch. A generator decides what candidates appear for a given command line context, which is how completion for a bespoke internal tool gets added without patching Clink itself. Prompt filtering is the other common entry point, and it is what makes the scriptable prompt practical: the prompt can reflect state rather than being a fixed string.

The trade-off is that Lua scripts are configuration you now maintain. The README does not document a rollback path for a broken script, and a prompt filter that errors on every keystroke is a bad place to discover that. Keep custom scripts small and test them in a scratch window before wiring them into your default profile.

Editorial conclusion

Clink is for engineers who must keep cmd.exe, usually because of batch files, legacy build scripts or locked-down Windows hosts, but want completion, persistent history and a scriptable prompt while doing it. It is not for anyone already working in Windows Terminal with PowerShell or WSL, since those shells provide comparable editing without an injected DLL. Before adopting it, verify that your environment permits the injection mechanism, that your security tooling does not block it, and check the CHANGES file against the v1.9.34 release notes for anything affecting your existing configuration.

Frequently asked questions

Official sources

1. chrisant996/clink on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases