Cursor зависает и тормозит: что известно о фризах, памяти и Agent в 2026 году

В 2026 году на официальном форуме Cursor действительно появился устойчивый поток жалоб на фризы, высокий расход памяти, медленный интерфейс и зависающие действия Agent. Но доступные данные не подтверждают одну массовую аварию с общей причиной. Одинаковый внешне симптом дают разные слои: renderer интерфейса, Extension Host, индексация, language server, терминал, сетевой запрос к модели, удалённая среда или конкретная версия Electron. Поэтому начинать нужно не с переустановки и удаления профиля, а с ответа на два вопроса: что именно зависло и какой процесс в этот момент растёт.

Материал проверен 6 сентября 2026 года. Если Cursor завис прямо сейчас, сначала сохраните файлы и изменения Git, остановите активные локальные агенты, откройте Developer: Open Process Explorer, проверьте Cursor Status и только затем меняйте по одному параметру.

Действительно ли это волна жалоб

Форумная активность измерима. В публичной выборке официального форума с тегом performance с 7 января по 6 сентября 2026 года было 643 темы. Механический отбор заголовков со словами о зависаниях, падениях, памяти, CPU, OOM, медленной работе и утечках оставил 347 тем; 107 из них одновременно упоминали Agent, chat, Composer или Agents Window/Glass. Пик этой выборки пришёлся на март — 71 тема, в апреле было 59.

Эти числа подтверждают поток жалоб, но не распространённость проблемы. Один человек может создать несколько тем, темы могут дублировать один дефект, а тег performance охватывает не только фризы. Неизвестно и число активных установок Cursor. Корректный вывод такой: жалоб много, они идут весь год, несколько конкретных дефектов признаны командой Cursor, но доказательств единого массового сбоя нет. Текущие темы можно увидеть в разделе форума Performance.

Официальная статус-страница отражает другой класс событий. Например, 1–4 сентября там фиксировались и затем были закрыты инциденты Grok 4.5, Grok 4.6, моделей OpenAI и Anthropic, Automations и Cloud Agents. Такие события объясняют ошибки и долгие ответы с живым интерфейсом, но не локальный рост renderer до нескольких гигабайт.

Хронология заметных жалоб и подтверждённых проблем

В таблице собраны не «все пострадавшие», а репрезентативные случаи, где есть версия, ОС или полезная диагностика. Статус «тема закрыта» не означает, что дефект исправлен.

Дата и версия	Что наблюдали	Что подтверждено	Статус на 6 сентября 2026 года
15 января, 2.3.35, Windows	Renderer падал по OOM; автор связал рост памяти с повторяющимися ошибками OpenTelemetry	Подробные логи есть, но опубликованная первопричина — вывод автора темы	Тема закрыта; публичного основания переносить причину на другие версии нет
21 февраля, 2.5.20, Windows	В маленьком проекте renderer Agent рос примерно с 600 МБ до более 5 ГБ и падал каждые несколько минут	Воспроизводимый пользовательский замер отделил renderer от main, extension host и GPU process	Обсуждение собрало несколько похожих ответов; это не оценка частоты среди всех пользователей
9 марта, 2.6.26, Linux	Во время генерации Agent тормозили меню, редактор и терминал	Поддержка предложила сравнить extensionHost и ptyHost, запустить без расширений, проверить Wayland и GPU	Тема закрыта 6 мая без публично установленной единой причины
3 мая, 3.2.16, macOS	Создание multi-root workspace в Agents Window резко нагружало Mac с 16 ГБ RAM	Сотрудник Cursor назвал известной проблему Glass с несколькими корнями и сообщил, что её отслеживают	Временные меры: Editor layout, один корень на окно, перезапуск; ETA не был указан
20 мая, 3.4.20, macOS	Agent стабильно застревал после Grep/Glob на Explored 2 searches	Сотрудник Cursor подтвердил отслеживаемую проблему этого пути	Рекомендованы Stop/повтор, Reload Window и Request ID; срока исправления не было
18 августа, 3.16.17, macOS	После 1–2 дней Agents Window держал высокий CPU без активной генерации, память не возвращалась к прежнему уровню	Сотрудник Cursor подтвердил, что проблема renderer долгой сессии отслеживается	Надёжная временная мера — остановить локальные задачи и перезагрузить окно или полностью выйти; ETA не указан
4 сентября, 3.19.7, Linux	После обновления вырос расход RAM, окно завершалось с clean-exit, code 0	Сотрудник Cursor подтвердил Linux-специфичную проблему runtime/Electron в 3.19.x	Исправление готовится; временно рекомендован официальный откат на 3.18.25

Последняя строка особенно важна. Подтверждение относится к Linux 3.19.x и сигнатуре clean-exit, code 0. Жалобу Windows из той же темы нельзя автоматически считать тем же дефектом.

Перед диагностикой сохраните работу

Фриз — плохой момент для экспериментов с профилем. Перед перезапуском или изменением настроек:

• сохраните открытые файлы;
• выполните git status --short и просмотрите git diff;
• зафиксируйте важные изменения коммитом в рабочей ветке или сделайте копию проекта, включая неотслеживаемые файлы;
• запишите версию Cursor из About Cursor и сделайте снимок Process Explorer;
• остановите или дождитесь локальных Agent-задач: Developer: Reload Window прервёт процессы этого окна;
• экспортируйте или скопируйте критичные настройки перед переустановкой либо очисткой состояния.

Не удаляйте вслепую %APPDATA%\Cursor, ~/Library/Application Support/Cursor, ~/.config/Cursor, workspaceStorage, state.vscdb или весь каталог .cursor. Там могут находиться настройки, локальная история, состояния рабочих пространств и чаты. Сначала сделайте backup, затем используйте штатные команды вроде Clear Editor History, если симптом соответствует их назначению. Restore Checkpoint помогает откатить действия Agent, но документация Cursor прямо отделяет локальные checkpoints от постоянного контроля версий Git.

Быстрая диагностика: найдите перегруженный слой

Откройте палитру команд и запустите Developer: Open Process Explorer. Смотрите не только на общий процесс Cursor, а на тип процесса и изменение нагрузки в течение нескольких минут.

Симптом	Что проверить	Безопасное первое действие
Меню, ввод и панель Agent лагают; растёт window или renderer	Повторяется ли в обычном Editor layout, новом чате и пустом workspace	Сохранить работу, остановить локальные агенты, Developer: Reload Window
Растёт extensionHost, пропадают Git, расширения или AI-функции	Запуск с cursor --disable-extensions	Если стало нормально, включать расширения по одному или отключать только для workspace
Растёт ptyHost, зависает терминал	Завершилась ли команда на самом деле, ждёт ли ввод, не запущен ли watcher/server	Прервать одну команду и повторить её вручную в новом терминале
Нагрузку создаёт процесс TypeScript, Python, Java, Rust и другого языка	Output соответствующего language server, число открытых корней, generated-файлы	Исключить артефакты сборки из наблюдения и индекса, временно отключить одно языковое расширение
Интерфейс жив, но Agent не отвечает	Status, Network Diagnostics, Request ID, Developer Tools Console	Остановить запрос, проверить статус, повторить маленький запрос в новом чате
Проблема только через SSH, WSL или контейнер	CPU/RAM/disk удалённой среды, SSH-канал, remote logs, credential prompt	Переподключиться и сравнить ту же команду в обычном remote terminal

Меняйте одну переменную за тест. Если одновременно очистить кэш, отключить расширения, сменить модель и переустановить Cursor, причина останется неизвестной, а проблема может вернуться.

UI и renderer: когда зависает само окно

Renderer отвечает за отрисовку интерфейса Electron. Его признак — тормозит не только ответ модели: запаздывают меню, набор текста, переключение вкладок или вся панель Agent. При этом window/renderer растёт в Process Explorer, а extensionHost и ptyHost могут оставаться спокойными.

Порядок действий:

1. Зафиксируйте CPU и память renderer в покое, во время одного запроса и спустя пять минут после завершения.
2. Откройте новый чат без длинной истории и повторите короткий запрос.
3. Если вы работаете в Agents Window, сравните поведение с обычным Editor layout.
4. Закройте ненужные долгие чаты и окна, остановив активные локальные задачи.
5. Выполните Developer: Reload Window. Если окно уже не отвечает, полностью выйдите из Cursor и откройте его снова.

Перезапуск — временное восстановление, а не диагноз. Если память одного renderer снова монотонно растёт в минимальном сценарии, сохраните график и переходите к отчёту об ошибке.

Extension Host и расширения VS Code

Cursor поддерживает экосистему расширений, и отдельное расширение может перегружать Extension Host, запускать свой language server, следить за файлами или конфликтовать с другим AI-ассистентом. В этом случае общий ярлык «Cursor течёт» вводит в заблуждение.

Официальный A/B-тест безопасен: полностью закройте Cursor и запустите cursor --disable-extensions. Команда не удаляет расширения. Если зависание пропало, включайте их по одному, начиная с языковых серверов, контейнерных и удалённых инструментов, Git-интеграций и других AI-помощников. Расширение можно отключить только для текущего workspace, сохранив его для остальных проектов. Читать полный обзор сервиса Cursor

Если проблема остаётся без расширений и растёт именно renderer, перестаньте обвинять Extension Host. Если растёт extensionHost, приложите к отчёту его имя, CPU/RAM и минимальный набор расширений, который воспроизводит сбой. Официальная инструкция рекомендует именно изоляцию, а не удаление всей коллекции.

Индексация workspace и файловые наблюдатели

Индексация чаще проявляется при открытии конкретного большого репозитория: нагружаются CPU и диск, Agent долго ищет файлы, а маленький проект работает нормально. Частые источники шума — node_modules, .next, dist, build, coverage, кэши, сгенерированные SDK, большие логи, датасеты и каталоги со множеством меняющихся файлов.

Добавьте в .cursorignore только то, что Agent действительно не должен читать, например:

node_modules/
.next/
dist/
build/
coverage/
*.log

После этого выполните штатную переиндексацию из палитры команд и сравните число файлов и нагрузку. Не исключайте весь src, корень монорепо или конфигурацию, нужную для ответа: .cursorignore блокирует эти файлы для Agent, поиска по кодовой базе и @-упоминаний. И не считайте ignore-файл барьером для любых инструментов: терминал и MCP могут читать файлы вне контроля AI-контекста.

Если фриз воспроизводится во время создания multi-root workspace в Agents Window, проверьте каждый корень отдельно. Для подтверждённого майского случая команда Cursor предлагала временно использовать один корень на окно или Editor layout.

Language server: TypeScript, Python, Java, Rust и другие

Language server анализирует проект для подсказок, диагностики и навигации. Его нагрузка часто ошибочно записывается на счёт индекса Cursor. Признаки: проблема зависит от языка или конкретной папки, в Output повторяются ошибки одного сервера, а процесс Node/Java/Python/Rust растёт независимо от активности Agent.

Проверьте три сценария:

• тот же репозиторий без Agent;
• маленькая папка с несколькими исходниками того же языка;
• текущий workspace без конкретного языкового расширения.

Уберите из анализа generated-код, виртуальные окружения, build-каталоги и вложенные зависимости средствами самого language server и files.watcherExclude, если это соответствует его документации. Не выключайте все подсказки навсегда: задача теста — найти конкретный сервер или набор файлов.

Agent завис на Thinking, Grep, Glob или вызове инструмента

Если редактор отзывчив, а остановилась только цепочка Agent, сначала рассматривайте tool loop, сеть и backend. В мае команда Cursor отдельно подтверждала зависание после Grep/Glob. Без Request ID внешне одинаково выглядят таймаут сервера, потерянный поток ответа, зависший локальный инструмент и модель, которая повторяет один шаг.

Безопасная последовательность:

1. Нажмите Stop и не отправляйте пять одинаковых продолжений в тот же зависший turn.
2. Скопируйте Request ID из меню этого чата.
3. Откройте новый чат и сформулируйте один маленький проверяемый шаг: конкретный файл, команда и ожидаемый результат.
4. Посмотрите кольцо контекста. Уберите ненужные вложения, большие папки, старые диффы и лишние MCP-инструменты.
5. Если зависает один MCP, откройте Output → MCP Logs и временно отключите только этот сервер.
6. Если проблема повторяется после Grep/Glob в малом проекте, приложите Request ID и точный путь поиска к баг-репорту.

Новый чат полезен не потому, что «стирает утечку памяти», а потому, что даёт чистый контекст и новую цепочку инструментов. Длинный чат может быть тяжёлым, но модельный контекст и память процесса — разные величины.

Терминал и shell: Agent может ждать не там, где кажется

Agent запускает команды через терминальный слой. Spinner может остаться, если команда ждёт пароль, подтверждение, ввод, GUI credential helper, завершение watch-процесса или shell hook. Иногда сборка закончилась по выводу, но дочерний процесс продолжает работать.

Скопируйте команду и запустите её вручную в новом терминале того же workspace. Проверьте:

• появляется ли prompt, который Agent не может обслужить;
• завершается ли процесс с кодом возврата;
• не стартует ли dev server, watcher или REPL;
• отличается ли поведение при CI=1, который Cursor задаёт для Agent-команд;
• не блокирует ли Git credential helper или askpass удалённую сессию;
• растёт ли ptyHost в Process Explorer.

Прерывайте конкретную команду после сохранения нужного вывода. Не завершайте все процессы Cursor через диспетчер задач, пока не проверили незаписанные файлы и локальные агенты. В Remote SSH одинаковая команда в обычном терминале и в Agent может иметь разное окружение и разные способы запроса credentials — это полезный минимальный тест, но он ещё не устанавливает причину сбоя.

Network, provider и ошибка 429

Когда интерфейс работает, но ответы приходят медленно, обрываются или возвращают 429/timeout, локальная очистка кэша редко является первым шагом.

Проверьте по порядку:

1. Статус Cursor и выбранного провайдера/модели.
2. Cursor Settings → Network → Run Diagnostics.
3. VPN, прокси, корпоративный TLS inspection и другую сеть как A/B-тест.
4. Request ID и красные ошибки в Help → Toggle Developer Tools → Console.
5. Другую модель только для разделения provider-specific инцидента и общего сбоя.

429 означает ограничение частоты или ёмкости, а не нехватку RAM на компьютере. Не пытайтесь обойти его массовыми параллельными запросами. За корпоративным прокси официальная документация предлагает HTTP Compatibility Mode → HTTP/1.1, если HTTP/2 блокируется; после изменения нужен перезапуск. Не отключайте файрвол, проверку сертификатов или защиту endpoint ради быстрого теста.

Память, история чата и контекст — три разные вещи

Слово «память» в обсуждениях Cursor обозначает как минимум три объекта:

• оперативную память процесса Electron;
• локальную историю и состояние интерфейса;
• контекстное окно модели в токенах.

Контекстное окно заполняют сообщения, файлы, правила, инструменты, MCP и результаты вызовов. Когда оно приближается к лимиту, Cursor сжимает старую часть разговора. Это может ухудшить точность, добавить поисковые шаги или задержку, но не позволяет по одному индикатору контекста диагностировать renderer leak.

Практическое правило: одна законченная функция или одна причина сбоя — один чат. При смене задачи начните новый и приложите только необходимые файлы, @Commit или @Branch, а не весь репозиторий. Если OS RAM всё равно растёт в новом коротком чате без расширений, причина находится ниже модельного контекста.

Corrupt state и кэш: когда очистка оправдана

Повреждённое состояние вероятно, если ломается один workspace или чат, а новый профильный сценарий и пустая папка работают. Сначала попробуйте новый чат, Reload Window и штатный Clear Editor History. Затем создайте backup пользовательских данных и только после этого тестируйте переустановку.

Удаление всей папки профиля — крайняя диагностическая мера, а не универсальный совет. Оно способно убрать след проблемы вместе с историей, настройками и доказательствами. Гораздо полезнее сохранить проблемную копию, проверить чистый профиль отдельно и приложить точные логи.

Remote SSH, WSL и контейнеры

В удалённом режиме есть минимум две машины и несколько каналов. Для Remote SSH Cursor отправляет AI-запросы с локального компьютера, а remote host обслуживает файлы, Git, shell и language servers. Поэтому зелёный статус и быстрый локальный интернет не исключают перегрузку удалённого хоста.

Проверьте:

• локальный Network Diagnostics;
• CPU, RAM, swap, диск и свободные inode на remote;
• повтор той же команды в обычном remote terminal;
• Remote SSH/WSL/Dev Containers logs в Output;
• зависшие credential prompts и SSH keep-alive;
• symlink-циклы и каталоги, доступные только из WSL;
• исчезает ли проблема в локальном клоне того же небольшого проекта.

После разрыва SSH полностью перезапустите Cursor: stale-процессы могут пережить переподключение. Не удаляйте remote server-каталоги и контейнерные volumes без backup и точного понимания, какие данные там находятся.

OS и GPU

Electron/Chromium, драйвер и оконный compositor могут давать фризы, пустое окно и высокий gpu-process. Особенно полезен A/B-тест на Linux с Wayland и NVIDIA, но он не должен превращаться в постоянное отключение ускорения без замера.

Сначала обновите снимок процессов и повторите проблему в пустом окне. Затем измените только один параметр: переключите аппаратное ускорение через Help → Open Command Line Arguments и перезапустите. Если эффекта нет, верните исходное значение. На Linux можно отдельно сравнить Wayland и X11-сеанс. На Windows зафиксируйте версию драйвера и наличие Remote Desktop; на macOS — архитектуру Intel/Apple Silicon и версию ОС.

Никогда не лечите UI-фриз отключением sandbox, антивируса, проверки сертификатов или системной защиты. Эти изменения расширяют риск и обычно не локализуют renderer.

Чек-лист Windows, macOS и Linux

Windows

• Сохраните файлы; снимите git status --short и git diff.
• В Task Manager добавьте колонки PID, CPU и Memory и сопоставьте PID с Process Explorer Cursor.
• Проверьте window/renderer, extensionHost, ptyHost и language server отдельно.
• Запустите Cursor без расширений для одного контрольного теста.
• Сравните локальный workspace и WSL/Remote SSH.
• Проверьте Network Diagnostics и статус до очистки кэша.
• Не удаляйте %APPDATA%\Cursor без копии.

macOS

• В Activity Monitor сделайте выборку CPU и Memory Pressure, раскройте Cursor Helper по PID.
• Сопоставьте тяжёлый PID с Process Explorer.
• Сравните Agents Window и Editor layout, особенно после долгой сессии.
• Полностью завершайте приложение через Cmd+Q, если Reload Window не отвечает.
• При Remote SSH проверьте Keychain/credential helper и remote ресурсы.
• Не удаляйте ~/Library/Application Support/Cursor без backup.

Linux

• Запишите дистрибутив, desktop environment, Wayland/X11, видеодрайвер и формат установки.
• Сопоставьте top/htop или ps с PID из Process Explorer.
• Проверьте file watchers, language servers, swap и remote/container процессы.
• Проведите один A/B-тест аппаратного ускорения или оконной сессии.
• Если на 3.19.x есть clean-exit, code 0, применяйте специальную рекомендацию по версии ниже.
• Не удаляйте ~/.config/Cursor и remote server-каталоги без backup.

Обновление и безопасный откат

Для обычного пользователя предпочтителен Stable. Штатное обновление запускается через палитру команд Cursor: Attempt Update, после чего Cursor нужно перезапустить. Early Access содержит более свежие изменения, но может быть менее стабильным.

Откат оправдан, когда выполнены четыре условия:

• проблема началась сразу после известного обновления;
• она воспроизводится на той же папке и исчезает на предыдущей сборке;
• предыдущая версия доступна из официального канала;
• сохранены проект, ветка и настройки.

На 6 сентября есть один особенно ясный случай: Linux 3.19.x, рост памяти и завершение окна с clean-exit, code 0. Сотрудник Cursor рекомендовал временно вернуться на 3.18.25 и дождаться исправления. В официальном changelog на дату проверки не нашлась отдельная release note о выпуске этого исправления, поэтому объявлять проблему закрытой рано. Рекомендация по откату не относится автоматически к Windows, macOS, обычному OOM или зависшему tool call. Не скачивайте старые установщики с зеркал и не фиксируйте уязвимую версию надолго: после выхода исправления нужно вернуться на поддерживаемую сборку.

Как собрать минимальный repro и когда эскалировать

Переходите к баг-репорту, если проблема повторяется после безопасной изоляции или приводит к потере работы, OOM, постоянному росту памяти, падению окна либо блокирует проект.

Хороший минимальный repro содержит:

• полную версию Cursor, commit/build track и ОС;
• local/SSH/WSL/container и Editor/Agents Window;
• маленький публичный или очищенный от секретов проект, если возможно;
• точные шаги и время до зависания;
• ожидаемое и фактическое поведение;
• Process Explorer до, во время и после события;
• Help → Toggle Developer Tools → Console;
• нужный канал Output: MCP, Remote, Git, language server или индекс;
• Request ID зависшего Agent-turn;
• результат теста без расширений и в новом чате;
• одну изменённую переменную и результат A/B.

Официальная инструкция по баг-репорту разрешает делиться Request ID: это служебный ключ для поддержки. Но логи, скриншоты, пути и repro могут содержать имена, код, токены и URL. Перед публикацией удалите секреты. Privacy Mode не требуется отключать во всех случаях: для сетевой ошибки метаданных часто достаточно, а доступ к содержимому Agent-сессии должен быть осознанным решением.

Вывод

В 2026 году проблема не сводится к мифу: официальный форум показывает сотни тем о производительности, а команда Cursor подтверждала отдельные дефекты Agents Window, Grep/Glob и Linux 3.19.x. Но «Cursor тормозит» — не диагноз. Самый быстрый путь к рабочему состоянию проходит через Process Explorer, проверку статуса, короткий тест без расширений и минимальный новый чат.

Сохраните код и настройки до экспериментов. Не стирайте профиль, не выключайте безопасность и не откатывайтесь на случайную сборку. Если один процесс снова растёт в минимальном сценарии, соберите Request ID и логи: такой отчёт полезнее десяти перезапусков и помогает отличить локальную перегрузку от дефекта продукта.