Ctrl+N = "Undo" Behavior Destroys In-Progress Copilot Edits

Question

Feedback: Ctrl+N "Undo" Behavior Destroys In-Progress Copilot Edits

From: DaveMcom (daily Copilot user) Created: 2026.02.09 Target: VS Code Copilot team / GitHub Copilot feedback channel

---

The Problem

Ctrl+N in VS Code triggers "Undo" on pending Copilot edits instead of opening a new file/buffer.

Every other application on the planet — including VS Code itself for non-Copilot contexts — uses Ctrl+N to mean "New File" or "New Buffer." Copilot hijacks this universal keybinding to mean "reject/undo the current edit suggestion."

This is not a minor UX papercut. This is a data-destroying, workflow-breaking, muscle-memory-hostile defect.

---

Scenarios Where This Causes Real Damage

1. Mid-Run Edit Loss

Copilot is in the middle of a multi-file edit run. It has proposed changes to 3 files. I see something interesting and reflexively hit Ctrl+N to open a scratch buffer to write a note. The pending edits are undone. Work is lost. The agent has to redo the edits or — worse — I don't notice some edits were reverted and commit partial state.

2. Reviewing Edits + New Buffer

I'm reviewing a Copilot edit diff. I want to compare it with something, so I hit Ctrl+N to open a new tab to look at a reference. The edit I was reviewing is gone. I now have to re-request it.

3. Start of Session

I sit down, VS Code has some pending Copilot edits from a previous session or a background run. Before I've even oriented myself, I hit Ctrl+N (habit: open a buffer to plan my day). Edits I haven't even looked at yet are destroyed.

4. Compounding Cost

Every undone edit costs money (API calls to regenerate), time (re-prompting, re-waiting), and context (the agent may not reproduce the same edit). For complex multi-step operations, losing edits mid-stream can mean 5-15 minutes of rework per incident. This happens multiple times per day.

---

Why This Is Insidious

• Muscle memory is undefeatable. Ctrl+N = New File is burned into every developer's fingers from decades of use across every text editor, IDE, browser, and office application.
• No confirmation dialog. The undo is instant and silent. There's no "Are you sure you want to discard these edits?"
• No redo. Once Ctrl+N undoes the edit, it's gone. You can't Ctrl+Z to get it back.
• Invisible trigger. The user doesn't even know they've triggered an undo. They expected a new file tab. Instead, pending changes vanished.

---

What Should Happen

Option A (Preferred): Ctrl+N should ALWAYS mean "New File." Bind the Copilot undo action to a different, non-conflicting key (e.g., Ctrl+Shift+Backspace, or a dedicated Copilot key chord like Ctrl+K Ctrl+U).

Option B: If Ctrl+N must serve double duty, show a confirmation: "You have pending Copilot edits. Discard them? [Yes / No / New File Instead]"

Option C (Minimum): Allow users to unbind Ctrl+N from the Copilot undo action without breaking other Copilot functionality. Currently the keybinding overlap makes this difficult.

---

Severity Assessment

FactorRatingFrequencyMultiple times per dayData lossYes — pending edits destroyedCost impactAPI call waste (re-generation)WorkaroundNone (muscle memory)User expectation violationMaximum (universal keybinding hijacked)Discoverability of the problemZero (silent, instant, no feedback)---

Environment

• VS Code (latest stable)
• GitHub Copilot extension (latest)
• Windows 11
• Used daily for 8+ hours

---

Summary

Ctrl+N hijacking is the kind of defect that looks like a feature in a design doc ("convenient undo!") but functions as sabotage in practice. It fights the single strongest keybinding in computing history. Please fix it.