Keyboard shortcuts look like a beginner's topic right up to the first time a capability does not work. Cursor publishes a separate shortcut reference for general actions, the conversation with the agent, pointed edits, context, suggestions and the terminal. All of them can be remapped in the settings, and that is what creates a non-obvious class of problems: a conflict with a system shortcut or an extension looks like a broken feature rather than an intercepted key.
The naive reaction to such a breakage is a reinstall or a bug hunt. The right one is to check who intercepts the shortcut. The terminal, the shell, the window manager, an editor extension and the editor itself stand earlier or later in the queue, and the same combination behaves differently in another environment. Focus is a separate trap: inside the terminal some shortcuts go to the shell rather than to the editor, and the same keystroke gives a different result depending on where the cursor is.
It helps to lay the basic actions and shortcuts out in a table once: open the agent, invoke a pointed edit, add the selection to the conversation, switch the mode, accept and reject a suggestion, start a review in the command line. Below is that map. It is not a full reference but the minimum worth turning into a reflex: those are exactly the actions repeated dozens of times a day.
| Action | Default shortcut |
|---|---|
| Show or hide the side panel | Cmd/Ctrl+I |
| Inline Edit | Cmd/Ctrl+K |
| Add the selection to a new conversation | Cmd/Ctrl+L |
| Switch the mode | Shift+Tab |
| Accept a suggestion | Tab |
| Accept a word of the suggestion | Cmd/Ctrl+right |
| Review in the command line | Ctrl+R |
The diagnosis takes a minute and always follows one path. First you check whether the action works another way: if it is invoked without the key and fires, the problem is in the shortcut rather than in the capability. Then you look at the shortcut settings - there it is visible whether the combination is assigned to something else. If that is clean too, the interception happens outside the editor, and two candidates remain: the system and a third-party program sitting on global keys. The conclusion from the diagnosis is always the same - remap what conflicts instead of hunting for a breakage in the product.
Deep links are a separate topic. Cursor understands its own address scheme: it opens a conversation with a ready prompt, a command or a project rule, while a separate link installs an external server. That is convenient for documentation and onboarding: a link in a task description leads not to a general section but straight to what needs to be looked at. But the convenience has a price worth knowing in advance.
A link that installs an external server contains an encoded configuration. Formally that is just convenient packaging; in fact it is an executable decision that arrives with one click. Encoding is not a security review: it hides the content from the eye rather than making it safe. Before distributing such a link inside a team, the expected target is documented and people are shown the decoded configuration - otherwise installation becomes trust in the dark.
From there follows a natural transition to onboarding. A good outcome is not that a new developer receives your settings but that they can open the repository and prove a working baseline: the required extensions, settings, rules, skills and one verification task that must pass. Such a set is versioned together with the project and does not depend on what has accumulated on a particular machine.
Not every verification task will do. Building the project is not enough: a build touches neither rules nor skills nor external servers, and a green build says nothing about the agent's environment. What works is a task that goes through the whole configured path: the agent reads the project rules, calls a connected tool and runs into a prepared handler, and the result is visible to the eye. Then its failure names the broken link immediately instead of leaving a person alone with a general feeling that something is off.
The engineering conclusion is simple: a reproducible environment beats a transferred one. Importing someone else's state saves an hour at the start and costs days of untangling later, because along with the settings come their key remappings, disabled checks and forgotten experiments. A list of requirements plus a verification task give the same convenience without the legacy: any new person gets an environment in half an hour where it is clear what should work and how to check it.
The typical failures are predictable. Blaming an intercepted shortcut on a broken feature. Handing out an install link with an encoded configuration without explaining what exactly it adds. Treating a settings import as onboarding. And having no verification task - then a new developer learns about a broken environment on their first real assignment.