Cursor Tab: How Autocomplete Predicts Your Next Edit

Tab is Cursor's AI-powered autocomplete. It suggests code as you type, and the suggestion arrives as grayed-out text ahead of your cursor rather than in a dropdown you have to open. What separates it from a snippet engine is the input it reads. Three signals feed each prediction:

Of the three signals, linter errors get the least attention. An autocomplete that reads only the prefix can finish the line you are on. Reading the errors already sitting in the file means Tab can propose a fix for something you broke two minutes ago, which is a different job from finishing a line.

Recent edits are the steering input, and that shows up most at the start of a session. Open a file you have not touched today and the first suggestion has little to work from beyond the code around your cursor. Make two or three edits by hand in the direction you are heading and the suggestions narrow to that direction. That is, I think, why Tab reads as inconsistent to people in their first hour with it, when they are sampling it at its coldest. Suggestions that never arrive at all are a separate problem, and the troubleshooting guide lists the four usual causes.

Three keystrokes cover the whole interaction. Accepting is one key, rejecting is a key or simply typing over the suggestion, and there is a third for taking only part of it. The table pairs each action with its key on both platforms.

Word-by-word acceptance is the control worth learning early, and one specific failure is why. A suggestion opens on exactly the right shape and then drifts somewhere in its second half. Take the whole thing and you own a line that reads like your own code, which is the kind of line a reviewer skims instead of checking. Walk into it with Cmd + Right Arrow instead, and keep typing the moment it stops matching what you wanted.

Between the two ways of rejecting, typing over the suggestion is the cheaper one, since it is what you were about to do anyway. Esc is worth the keystroke when the suggestion is long enough to be in your way while you think.

Remapping the accept key is offered, and it is the change I would make last. The pull toward it is indentation muscle memory, and Cursor does let you rebind Accept Cursor Tab Suggestions from Keyboard Shortcuts. The catch is that Tab is the accept key in Cursor's own shortcut reference, so a rebind becomes a local convention that every doc and every colleague pairing with you will get wrong. Rebind it if the conflict is genuinely costing you edits. If it only bites in two file types, use the per-extension switch further down instead.

Yes. A single Tab suggestion is not limited to finishing the line under your cursor. Cursor documents three shapes it can take, and they get progressively larger:

• Modify multiple lines in one accepted suggestion.
• Add missing import statements that your new code needs.
• Suggest coordinated edits across related code.

The import case is the everyday one. Type a call to something you have not imported yet and the import arrives with the suggestion.

The larger shapes change what reviewing a suggestion means, though. A single-line completion you judge from the line you are already reading. Once a suggestion also edits code above your cursor, part of what you accepted sits outside the window you were looking at, so read the diff rather than the line, and read it properly on code you did not write.

Tab predicts where you will edit next, not only what you will type next. Once you have accepted a suggestion, the Tab key changes meaning: press it again and Cursor moves you to the next editing location. The two forms differ in how far the jump reaches.

The key changing meaning is, I suspect, what catches most people, and it catches them the same way every time. You accept a suggestion, your hand is still on Tab, you press it again out of habit, and your cursor is now somewhere else in the file. Nothing is broken by that. You have been moved, and if you did not read where it took you, your next keystroke lands in the wrong place.

No. Cursor's rules documentation answers this one directly: rules do not impact Cursor TabCursor's original autocomplete: multi-line, edit-aware suggestions you accept with the Tab key. Press Enter for the full definition. or other AI features. Rules reach Agent and the chat surfaces; Tab sits outside their scope.

So the levers over Tab are different from the ones over the agent. No rule file reaches it. What it reads is the code around your cursor and what you just did to it, so a convention reaches its suggestions by being present in the file rather than by being written down somewhere.

My first instinct was to treat that as a gap and write the convention into a rule anyway, on the theory that at least the agent would respect it. That is the wrong order of operations. If you want Tab to follow a pattern, put one correct instance of it in the file and start typing the second one. Keep the rule file for the surfaces that read rules.

If you concluded your rule file was broken after watching Tab ignore it, the rules fix page covers where else that test goes wrong.

Two hooks cover Tab specifically. beforeTabFileRead runs before Tab reads a file and returns allow or deny, which is where redaction or access control goes. afterTabFileEdit runs after Tab edits a file and receives the edit range plus the line before and after, enough to drive a formatter or an audit log. Both fire only for Tab, never for Agent.

On a team of five I would not wire either one. The setup cost is real and every hook is one more thing that can break on somebody's machine. That calculus flips where a secret sitting in a file is a reportable event rather than an embarrassment, since beforeTabFileRead runs early enough to redact before Tab sees the contents.

The wording matters if any of this ends up in a written policy. Tab completions are an IDE feature, so neither hook runs in cloud agents. A policy line that reads 'every file Cursor reads passes through our redaction script' does not hold for a cloud agent run, so scope the sentence to the IDE before somebody audits you against it.

Tab has a status indicator in the bottom-right corner of Cursor, and clicking it is how you control the feature. It gives you three levels of off, from a timed pause to a permanent exclusion for particular file types.

• Snooze: disable Tab temporarily for a duration you choose.
• Disable globally: turn Tab off for all files.
• Disable for specific extensions: turn Tab off for certain file types, such as markdown or JSON.

The same settings live under Cursor Settings → Tab. Of the three, the per-extension switch is probably the one you keep: markdown and JSON are where a code-shaped suggestion is mostly noise, and turning Tab off there costs you nothing in the files where you want it. Snooze is for a screen share or a pairing session. Reach for the global switch last, because if the actual complaint is that Tab keeps guessing at your YAML, disabling globally solves it by removing the feature everywhere else too.

Cost is not a reason to switch it off on a paid plan. Cursor's models and pricing page lists unlimited Tab completions on the individual paid plans, and its sizing guidance says daily Tab users always stay within $20 of usage, which is what Pro already includes. Free (Hobby) accounts are the exception: they carry a monthly Tab allowance, and once it is spent suggestions pause until the next billing cycle.