Terminal that Agent runs gets stuck

Hi, thanks for reporting an issue with Cursor.

Before you report this, we’d appreciate if you can search this forum to see if this issue has already been reported.

If you have done so, please check this box.
on

Describe the Bug

Terminal commands in the agent get stuck in a loop, repeating the last output of a previous command. This makes it impossible to execute new commands properly.

Steps to Reproduce

  1. Start a conversation with AI assistant
  2. Ask AI to run a server (e.g., npm run dev)
  3. Try to execute subsequent commands (e.g., curl commands or git operations)
  4. Observe that the terminal keeps showing the output of a previous command instead of executing the new one

Expected Behavior

Each new terminal command should execute independently, clearing the previous command’s output and showing new results. The terminal should not get stuck repeating previous outputs.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Windows 11 (running WSL/Ubuntu)
Version: 0.44.9
VSCode Version: 1.93.1
Commit: 316e524257c2ea23b755332b0a72c50cf23e1b00
Date: 2024-12-26T21:58:59.149Z
Electron: 30.5.1
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.22631

Additional Information

The issue appears to be related to how the terminal handles background processes
The terminal seems to get stuck in a state where it keeps repeating the last output
This particularly affects scenarios where multiple commands need to be executed in sequence

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

I’m having the same issue on my end. Have you found a solution for this?

Several issues going on here; cursor is an OS-ist (racist against OSs) – it truly loves to be mac native

So you have to constantly remind it that on windows - to invoke all things via powershell commands it will constantly attempt to chain commands with &&…

(FIX THIS BEHAVIOR @anon-9002714 – Have the ■■■■ IDE do an OS check EVERY time it launches to know what terminal lexicon to use)

Second, please take my advice and tell it to only wrap all terminal commands in a .ps1 that it then executes and to store all the .ps1s in your projects /@scripts/ folder… and direct it to provide a max 200 char description of the command…

THis allows you to have atomic file history of all terminal invocations the bot does… (invocation is my word of the day, kids)…


It appears that when cursor f-ups the CLI and tries && on powershell, it will loop back to “let me try that another way” many times… and this churns through its context window allotment.

If you see a composer ‘generating…’ for long periods, just type ‘continue’ or ‘?’ and it will give it a nudge to regroup…

Sometimes you’ll need to just create a new session - which can be super problematic if your context training took a significant effort (which ■■■■ but will fade in time)



title: “Cursor AI PowerShell Directives”
subtitle: “Script Management and Execution Guidelines”
author: “Cursor AI”
date: “r format(Sys.time(), '%B %d, %Y')
output:
html_document:
toc: true
theme: united
highlight: tango

PowerShell Script Management Directive

Core Principle

All terminal operations should be encapsulated in PowerShell scripts (.ps1) stored in the scripts/ directory. Direct terminal execution should be avoided in favor of documented, reusable scripts.

Implementation Rules

  1. Script Location

    • All PowerShell scripts must be stored in scripts/
    • Use subdirectories for organization (e.g., scripts/setup/, scripts/maintenance/)
    • Maintain consistent naming: verb-noun.ps1
  2. Documentation Requirements

    • Header block with purpose, parameters, and examples
    • Inline comments for complex operations
    • README.md in script directories
    • Version history in script headers
  3. Script Structure

    <#
    .SYNOPSIS
        Brief description
    .DESCRIPTION
        Detailed description
    .PARAMETER ParamName
        Parameter description
    .EXAMPLE
        Usage example
    .NOTES
        Version: 1.0
        Author: Cursor AI
        Last Updated: Date
    #>
    
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$false)]
        [string]$ParamName
    )
    
  4. Execution Model

    • Scripts should be parameterized
    • Use error handling and logging
    • Return structured output
    • Support -WhatIf operations

Example Implementation

Directory Structure

scripts/
├── setup/
│   ├── install-dependencies.ps1
│   └── configure-environment.ps1
├── maintenance/
│   ├── backup-database.ps1
│   └── cleanup-logs.ps1
└── README.md

Script Template

<#
.SYNOPSIS
    Template for new PowerShell scripts
.DESCRIPTION
    Provides a standardized structure for all new PowerShell scripts
    in the project, ensuring consistency and maintainability.
.PARAMETER Operation
    The operation to perform
.EXAMPLE
    ./template-script.ps1 -Operation "test"
#>

[CmdletBinding()]
param(
    [Parameter(Mandatory=$true)]
    [string]$Operation
)

# Script initialization
$ErrorActionPreference = "Stop"
$ScriptPath = Split-Path -Parent $MyInvocation.MyCommand.Path
$RootPath = Split-Path -Parent $ScriptPath

# Import common functions
. "$ScriptPath\common\functions.ps1"

# Main operation
try {
    Write-Host "Executing $Operation..."
    # Operation logic here
}
catch {
    Write-Error "Operation failed: $_"
    exit 1
}

Execution Guidelines

  1. Instead of Direct Execution:

    # DON'T: Execute directly
    psql -U postgres -c "CREATE DATABASE mydb"
    
    # DO: Create and use a script
    ./scripts/setup/create-database.ps1 -Name "mydb"
    
  2. Error Handling:

    # In scripts/setup/create-database.ps1
    try {
        $result = & psql -U postgres -c "CREATE DATABASE $Name"
        Write-Host "Database created successfully"
    }
    catch {
        Write-Error "Failed to create database: $_"
        exit 1
    }
    

Documentation Example

Script Header

<#
.SYNOPSIS
    Creates a new PostgreSQL database
.DESCRIPTION
    Creates a new PostgreSQL database with the specified name
    and configures basic settings. Supports error handling and
    logging.
.PARAMETER Name
    The name of the database to create
.PARAMETER Owner
    Optional. The owner of the database
.EXAMPLE
    ./create-database.ps1 -Name "myapp_db"
.EXAMPLE
    ./create-database.ps1 -Name "myapp_db" -Owner "appuser"
.NOTES
    Version: 1.0
    Author: Cursor AI
    Last Updated: 2024-01-02
#>

Best Practices

  1. Version Control

    • Include version numbers in script headers
    • Document changes in script history
    • Use semantic versioning
  2. Testing

    • Include test cases in script documentation
    • Support -WhatIf parameter for dry runs
    • Validate parameters
  3. Maintenance

    • Regular script audits
    • Update documentation
    • Remove deprecated scripts
  4. Security

    • No hardcoded credentials
    • Use secure parameter types
    • Implement proper permissions

Integration with Cursor AI

  1. Script Generation

    • Use templates for consistency
    • Auto-generate documentation
    • Validate script structure
  2. Execution Context

    • Scripts should be workspace-aware
    • Support multiple environments
    • Handle Cursor AI specific paths
  3. Logging

    • Write to Cursor AI log directory
    • Use structured logging
    • Support different log levels
1 Like

Hey, it does seem like Cursor does have a preference for Mac even when you aren’t running Cursor on Mac.

I’ll check with the team internally, but I don’t believe we currently tell the AI what platform you are on, hence this issue.
I’ll see if this is something we can add, but for now, you can probably add into your “Rules for AI” section which platform you are on so the AI always knows whenever you are talking to it.