Agent with Confusion Hallucinations and Mutiny (100% broken)

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Bug Report: Agent context collapse, scope drift, and failure to honor explicit stop constraints

Product: Cursor AI coding agent
Severity: High — user lost trust, work had to be abandoned/reverted, significant time wasted
Category: Agent reliability / instruction following / context management


Summary

During a focused implementation task, the agent repeatedly diverged from the user’s stated goal, introduced unrelated changes, contradicted its own prior “fixes,” and continued modifying code after explicit instructions to stop. The agent appeared to merge stale conversation summaries, assumed prior work was absent when it already existed on the main branch, and treated each user correction as a new design problem rather than a return to the original narrow scope.


Expected behavior

  1. Restate the user’s constraints before acting.
  2. Make minimal changes that satisfy the stated goal only.
  3. Use the current repository state as source of truth—not chat summaries or prior sessions.
  4. Stop all code changes when the user says stop.
  5. When corrected, narrow scope—not expand into adjacent systems.
  6. Ask once if a requirement is ambiguous; do not invent architecture.

Actual behavior

The agent exhibited a cascade of failure modes over a single session:

1. Context pollution from conversation summaries

The agent relied on a conversation summary that mixed:

  • Work already merged or present on the default branch
  • Work planned but never implemented in the user’s current tree
  • Work from a different feature branch

This caused the agent to re-implement or re-discuss infrastructure the user already had, and to give incorrect explanations about what would happen on startup, what was “missing,” and what files needed to change.

Impact: User was told their system lacked behavior that already existed; agent proposed redundant work.


2. Scope creep on every correction

When the user pushed back (e.g., “too much abstraction,” “wrong pattern,” “not related to the task”), the agent did not return to the original minimal fix. Instead it:

  • Swung to the opposite extreme (full duplication, then helpers again)
  • Added new subsystems (separate sync paths, new runnables, new layers)
  • Touched files outside the user’s stated scope

Impact: Each “fix” increased diff size and confusion.


3. Conflating “related in the system” with “part of this task”

The agent correctly understood that feature A and feature B are connected in a larger architecture, but incorrectly treated implementing B as required to complete task A.

The user had already landed related work elsewhere; the agent still introduced parallel implementations, registration hooks, and lifecycle wiring that duplicated existing production behavior.

Impact: User repeatedly asked “how is this related?”—valid question the agent failed to answer by staying in scope.


4. Inventing requirements and “helpful” architecture

Without being asked, the agent:

  • Introduced constants, helpers, and abstractions the user rejected
  • Moved responsibilities across package boundaries, then moved them back
  • Proposed alternative workflows (e.g., dedicated sweeps) after the user explicitly required using an existing reconcile/sync path

Impact: User perception: “you are doing different tasks.”


5. Failure to stop

After clear directives (“stop touching the code,” “forget it”), the agent had already made or was about to make additional edits. Continuing after STOP is a critical trust violation in an autonomous coding agent.


6. Oscillating implementation style under pressure

The agent cycled through incompatible styles in response to frustration:

User signal Agent response (wrong)
Don’t over-abstract More abstraction in a different form
Don’t duplicate Massive duplication
Don’t use loops Loops removed, duplication added
Use a helper for repeated API calls Wrong helper (sync check wrapper) instead of the repeated low-level call

Impact: Code churn without converging on a stable, user-approved solution.


7. Post-hoc “redo checklists” that were still wrong

After the user decided to revert and start over, the agent produced a “clean checklist” that still mis-scoped the task (e.g., treating parts of the problem as separate when the user considered them one flow, or omitting things the user considered in-scope).

Impact: User concluded the agent remained confused even while claiming to understand.


Root cause hypothesis (for engineering)

  1. Summary-over-git: Prior chat summaries overweighted vs repository state and open files.
  2. No hard scope lock: No mechanism to freeze file allowlist after user defines task.
  3. Correction misfire: Negative feedback triggers “try another approach” instead of “re-read original intent.”
  4. No stop latch: “STOP” not treated as a hard halt on all write/edit tools.
  5. Long-horizon goal drift: Original three-bullet task degraded into multi-file refactor across unrelated packages.

User impact

  • Time lost to review, revert, and restash
  • Anger and loss of confidence
  • Decision to abandon the session and redo work manually
  • Intent to file this report externally

Suggested product fixes

  1. Scope contract: At task start, agent must output: goal, files in scope, files forbidden, done criteria—user can confirm in one click.
  2. Summary disclaimer: When resuming from summary, agent must verify claims against the repo before stating what exists.
  3. Stop latch: User “STOP” / “don’t touch code” disables all write/edit tools until explicitly released.
  4. Correction mode: On strong negative feedback, force re-read of first user message + constraints; block new files unless user approves.
  5. Branch awareness: Surface “this may already exist on main / another branch” before re-implementing.
  6. Diff budget: Warn or require approval when change set exceeds N files or M lines off stated scope.

Reproduction (generic)

  1. Start a session with a narrow task (2–3 concrete requirements).
  2. Resume or continue with a long conversation summary that mentions related features.
  3. Correct the agent multiple times on style/scope.
  4. Observe: agent expands scope, duplicates work that exists on main, ignores STOP, and produces incorrect “clean start” guidance.

I was working with the agent for couple of hours to introduce a change to my codebase.. In some point the agent got so confused and went rogue and started doing changes that were not related to the problem. Unfortunately I had to git stash and start over because the agent was completely broken.

This BUG report here, is the reason why the agent is buggy and we can’t trust it to generate code.

Steps to Reproduce

Follow the description

Operating System

Linux

Version Information

Version: 3.6.21
VS Code Extension API: 1.105.1
Commit: e7a7e93f4d75f8272503ecf33cedbaae10114a10
Date: 2026-05-28T21:45:36.072Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Linux x64 6.12.11-100.fc40.x86_64

For AI issues: which model did you use?

it was auto

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey @droslean Thanks for the detailed writeup. What you’re hitting shows up once a conversation gets long enough that older turns get compressed into a running summary - constraints fade and the agent starts working off the summary instead of your actual repo. Not something you misconfigured, and it’s an issue we’re tracking.

For right now:

  1. Update Cursor - you’re on a May 28 build (3.6.21); a lot of context-handling work has shipped since.
  2. Use Plan Mode (Shift+Tab) as your scope gate - it states a plan for approval before editing. Plan Mode
  3. Anchor corrections - tell it to update the existing file/plan, not create a new one, and name the file. That’s the direct fix for “every correction spawns a new design.”
  4. Once it’s drifted, start a fresh chat - pasting in the current state and constraints beats correcting in place. (Restore Checkpoint rolls your files back if you want to undo changes. Checkpoints)
  5. Stop button vs. typed “stop” - the Stop button hard-aborts in-flight work; typing “stop” is only read next turn. Cmd+Enter interrupts and redirects in one move.
  6. Pin a model instead of Auto for long, precision work - Auto can switch models mid-conversation.

The habit that matters most: one task, one chat.

Your six suggestions are the most useful part here - we’ll be tracking this thread, which is what helps the product team weigh it. On rules, hooks are still the right tool for a hard block (won’t rehash your earlier thread).

Thanks @mohitjain ! I will keep in mind all of your advice. I wasn’t aware of the checkpoints, that might be helpful.