This release is about the keyboard and the mouse inside a terminal. Cordy's terminal now speaks both keyboard protocols Windows CLIs rely on, so the newline keys those CLIs advertise in their own footers — Shift+Enter in Claude Code, Shift+Enter and Ctrl+J in Codex — insert a newline instead of submitting the message. A TUI that asks for the mouse gets it back, with Shift+drag to select text. And a terminal tab opened after startup no longer occasionally begins life having missed the first bytes of its own session. Around that: the CPU / memory chip regains a compact overview, the toolbar's editor button opens your editor in one click, and the app moves to Electron 42.11.3 for the current Chromium security fixes.
Added
- Both keyboard protocols Windows CLIs rely on — so Shift+Enter means
newline. Cordy's terminal now enables win32-input-mode (the protocol Windows
Terminal always runs, read by CLIs that consume console input records) and the
kitty keyboard protocol (read by CLIs that consume VT bytes). With neither of
them on, the terminal could not express a modifier on Enter at all:
Shift+Enter and Ctrl+Enter left as a bare carriage return — the same byte a
plain Enter sends — so every CLI in a Cordy pane read them as "submit". Each
CLI now gets the key its own documentation promises: in Codex, Shift+Enter and
Ctrl+J insert a newline; in Claude Code, Shift+Enter does. Cordy encodes
keystrokes faithfully and adds no remappings of its own — which key means what
stays the CLI's decision — and the newline keys were verified against the real
Codex CLI, not simulated. Both protocols are inert until a program asks for
them, so a pane running a plain shell is unchanged byte for byte. Chinese IME
composition is unaffected: a key-release guard keeps the IME's own internal key
events off the wire. The bundled Windows Terminal ConPTY pair moves to
1.25.2603.03002— the same pair VS Code ships to its own users, from the preview line rather than a stable Windows Terminal release — because it is the build that re-encodes a keystroke as the kitty protocol's form for a CLI that asked for it. One consequence worth knowing: inside a CLI that turned the kitty protocol on, Ctrl+C arrives as that protocol's key event instead of the raw interrupt byte, and the CLI handles it — the specified behaviour of every terminal implementing the protocol, Windows Terminal, kitty and ghostty included. Where no CLI asked, Ctrl+C is the interrupt byte exactly as before. - A compact performance overview, back on the chip. Clicking the toolbar's CPU / memory chip opens a small popover again: live memory and CPU charts over a 2m / 10m / 1h window, the six heaviest app processes with what each one is hosting, a Workload line totalling the Rust runtime, shells and agents, and buttons to choose which numbers the chip itself displays. View details opens the full monitor 0.3.0 introduced, which is unchanged — the overview is the part of the old popover that was worth keeping.
- The toolbar's editor button opens your editor in one click. In the compact top bar it was a single control that could only open a menu, so launching an editor always cost two clicks. It is now split in two: the left half opens the current workspace in your default editor immediately and wears that editor's own icon (its tooltip names it), and the chevron on the right opens the list to pick a different one. Picking one from the list makes it the new default.
Fixed
- A terminal tab opened after startup could miss the first bytes of its session. A new tab could come up having never received the one-shot terminal setup its session had already emitted — focus reporting, and the keyboard protocol above — because the pane was still subscribing while those bytes were broadcast. Ordinary output survived that window (the terminal repaints itself), but a one-shot mode never comes back, so that tab alone silently fell back to the old encoding with nothing visibly wrong. Every new terminal is now reconciled against the runtime's own snapshot, exactly the way a reattached one already was, so nothing produced before the tab could listen is lost.
- The quit confirmation fills its own window. When Cordy has been closed to the tray, the quit prompt opens as a standalone window — but it drew the same floating, bordered card it uses inside the app, so it appeared as a small boxed dialog framed inside another small window. It now fills the window it owns.
- Importing passwords from CSV starts in your download folder. The Password vault's Import from CSV chooser opened wherever the system decided; it now opens in the download directory Cordy is configured to use, which is where a password manager's export actually lands.
Changed
- A TUI that asks for the mouse now gets it. 0.3.0 made an ordinary drag select text even while a TUI held mouse reporting on, at the price of the application never receiving the mouse at all: a clickable or hoverable TUI — Claude Code's in-session agent list, for one — saw a click only while you held Alt, and never saw hover. That trade is reversed. Clicks, drags and hover go to the application, and selecting text there is Shift+drag — the gesture every other terminal uses, and the one Claude Code's own footer tells you about — followed by Ctrl+C or Ctrl+Shift+C to copy. On macOS the Option key forces a selection too (which costs Alt block-select on that platform; Windows and Linux keep both). Ctrl+C with no selection is still an interrupt, unchanged.
- Electron 42.11.3, and a dependency refresh. The 42.11 line carries the current Chromium security fixes (Chromium 148, Node 24.19) — which matters because Cordy's browser pane loads arbitrary pages. Alongside it: xterm 6.1 beta.304 with Cordy's IME patch re-derived unchanged, React 19.3, tiptap 3.31, and electron-builder 26.16 for packaging.
- WebSQL is no longer listed as clearable site storage. Chromium removed WebSQL, so the bucket Settings → Site data offered to wipe for a site had not existed for some time. Everything else a per-site clear covers — cookies, local storage, IndexedDB, caches, service workers — is unchanged.
Known Limitations
- The Windows installer is not code-signed. SmartScreen will show its "unrecognised app" interstitial on first run; choose More info → Run anyway. A certificate is a planned purchase, not something a self-signed build can fix.
- The monitor's Workload half is Windows-only. On macOS and Linux it says so and shows the App half alone; the compact overview's Workload line follows the same rule and is simply absent there.