Ctrl+C: Copy or Kill? – Stop it from cancelling Claude Code

This article is one chapter of my book Delphi in all its glory – AI-assisted development, the fifth book of the series.

In Windows, Ctrl+C means Copy. In a terminal, it means Stop. In Claude Code, it means whichever one you did not want.

I press Ctrl+C by reflex. In Claude Code, one stray press cancels whatever Claude is doing. Worse, it can also stop the background agents. One accidental Ctrl+C, and my Android64 and macOS build of LightCore died mid-run:

  Background agent Android64 and macOS build of LightCore was stopped by the user

You cannot fix this inside Claude Code. Its keybindings page puts Ctrl+C on the list of shortcuts that “cannot be rebound” (code.claude.com/docs/en/keybindings). Somebody asked Anthropic for an exit confirmation (GitHub issue #64975). A bot closed it as “not planned”, for inactivity. So the fix goes one level lower, into Windows Terminal.

Windows Terminal binds Ctrl+C to Copy, but Copy keeps the key only when Windows Terminal has a selection. With nothing selected, “the key chord is sent directly to the terminal” (Microsoft’s words). And if you run Claude Code in fullscreen mode, Windows Terminal almost never has a selection: the mouse selection belongs to Claude Code, which copies it the moment you release the mouse button. While that text is still highlighted, Claude Code treats Ctrl+C as Copy too. The accident happens when nothing is highlighted.

The trick: bind Ctrl+C to an action that always swallows the key and does no harm. Scroll to Bottom is such an action. Press Ctrl+Shift+, to open Windows Terminal’s settings.json, and change the Ctrl+C line in the “keybindings” section to this (add it if there is none):

  { "id": "Terminal.ScrollToBottom", "keys": "ctrl+c" }

Why this one? In Windows Terminal’s source code, the Scroll to Bottom handler (AppActionHandlers.cpp) always marks the key as handled. Copy marks it handled only when there is a selection. A comment in ControlInteractivity.cpp even says why: so that “ctrl+c without a selection can still send ^C”. And don’t try “unbound”: an unbound key “will pass to the underlying terminal”, which is the exact problem.

I tested it both ways. In a PowerShell tab, ping -t localhost kept running after Ctrl+C. In a Claude Code tab, I pressed Ctrl+C while Claude was working. Nothing happened.

The price: Windows Terminal has one set of key bindings for all tabs. A profile cannot have its own (issue #5790, still open). So Ctrl+C is now dead in every tab, PowerShell and cmd included. Copying still works: in Claude Code, selecting with the mouse copies; in the other tabs, use Ctrl+Shift+C or Ctrl+Insert. To stop Claude on purpose, press Esc. I never use Ctrl+C to stop anything, so for me the price is zero.

One warning before you relax. Anthropic’s release notes for version 2.1.47 say background agents “continue running when you press ESC to cancel the main thread”. A bug report from the Claude Code desktop app on macOS (issue #76807) says the opposite: an Esc interrupt killed every running background agent. A bot, not a developer, closed that report. I have not tested Esc. Blocking Ctrl+C protects you from accidents, not from yourself.

Tested 2026-09-13 on Windows 11, Windows Terminal 1.24.11911.0 and Claude Code 2.1.270 in fullscreen mode.


This was one chapter of a whole book

You just read one chapter of Delphi in all its glory – AI-assisted development: more than 400 pages about Claude Code and AI for Delphi programmers. Written by a Delphi programmer, with the failures documented next to the wins.

Leave a Comment

Scroll to Top