Cursor rule workflow duplicates full report blocks despite delete-and-regenerate instructions

[GWTech (Nate)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Bug Report Draft: Duplicate Full-File Report Blocks During Rule-Driven Writes

Summary

When running a Cursor rule workflow (<Review>), I created, that should create exactly two files (one report each), the resulting files consitantly contained multiple full report blocks in the same file. This happened even when the workflow explicitly deleted existing files first and instructed single-pass generation.

The issue only stabilized after forcing hard truncate-overwrite writes (Set-Content) and forbidding patch-style final writes.

Environment

• OS: Windows 10.0.26200
• Shell: PowerShell
• Workspace: c:\Users\<USER>>\AppData\Roaming\VSC\<PROJECT>
• Workflow trigger: <Review>
• Target files:
  • <Report1>.md
  • <Report2>.md

Expected Behavior

• Exactly one complete report written to each target file per invocation.
• Marker counts should always be:
  • # Title => 1
  • ## First Section => 1

Actual Behavior

• Files repeatedly ended up with multiple full report blocks (apparent append/stacking behavior).
• This occurred despite delete-then-regenerate instructions and duplicate guards in the rule.
• Behavior was eliminated only after switching to hard overwrite/truncate shell writes.

Impact

• Corrupted report artifacts (duplicated full content)
• Repeated execution loops and extra token usage
• Reduced trust in deterministic rule execution for file outputs
• Token usage bloat / Unecessary backend tasking

Repro Pattern (Observed)

1. Rule deletes existing report files.
2. Agent writes one fresh report per file via patch-style file creation/update path.
3. Existing content appears to be restored/reintroduced (likely editor/buffer interaction timing).
4. Patch-style write lands as another full block in the same file.
5. Marker checks fail with counts >1.

Workaround That Consistently Worked

• Replace final file creation path with PowerShell truncate-overwrite:
  • Set-Content -Path "Report1.md" -Value $<type> -Encoding utf8
  • Set-Content -Path "Report2.md" -Value $<type> -Encoding utf8
• Validate with shell marker count:
  • Select-String ... .Count
• Result observed: marker counts returned exactly 1 for both files.

Evidence Snapshot (Most Recent Successful Validation)

• report1_marker_count=1
• report2_marker_count=1

Previous Rule Syntax (Before Hard-Overwrite Lock-In)

This is the relevant previous syntax that still allowed patch-style final writes:

## Required execution order (must follow)

1. **Delete existing report files first** (if present):
   - `Report1.md`
   - `Report2.md`
2. **Review the current repository tree** per the instructions in this rule.
3. **Write exactly one fresh version of each report file** to the repo root.
4. **Run a single-marker sanity check** on both files.
5. If marker checks fail, **stop and escalate** (do not auto-regenerate in the same invocation).

### Single-pass write contract (strict)

- In one `<Review>` invocation, create at most:
  - one complete `Report1.md`
  - one complete `Report2.md`
- Do **not** draft or write alternate full versions in the same run.
- Do **not** “try again” by writing another full report block in the same file within the same run.
- If a duplicate block is detected after write, treat it as an external overwrite/restore risk and escalate to the user.

## Execution notes for the agent

- **Overwrite safety:** Start by deleting prior report files, then create fresh files once each (no append/duplicate blocks).
- **Duplicate-block guard (required):** After writing each report, verify it contains exactly one top-level start marker. For the <type>, `# <Report1>` must appear once. For <type>, `## 1. First Section` must appear once.
- **If marker count is not exactly 1:** **STOP** and report a blocker. Do **not** write another full report in the same invocation. Ask the user to approve a hard-reset pass (close/open buffer as needed, then delete + regenerate once).

New Rule Syntax (After Hard-Overwrite Lock-In)

This is the updated syntax that reliably prevented duplicate blocks:

### Required write mechanism (non-negotiable)

- For these two files, use **hard overwrite/truncate writes** (PowerShell `Set-Content` or equivalent truncate-and-replace command).
- Do **not** use patch-style add/update writes for final report creation (`ApplyPatch`, append flows, or multi-pass patch retries) because they can reintroduce duplicate blocks when editor buffers restore content.
- Write each file **once** in the invocation, then immediately run marker checks.
- Marker check should use shell-native counting (PowerShell `Select-String ... .Count` or equivalent) and confirm:
  - <type> marker count = `1` for `^# <Report1>$`
  - <type> marker count = `1` for `^## 1\. <First Section>$`
- If either count is not `1`, **STOP** and ask user for a manual hard-reset pass (no automatic regeneration in the same invocation).

## Execution notes for the agent

- **Write method:** Final report writes must be truncate-overwrite shell writes (`Set-Content` / equivalent), not patch-append workflows.

Why This Appears To Be A Tooling/UI Edge Case

• The workflow logic already prohibited duplicate generation and retry loops.
• Duplicate full-file blocks still appeared until write mechanism changed.
• Behavior is consistent with an editor/buffer/file-state interaction where patch-style writes can land on unexpectedly restored file content.
• Hard truncate-overwrite bypassed the issue consistently.

Requested Investigation

1. Investigate file-state synchronization between agent write operations and editor buffer/autosave restore paths.
2. Verify whether patch-style write operations can append/merge unexpectedly when file state changes between delete and write.
3. Provide guidance or safe-write primitive for deterministic “single fresh file” generation in rule workflows.
4. Consider a built-in guard for “final artifact files” that enforces truncate-overwrite semantics.

Minimal Repro Request

Please run a small rule that:

1. Deletes A.md and B.md
2. Writes one complete document to each using patch-style writes
3. Runs a marker count check
4. Repeats invocation while files are open in editor tabs with autosave enabled

Then compare with identical flow using truncate-overwrite shell writes.

Steps to Reproduce

1. Create/open two markdown files: .md and .md.
2. Use a Cursor rule/workflow that does:

• delete both files
• write one full report to each file using patch-style writes (ApplyPatch add/update)
• verify marker count is exactly 1 per file

3. Keep both files open in editor tabs (autosave enabled).
4. Run the workflow repeatedly .
5. Observe that one or both files can contain multiple complete report blocks (marker count > 1), despite single-pass instructions.
6. Switch the write step to hard truncate-overwrite (Set-Content) and rerun; duplication no longer occurs (marker count returns to 1).

Expected Behavior

• Exactly one complete report written to each target file per invocation.
• Marker counts should always be:
  • # Title => 1
  • ## First Section => 1

Operating System

Windows 10/11

Version Information

Version: 3.2.10 (user setup)
VSCode Version: 1.105.1
Commit: 87903b25fe9074e35b9ba372ed5bf14de5835960
Date: 2026-04-24T00:45:10.396Z
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
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Agent: Premium (Codex 5.3)

I normally leave it in auto, so this was chosen for me based on the tasking.

For AI issues: add Request ID with privacy disabled

6512598d-bdae-4c0d-8181-93f2c915c1ff

Additional Information

I had AI create the initial report and I redacted the names. I can send the unredacted report if need be but I’m sure you can just read the conversation with the ID provided.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report. The repro steps and workaround analysis really help.

This is a known class of bugs. With patch style writes, the agent read path can sometimes read content from an open editor buffer in memory TextModel instead of from disk. If the file was deleted but the tab is still open, especially with autosave, the buffer can restore old content, and the patch gets applied on top of it. That’s why you see duplicated blocks. Your Set-Content workaround works because it skips the whole read patch write pipeline and writes directly with truncate semantics.

A very similar thread with the same symptom: Delete & re-creation of file cause duplicated data Delete & re-creation of file cause duplicated data

We’re tracking this on our side, but there’s no exact ETA for a fix yet. For now, your workaround truncate overwrite via Set-Content plus the marker count check is a solid solution for deterministic generation of final artifacts. For rules that write final files, it makes sense to lock in that kind of write contract like you did.