Sonnet having a real tough time figuring out how to put files in the right location

[jrista (Jon)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have noticed in the last couple of days, that Sonnet seems to be having a VERY HARD time adding code or creating new code to files in the right location. If it updates an existing file, it will apparently read the original content from the correct file, however when it writes out the updated content, it is often in a directory in the root of my workspace, rather than in teh right location. So I may have project-x/ within which is src/api/some-area/ and within that I might have some *.controller.ts and *.serivce.ts files. Sometimes Sonnet will update the right code. Often it will save the code out to src/api/some-area/some.controller.ts instead. This rooted src/ directory did not exist before, should not exist, and yet now it has a full copy of my controller, with the updates that were supposed to go to project-x/src/api/some-area/some.controller.ts.

When you try to correct this, it just won’t get corrected. You can try many different things, and it won’t get resolved, and even if you instruct the agent to MOVE the files to the right location (for new files) or take any new updates from the files in the rooted src/ directory, and reapply them to the actual file, it won’t actually work.

I have had to ultimately resort to forcing the model to not change code, but explicitly explain why it is doing what it is doing. Its response will usually be its not using the right relative paths. I am hjonestly not sure what relative paths it is trying to use, but, I don’t see how this could happen either. I would assume that the agent within cursor, should be responsible for referencing all files correctly (which seems to be the case initially, since clearly, the agent and llm are able to READ teh correct file!! They just can’t seem to WRITE the correct file!)

Seems like an explicit bug, in the way the agent interacts with the model in this case. Whatever the cause, it sometimes becomes a real problem, and it is very difficult to get out of. Even with a full reversion back to the original prompt, there is no guarantee that it won’t just encounter the same problem again.

In EITHER case, the darn issue has cost me a crap-ton of tokens today, because I’ve had to constantly rework large tasks because of rogue file mis-writes to the rooted src/ directory. This kind of thing can’t be happening, when your customers are paying for every mistake your agent makes…

Steps to Reproduce

I don’t know how to forcibly reproduce the issue. -_o.o_/-

Expected Behavior

Files are ALWAYS written to the correct location!

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.4.5 (Universal)
VSCode Version: 1.99.3
Commit: af58d92614edb1f72bdd756615d131bf8dfa5290
Date: 2025-08-13T02:08:56.371Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[sanjeed5 (Sanjeed)]

Hi there, please try these:

• Update to the latest Cursor version

• Use explicit path context - When working with the agent, reference specific folders using @Folders and be very explicit about file locations in your prompts (e.g., “update the file in project-x/src/api/some-area/controller.ts, not the root src directory”).

• Verify your workspace root - Ensure you opened Cursor from the correct project root directory. The agent uses your current working directory for path resolution, so opening from the wrong location can cause these path issues.

You can also try adding Rules about your project structure.

Please let us know if the issue still persists after updating and trying these approaches.

[jrista (Jon)]

I am on 1.5.11 right now. This seems like it may be only a sonnet issue, as I’ve been using Grok Code a lot, and have never had the issue. Something about Sonnet, despite explicitly referencing my project with an @ reference in the prompt, as well as explicitly referencing my code directories and files the same way, Sonnet often seems to assume its working directory is something other than it actually is.

When it does that, it seems to put code in the root. So it assumes its working in ProjectX/ and as such, it uses relative paths when it uses the cursor edit tool. If the working directory is not what Sonnet thinks, and it creates or edits a file with the relative path src/some/other/directory/file.ts, then that relative path is relative to whatever the ACTUAL working directory is. I don’t think this is the same as the terminal working directory for the agent, either, as I have rules that the agent usually follows that help it make sure its in teh right directory before issuing any terminal commands. I think the “working directory” for cursor’s mcp/tools is different? I think Sonnet either loses sight of what the working directory is, or it changes back to the root of my workspace and the model doesn’t know that it has.

Oh, I guess that’s a factor, too… The way I use cursor might not be the most common? I have a directory that I load into cursor, and within that directory are a bunch of git repo directories, and within each is a separate git repo for each different project. We have Next.js (React) projects, Nest.js (TypeScript) backend projects, Node.js (JavaScript) projects, AWS lambda function projects, and a few others. Lot of this was in place before I started, and we aren’t in a position for a true monorepo. So I’ve cloned all these into a single directory, and I open that one directory in Cursor. That way I have all the projects at once, I can have the agent cross-reference across them, etc.

~/workspace/
   |__ project_next/
   |__ project_node/
   |__ project_nest/
   |__ knowledge_base
   |__ aws_lambda/
   |__ ...

HOWEVER, the root area that I load into cursor, is NOT a project itself. It contains my .cursor/ directory with my mcp configs and rules. It does not contain any code itself. I don’t know if somehow, this organization might be tripping Sonnet up.