Agent Read tool silently zeroes out files in external repositories

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When the agent reads files located outside the workspace root directory (in sibling/external repos), those files are silently truncated to 0 bytes. No error is shown. The agent never intentionally writes to these files — only reads them for context.

Steps to Reproduce

Open workspace rooted at directory A (e.g., an Angular project)
Have the agent use the Read tool on files in directory B (a sibling repo — e.g., a Rails API repo)
After the session completes, check the files in directory B
Files that were read are now 0 bytes

Operating System

MacOS

Version Information

Version: 3.5.33
VSCode Version: 1.105.1
Commit: aac81804b986d739acab348ed96b8bea6e83cc50
Date: 2026-05-22T06:47:48.039Z
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: Darwin arm64 25.4.0

For AI issues: which model did you use?

opus 4.6 and opus 4.7

Additional Information

Summary

When the Cursor agent uses the Read tool to access files in repositories outside the active workspace root, those files are silently truncated to 0 bytes. The files are not intentionally written to — only read for context — yet their contents are destroyed.

Environment

Cursor version: Recent (bug appeared ~week of May 19, 2026)

OS: macOS (darwin 25.4.0)

Workspace root: /Users/gary/GKB/RubyApps/TC_Rest/Hammer (Angular project)

Affected external repos:

/Users/gary/GKB/RubyApps/TC_Rest/thor (Ruby on Rails)

/Users/gary/GKB/RubyApps/angular-libraries (TypeScript/Angular)

Behavior

Agent is working in the Hammer workspace

Agent uses the Read tool (or Grep/Glob followed by Read) to inspect files in sibling repositories (Thor, angular-libraries) for context

After the session, the read files are 0 bytes on disk — contents completely gone

No error or warning is shown to the user or agent during the session

The corruption is only discovered later when the application fails to compile or run

Affected Files (Two Incidents)

Incident 1 — angular-libraries repo:

projects/thor-api/src/lib/thor-api.module.ts (zeroed from ~2KB to 0)

Incident 2 — Thor repo (5 files):

app/jobs/ub_post_charges.rb (1,985 bytes to 0)

app/modules/chargeTypes/chargeTypes.rb (10,094 bytes to 0)

app/modules/ubRateSchedules/ubRateSchedules.rb (5,481 bytes to 0)

app/services/ub_billing/charge_calculator.rb (22,604 bytes to 0)

app/services/ub_billing/reading_adjuster.rb (16,235 bytes to 0)

Key Observations

File type is irrelevant — affects both .rb and .ts files

The files were only read, never intentionally written or edited

The agent’s Write/StrReplace tools were not called on these files

The workspace sandbox is configured with “write access limited to the workspace directory” — yet files outside the workspace are being truncated

This behavior is new — the same multi-repo workflow worked without corruption prior to ~May 19, 2026

Recovery is possible via git restore since contents are committed

Does this stop you from using Cursor

No - Cursor works, but with this issue
revising - silent changes that impact my applications functionality are significant hits to the confidence we have in the code. This definitely impacts how we use cursor and if we can afford to use cursor with the additional testing requirement this adds to our job.

Thanks for the detailed report - the file sizes, timestamps, and confirmation that no Write/StrReplace tool calls were made on those files is genuinely helpful.

This is a confirmed bug class. We’re aware of an issue where our internal file cache can diverge from what’s on disk, resulting in 0-byte files.

Your recovery approach (git restore) is correct. For now, there are a couple of things that can help reduce the risk:

  • Avoid referencing external repos via the Read tool when possible. Instead, consider adding the sibling repos to a multi-root workspace so they’re treated as part of the workspace and get proper file lifecycle handling.

  • Check external files after agent sessions — a quick git status in the sibling repos will surface any unexpected changes early.

We’ve filed this with our engineering team for investigation.