Cursor App Cleanup: What to Fix Before You Ship

TLDR: Cursor doesn't generate apps. It patches them. Each session adds context-free changes that accumulate into something neither you nor the AI fully understands.

I review apps built or iterated with Cursor before they go live. The pattern I see most often is not broken code — it is code that worked in the session it was written, where each session was unaware of the sessions before it.

Cursor is an AI IDE that modifies existing codebases. That makes its failure modes different from tools like Lovable or Bolt.new. The problems are not about missing features or broken scaffolding. They are about accumulation: duplicate logic, security surface you did not know existed, and architecture that drifted across sessions without anyone noticing.

These are the five categories I check on every Cursor app review. For each one, I have listed the questions that catch the most problems and what good looks like when they are addressed.

1. AI patch accumulation

Each Cursor session adds patches to the codebase without full context of what came before. Over time, this creates structural debt that becomes harder to debug, harder to change, and harder to hand off.

  • How many places in the codebase implement authentication, session management, or user identity checks? If the answer is more than one, you have patch accumulation.
  • Is there dead code from previous fix loops — original broken implementations that were left in place when the AI added a new version instead of replacing the old one?
  • Do different parts of the codebase use different patterns for the same concerns — state management, error handling, data fetching, API calls?
  • Could a developer who did not build the app explain where the business logic lives and why it is there?
  • Do any database queries appear in React components or presentation code?

Research shows AI-generated code introduces logic and correctness errors at 1.75 times the rate of human-written code on existing codebases, because the AI lacks context of implicit conventions and undocumented assumptions established across previous sessions. One codebase I reviewed had authentication logic in seven separate locations.

What good looks like: each concern is implemented once, in a predictable location. New sessions add features, not competing implementations. Dead code from fix loops has been removed.

2. Agent and MCP tool access

Cursor's Agent mode can execute terminal commands and call external services through MCP (Model Context Protocol) servers. This is a distinct attack surface from the code itself — one that most developers do not audit.

  • Are production credentials — API keys, database connection strings, cloud provider access tokens — accessible on machines where Cursor runs?
  • Is auto-run mode disabled? When enabled, Cursor can execute terminal commands without explicit human approval.
  • What MCP servers are connected? Each connection is effectively a third-party integration with access to your developer environment.
  • Does your .cursorignore file exclude sensitive directories? Note: .cursorignore blocks file indexing but does not block terminal commands or MCP tool calls — a critical distinction.
  • Have you reviewed your shell history for commands that may have been executed by the agent rather than by you?

Seven CVEs were assigned to Cursor in 2025. CurXecute allowed a malicious social media post to trigger remote code execution through MCP prompt injection — the agent read content from the internet and executed commands with developer privileges. MCPoison demonstrated persistent team-wide compromise through poisoned MCP configurations. Thirty or more CVEs targeting MCP servers and clients were filed between January and February 2026.

What good looks like: production credentials are not available in the local development environment. Auto-run mode is disabled. MCP server connections are audited and limited to what is actively needed.

3. Secret exposure

Developers using AI coding assistants leak secrets at roughly twice the baseline rate, according to GitGuardian research. Cursor creates specific vectors for credential exposure that are easy to miss.

  • Search your codebase and git history for common key prefixes: sk-, pk_, AKIA, SG., gh_, glpat-. Are any hardcoded?
  • Were any API keys or credentials ever pasted directly into a Cursor prompt? Cursor's chat history persists and may include those values.
  • Is your .env file excluded from Cursor's indexing scope via .cursorignore? If not, the AI has been reading your credentials as context.
  • Run git log -- .env and git log -- .env.local. Have these files ever appeared in your commit history?
  • Do your production and development environments use separate, scoped credentials?

Finding a secret in git history means rotating it immediately — not just removing it from the current branch. The history is accessible and the key may have already been harvested by automated scanners, which find exposed credentials within hours of a public push.

What good looks like: no credentials in source code or git history. .env files are gitignored and excluded from Cursor's indexing. Production uses separate credentials that were never present in development or chat history.

4. Dependency accumulation

Cursor adds packages to solve immediate problems without evaluating whether a package is maintained, whether a similar one is already in the project, or whether the dependency introduces known vulnerabilities.

  • Run npm audit (or equivalent). How many vulnerabilities are flagged? How long have they been there?
  • Is a lockfile committed and used consistently in production builds?
  • Are there packages in your dependency list you cannot explain the purpose of?
  • Does more than one package in the project solve the same problem — two HTTP clients, two date libraries, two form validators?
  • When were your major dependencies last reviewed against the current supported versions?

Unreviewed dependencies are liability you inherit without knowing it. If a vulnerability appears in a package you did not know you had, you cannot respond quickly. Multiple sessions adding overlapping packages often means you are shipping more surface area than the app needs.

What good looks like: every dependency has a known purpose and owner. Vulnerabilities are tracked. The lockfile is committed and used in production. Packages that duplicate each other have been consolidated.

5. Architecture consistency

After multiple Cursor sessions, the original architecture boundaries erode. Code ends up in the wrong layer, patterns conflict, and the codebase becomes harder to change safely.

  • Where does business logic live — in utility functions, API routes, server actions, or directly in React components? Is the answer consistent?
  • Do database queries appear in presentation code?
  • Is error handling consistent — do errors surface the same way in every part of the app, or does it depend on which session wrote which file?
  • If you needed to change how authentication works, do you know which files to touch? Can you identify every place the auth state is read or checked?
  • Is configuration centralised, or are values hardcoded in multiple files that need to be kept in sync manually?

An app you cannot change safely is fragile even if it works. If fixing a bug in one place breaks something else because the same logic is duplicated across three sessions, you stop shipping confidently. Architecture consistency determines whether the app is maintainable six months from now, not just today.

What good looks like: concerns are separated by layer. Business logic, data access, and presentation code each live in identifiable locations. A new developer can navigate the project without a guided tour.

How to read the results

Count the questions you cannot answer confidently.

0–2: You are in reasonable shape. Investigate the specific gaps before launch.

3–5: There are real risks worth addressing. Patch accumulation and secret exposure in particular tend to be more urgent than they initially appear.

6+: The categories compound each other — accumulated patches introduce dead code that obscures secret exposure, which coexists with architecture inconsistency that makes fixing any of it harder. Consider a structured review before shipping.

This checklist tells you where to look. It does not tell you what is in your codebase. That requires a code review.

The free production risk audit

If you have found gaps, or you want an independent read before the app handles real users and real money, the free AnchorStack production risk audit is the next step.

I review your codebase across each of these categories and return a prioritised report of what is most likely to break first and what to address before it does. It is not a sales process. You get the findings whether or not you want to work together further.

Get a free production risk audit →