IDE crash leaves terminal process running → Telegram bot conflict, forces token reset

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When Cursor crashes with “The window terminated unexpectedly”, the integrated terminal can keep the process that was running (e.g. a Telegram bot). After reopening Cursor and starting the bot again, Telegram returns “Conflict: terminated by other getUpdates request”, so only one instance can run per token. The only workaround is changing the bot token, which blocks normal development and testing.

Steps to Reproduce

Run a long‑running process in Cursor’s integrated terminal (e.g. python main.py for a Telegram bot).
Cursor crashes (e.g. “The window terminated unexpectedly”, reason: ‘crashed’, code: ‘5’).
Reopen Cursor.
Start the same bot again in a terminal (same or new).
Result: TelegramConflictError: Conflict: terminated by other getUpdates request — Telegram still treats the previous session as active or another instance is still running.

Expected Behavior

On crash, terminal processes are terminated so they don’t keep holding resources (e.g. Telegram long‑polling).
Or: after crash, Cursor does not auto‑restore/restart terminal tasks that would cause such conflicts.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 2.5.17
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.3.0

For AI issues: which model did you use?

Auto

Additional Information

Process from the terminal survives (or is restarted), so two getUpdates flows run for the same bot token.
User has to change the bot token to continue testing, which disrupts development.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey, thanks for the detailed report.

Two separate things are happening here:

  1. Orphan processes after a crash - when Cursor (or any app) crashes, the OS doesn’t automatically kill child processes. They get “adopted” by the system’s init process. This is normal macOS and Unix behavior, not Cursor-specific. Good news: you don’t need to change your bot token. Just kill the old process before starting a new one:
# Find the lingering process
ps aux | grep "python main.py"

# Kill it by PID
kill <PID>

Or use Activity Monitor to find and kill the Python process. After that, your bot should start cleanly with the same token.

  1. The crash itself (reason: “crashed”, code: “5”) - this is a separate issue. A few questions to narrow it down:
  • What were you doing when it crashed? (running an agent, editing, idle?)
  • How often does it happen?
  • Do you have a lot of extensions installed? You can test with cursor --disable-extensions to see if that helps.

In the meantime, the kill command is a reliable workaround.

“What were you doing when it crashed? (running an agent, editing, idle?)” - I provided the agent with a request for correction, his thoughts lasted about 10 minutes, after which Cursor completed its work with an error

”How often does it happen?” - within two weeks of daily use, this is the fifth time

”Do you have a lot of extensions installed? You can test with cursor --disable-extensions to see if that helps.” - I don’t use extensions.

Question regarding killing a process, how to do it if the launch occurs in the terminal of the IDE itself, and after restarting it opens an empty terminal (new) and even using this function it does not terminate previous processes.

The kill command works from a new terminal too. It doesn’t matter that it’s a fresh terminal session. The orphan process is still running on your system, so any terminal can find it and kill it:

ps aux | grep "python main.py"

This will show the old process and its PID. Then run:

kill <PID>

If it still won’t stop, try kill -9 <PID>. You can also use Activity Monitor. Look for the Python process there and force quit it.

About the crashes: what you’re describing, the agent thinking for about 10 minutes and then crashing, matches what other users are seeing. Long agent sessions can cause the renderer process to run out of memory, which can trigger error code 5.

A few things to try:

  • You’re on 2.5.17. Please update to the latest version. There have been stability improvements since then.
  • Start new chats more often instead of keeping one long session. This is the most effective workaround right now.
  • Before the next crash, open Cmd+Shift+P and then Developer: Open Process Explorer, and check if memory usage is going up. A screenshot would help us narrow it down.

If it still crashes after updating, grab main.log from Help > Open Logs Folder right after a crash and share it here.