Cursor Agent gets stuck in “Connection failed” loop after PowerShell output-truncation pipeline; local protobuf serialization fails (invalid int 32: 4294967295)

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Bug report: Cursor Agent gets stuck in “Connection failed” loop after PowerShell output-truncation pipeline; local protobuf serialization fails (invalid int 32: 4294967295)

Summary

On Windows, Cursor Agent sometimes runs a verification command that truncates output via a PowerShell pipeline (e.g. ... | Select-Object -First 30). This can cause PowerShell to abort the upstream process/pipe and set $LASTEXITCODE = -1. Cursor then attempts to serialize the tool result into an aiserver protobuf request and fails locally with:

  • [transport] Message serialization error in stream Error: invalid int 32: 4294967295
  • ERR [internal] Serialization error in aiserver.v1.StreamUnifiedChatRequestWithTools

After that, the UI shows “Connection failed. If the problem persists, please check your internet connection or VPN” and “Try again” loops forever. DevTools shows no outgoing network request because serialization fails before the request can be sent.

Environment

  • Cursor: 2.2.23 (stable) (from DevTools log)
  • OS: Windows (win32 x64) (inferred from log paths / extension win32-x64)
  • Shell: PowerShell (Windows PowerShell / pwsh; exact version not required to repro)
  • Project: Node/npm + SvelteKit (svelte-kit sync && svelte-check ...)

Steps to reproduce

  1. In Cursor Agent (or any tool execution path that records command exit codes), run a verification command that truncates output via early-terminating pipeline, e.g.:

    cd C:\git\project\frontend
    npm run check 2>&1 | Select-Object -First 30
    
  2. Immediately check exit code (manual reproduction outside agent is sufficient):

    $LASTEXITCODE
    
  3. Observe $LASTEXITCODE is -1 (reproduced reliably in my environment with the truncating pipeline).

  4. After the agent runs the command, the agent chat UI becomes stuck showing “Connection failed…”, and clicking “Try again” does not create any network activity.

Actual result

  • Cursor fails locally while preparing the chat/tool request:

    • [transport] Message serialization error in stream Error: invalid int 32: 4294967295
    • ERR [internal] Serialization error in aiserver.v1.StreamUnifiedChatRequestWithTools
    • Caused by: Error: invalid int 32: 4294967295
  • UI shows “Connection failed … check your internet connection or VPN”.

  • Retrying does not help; no network requests are triggered (failure happens pre-send).

Expected result

  • Cursor should not treat this as a network failure.

  • Tool results should be serializable even if the executed command returns an unusual/negative exit code.

  • “Try again” should either:

    • reattempt the request successfully, or
    • surface the real local error (serialization / exit code handling), not a generic network/VPN message.

Evidence (DevTools excerpt)

From DevTools console (pasted log):

  • Message serialization error in stream Error: invalid int 32: 4294967295
  • Serialization error in aiserver.v1.StreamUnifiedChatRequestWithTools
  • Caused by: Error: invalid int 32: 4294967295

Also observed in the same sequence:

  • [composer] Error in getPopulatedContext: EntryNotFound ... .cursor\projects\...\terminals\3.txt
    (May be secondary, but appears around the failure.)

Key finding / suspected root cause

  • PowerShell output-truncation pipelines like:

    <external command> | Select-Object -First N
    

    often terminate the upstream pipeline once N lines have been read. For external/native commands, this can result in:

    • $LASTEXITCODE = -1
  • Cursor appears to serialize a tool result field that expects a signed int32 exit code, but the value is ending up as 0xFFFFFFFF interpreted as an unsigned 32-bit integer:

    • -10xFFFFFFFF4294967295

    That value is out of range for int32 and protobuf serialization fails (invalid int 32: 4294967295). Because serialization fails before the request is sent, the UI incorrectly reports a “Connection failed” network issue and retries forever.

Impact

  • Agent workflows frequently end with a “verify” command; if the agent chooses an output-truncating pipeline, the entire run can become unrecoverable without reloading/restarting Cursor.
  • Misleading “internet/VPN” error message obscures the real failure mode.
  • Affects long tasks disproportionately (because verification steps run at the end).

Workarounds (user-side)

Avoid early-terminating pipelines for external commands. Instead:

  • Run command to completion, redirect output to a file, then print first N lines:

    npm run check *> .cursor_check.log
    $ec = $LASTEXITCODE
    Get-Content .cursor_check.log -TotalCount 30
    if ($ec -lt 0) { $ec = 1 }
    exit $ec
    

I implemented this via a wrapper script + npm run check:cursor and instructed the agent (via project rules) not to use | Select-Object -First ….

Suggested fixes (developer-side)

  1. Exit code type/validation

    • Ensure tool exit codes are stored and serialized as signed integers consistently.

    • Avoid unsigned casting/normalization that turns -1 into 4294967295.

    • Validate/clamp exit code before protobuf serialization:

      • If exit code < 0, map to a safe failure code (e.g. 1) or preserve sign via a signed int32/int64 field.
  2. Error handling / UX

    • If request serialization fails locally, show a “local serialization error” (with details) rather than “check your internet/VPN”.
    • Retrying should not repeat the same doomed serialization path indefinitely; it should either repair state or prompt user to reload.
  3. Agent command generation

    • Avoid generating PowerShell pipelines that truncate output from external commands (Select-Object -First, head, etc.) since they can force upstream termination.
    • Prefer run-to-completion + log + post-truncation when output needs to be short.

Minimal repro (copy/paste)

cd C:\git\project\frontend
npm run check 2>&1 | Select-Object -First 30
$LASTEXITCODE  # observed: -1

If needed, I can provide the full DevTools log and a wrapper script that avoids the issue.

Steps to Reproduce

Minimal repro (copy/paste)

cd C:\git\project\frontend
npm run check 2>&1 | Select-Object -First 30
$LASTEXITCODE  # observed: -1

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.2.20 (user setup)
VSCode Version: 1.105.1
Commit: b3573281c4775bfc6bba466bf6563d3d498d1070
Date: 2025-12-12T06:29:26.017Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.22631

For AI issues: which model did you use?

Opus 4.5

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Thanks for the report, I’ve raised it with the team.