Agent-started long-running servers (Vite) disappear from the Terminal UI; aborting the agent shell orphans the process (PPID 1)

Support Bug Reports
1

Title: Agent-started long-running servers (Vite) disappear from the Terminal UI; aborting the agent shell orphans the process (PPID 1)

Where does the bug appear: Cursor IDE (Agent Shell + Terminal panel)

Cursor version: 3.20.17
OS: macOS 15.2 (24C101)

Describe the Bug

When Agent starts a long-running local server (npx vite --host 127.0.0.1 --port 5173) in the background:

  1. Opening View → Terminal only creates a blank new terminal. The Agent’s Vite session is not listed.
  2. Cursor Browser can still load http://127.0.0.1:5173 after the chat shows the shell as aborted.
  3. The Node/Vite process is still alive, reparented to PID 1, with no TTY / no Terminal tab. The user cannot stop it from the Terminal UI. They must ask Agent to kill it, or find the PID with lsof themselves.

This is hostile for daily dev: Agent-owned servers are not first-class, not visible, and not cleaned up.

Steps to Reproduce

  1. In Agent chat, ask Agent to run a Vite/dev server to verify the app in Cursor Browser.
  2. Agent backgrounds npx vite --host 127.0.0.1 --port 5173.
  3. Chat later reports the shell aborted / terminated_by_user.
  4. Open Terminal (`⌃``). Observe only a new empty terminal; no Vite session in the tab list.
  5. Refresh Cursor Browser against 127.0.0.1:5173 — the app still loads.
  6. lsof -nP -iTCP:5173 -sTCP:LISTEN shows node still listening. ps shows PPID 1.

Expected Behavior

  • Agent-started processes appear in the Terminal list (same as user terminals).
  • Aborting/closing the Agent shell kills the process tree (npm + vite), or prompts to keep/stop it.
  • A Ports / Agent processes view: PID, cwd, port, Stop button. No need for lsof or asking Agent to kill.

Actual Behavior

  • Terminal UI does not surface the session.
  • After abort, Vite is orphaned (PPID 1) and keeps the port.
  • Observed PIDs (then killed): 96897 npm exec vite ..., 96928 node .../vite --host 127.0.0.1 --port 5173.

Does this stop you from using Cursor: No, but it breaks trust for Agent-run dev servers.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

4

Where does the bug appear: Terminal & commands

Operating System: MacOS

Version Information:
IDE:
Version: 3.20.17
VSCode Version: 1.128.0
Commit: 0c32194e3fb5ffaced9fb36430b860ec301e1fc0
Date: 2026-09-12T03:16:10.634Z
OS: Darwin arm64 24.2.0

For AI issues: which model did you use?
Cursor Grok 4.6 (Agent)

Does this stop you from using Cursor?
No - Cursor works, but with this issue

7

Hey, thanks for the detailed report. There are two separate things here, so I’ll cover them one by one.

Where the Vite terminal lives. In the Agents Window, terminals started by the agent are intentionally not shown in the normal terminal tab list, so View → Terminal opens a new terminal that’s yours. The agent shells are under the N Terminals pill right above the agent input. Click it to see the list of running agent shells. Each one has a Stop button, and clicking a row opens it as a read-only tab. That’s currently the closest thing to the agent processes view you described. It doesn’t show PID or port yet, but I passed your suggestion for that view to the team.

Vite stays alive after Stop. That shouldn’t happen, and I sent it to the team. It looks like Stop does end the shell wrapper, but with some command forms the actual server it started doesn’t get killed with it. To figure out which form you hit, can you help with two things:

  1. In the chat where this happened, expand the tool call that started Vite and paste the exact command line the agent ran, including parts like &, nohup, or > file 2>&1.

  2. Try this in a new chat and tell me what you see:

    1. Ask the agent to run cd <your project> && npx vite --host 127.0.0.1 --port 5173 > /tmp/vite.log 2>&1 in the background and leave it running.
    2. Once the chat shows the command is running in the background, click the 1 Terminal pill above the input.
    3. Hit Stop on the Vite row.
    4. Wait 10 seconds, then in your own terminal run lsof -nP -iTCP:5173 -sTCP:LISTEN.
    5. Repeat steps 1 to 4, but this time ask for cd <your project> && npx vite --host 127.0.0.1 --port 5173 without redirecting output to a file.

Does the listener survive in one case, both, or neither?

Workaround for now: ask the agent to start servers without redirecting output to a file, or explicitly ask it to kill the server when you’re done. That avoids the orphan process. Let me know what the test shows.