Cursor Inline Edit: Editing Code in Place with Cmd+K

Inline edit is a prompt that opens on your selection and rewrites that selection in place, without the chat panel. You stay in the editor, the prompt appears at the code you highlighted, and the result lands on the lines you picked. Cursor's help page describes the job as quick, targeted code changes.

The selection is doing two jobs at once. It says which code you are talking about, and it is also where Cursor applies the change, so a careless selection costs you more than a careless instruction does.

Undershooting and overshooting fail differently. Select too little and the edit is right inside the selection while the caller three lines below still expects the old signature, so the file stops compiling and it reads like the model's mistake. Select the whole file and a one-line request comes back as a diff you have to read line by line, which is most of the review cost you were avoiding by not opening Agent.

My own rule used to be to select exactly the lines you want changed. That is not quite right, and taken literally it is what produces the undershoot. Select the lines you want changed plus whatever has to stay consistent with them. Most of the time that means the whole function rather than the one line inside it.

The loop is five steps, and the fifth one, refining what came back, is the step that tends to get dropped. Cursor documents the sequence like this.

1. 1Select the code you want to change.
2. 2Press Cmd+K on Mac, or Ctrl+K on Windows and Linux.
3. 3Type your instructions. For example, "Convert this to an async function."
4. 4Press Enter. Cursor applies the edit to your selected code.
5. 5To refine, add follow-up instructions and press Enter again.

The widget is smaller than a chat panel and sits in a different place. In Cursor 3An older release label for Cursor's multi-agent interface; current product guidance calls the active surface the Agents Window. Press Enter for the full definition..12 on macOS it is a panel inserted into the file, between the line above your selection and the selection itself, so the code below shifts down instead of being covered up.

The placeholder reads Edit selected code. Around the input sit a scope control labeled Edit Selection, a circular up-arrow that submits, and a close button.

That inserted-panel detail sounds cosmetic, and mostly it is, though it does explain the fifth step. The prompt stays where it was after you submit, with an Add a follow-up input underneath it, so refining the edit is a second sentence in the same place, not a fresh attempt.

Skipping that step costs more than it looks. A proposal that comes back nearly right gets closed, the line gets hand-typed, and nothing is damaged, since a rejected proposal leaves the file exactly as it was. What you have done is type the change twice when one more sentence into the same prompt would have finished it.

The change arrives as a proposal you accept or reject, rather than as an edit already made. In Cursor 3An older release label for Cursor's multi-agent interface; current product guidance calls the active surface the Agents Window. Press Enter for the full definition..12 on macOS the removed line renders red with the added line green beneath it, both inside the file, and the widget header switches to Reject and Accept with the Cmd+Enter chord printed alongside. Each hunk also carries its own Undo (Cmd+N) and Keep (Cmd+Y) buttons at its right edge, and the tab shows an unsaved dot while the proposal is pending.

Reading the hunk before you touch Accept is the habit worth building. When we staged these states in Cursor 3An older release label for Cursor's multi-agent interface; current product guidance calls the active surface the Agents Window. Press Enter for the full definition..12 for this site's UI reference captures, a one-line reword came back with a stray blank line attached that nobody had asked for. Harmless, that one. It arrived inside the same green block as the line we had actually asked for, so the only way to catch it was to read both.

Accepting clears every one of those decorations at once.

Red and green are pending-state colors. The simulator we use to draw these screens for the site had a lingering tint sitting on the accepted line until the capture showed there is none. What stays behind is the modification bar in the gutter and the unsaved dot on the tab, since accepting does not save the file for you. Source Control and that gutter bar are where to look if you want to see what moved after the fact.

How much any of this matters scales with who reads the diff after you. Alone in your own repo, an accepted hunk with two extra lines costs you a git checkout once you notice. Where that line goes into a pull request, the extra lines become somebody else's reading time, and the reviewer has no way to tell which of them you meant. Rejecting and asking again costs one more prompt. On a team with reviewers, reject and re-prompt.

The same prompt has a second mode: instead of editing the selection, it answers a question about it. Switch modes with a modifier on Enter, then ask. The table below shows the two keystrokes per platform.

Cursor's steps put the mode switch before you type, and in practice the order matters. Plain Enter submits your text as an instruction and applies an edit to the selection, so a question typed before the switch goes down the editing path. Switching first removes that possibility.

Once you are in question mode, type your question about the selected code. If the answer includes a change you want, you do not have to retype it as an instruction: type "do it" and press Enter, and Cursor applies the suggested change.

Question mode is probably the least-used part of inline edit, and the reason is fair enough, since Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition. is sitting in the side panel with room for a longer answer. What the inline version saves is the trip out of the file. The answer lands where you are already looking. For anything longer than a short explanation, the panel is still the better surface.

Yes, and the handoff keeps your selection. Inline edit is scoped to the code you highlighted; when a change needs to touch several files or reason across the codebase, that scope stops being useful. Select the code and press Cmd+L on Mac, or Ctrl+L on Windows and Linux. Agent opens with your selected code already attached as context, so you restate the task, not the location.

Both routes live on the same affordance. Select a line in Cursor 3An older release label for Cursor's multi-agent interface; current product guidance calls the active surface the Agents Window. Press Enter for the full definition..12 and the chip that appears on the selection offers Add to Chat `⌘+L` and Quick Edit `⌘+K` side by side.

The table further up gives the keystrokes and says nothing about what the second one costs. You are trading a change bounded by your selection for one that can reach files you have never opened, and everything Agent touches is something you then have to read.

The usual advice to plan before you execute does not carry across this line. Cursor puts Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. on complex features and on tasks that touch many files or systems, and its docs say outright that quick changes can go straight to Agent. A selection-sized edit is about as close to that description as a task gets. Inline edit is narrower again, and if the change does not fit inside what you highlighted, hand it over and read the diff on the other side.