Copilot Agent sometimes replaces contents of one file with contents of another file

[drefrajo]

Describe the bug Sometimes when Copilot Agent mode works on a more complicated task, it can happen that the contents of one file are replaced with the contents of another file.

One example: Say we have some files A, B and C that Copilot tries to edit. Copilot successfully suggests edits for all three files, but looking at the changes actually applied to Xcode only files A and B have the correct changes applied, while C now also contains the same code as for example B.

Versions

• Copilot for Xcode: 0.44.0
• Xcode: 26.0.1
• macOS: 26.1 (happend on 26.0 as well)

Steps to reproduce

1. Ask an Agent to perform some more complicated changes in a non-small code base.
2. Watch as the changes are applied incorrectly.

Screenshots correct edits in the chat ui diff viewer, but incorrectly applied when viewed from the Xcode git view:

after typing continue, the previous changes are applied automatically and the new changes are applied incorrectly once again:

Logs Here are the logs from the time frame I've tried to reproduce the issue. The stuff further down is probably more relevant, as I wasn't immediately able to reproduce it. However, I don't really know what part of these logs actually contains useful information.

Additional context Interestingly, opening the suggested changes from the chat ui (see example above), the changes for file A, B and C are valid. They just seem to be applied incorrectly. Also, the agent was stopped because it reached the maximum attempts limit.

Typing continue made the situation even weirder: Staying with the example above, where previously there suggested changes were displayed in the chat ui, now only one change is shown. Applying this change correctly, the whole issue described above would've been resolved. However, this change was applied incorrectly as well:

actual edits before "continue": A -> edited A B -> edited B C -> edited B

actual edits after "continue": A -> edited A B -> edited B -> edited A C -> edited B

Please note that this A, B, C example might not 100% accurately describe the actually displayed behavior; it's just supposed to roughly illustrate the problem

I was only able to reproduce this in a more complex codebase (i.e. in my own project, where the code can get quite messy and complex in a few places).

When trying to reproduce the issue I used Grok Code Fast 1, I don't know which model I used when I first discovered this problem.

I tried to reproduce the issue in the Simple SwiftUI project, but I had no success. However, I was able to reproduce the problem in my own project (this is not open source so I can't link to the code here). I didn't have the time to try it on another larger project though.

[rolandsmeenk]

This is my biggest annoyance with copilot for Xcode currently. Even if I mark a file as corrupt copilot initially has a firm belief nothing is wrong with it, probably because its internal memory still contains the proper source. If you keep pointing at the build errors it will finally decide to reread the file and detect that it made a mistake. Quickest fix is to ask copilot to add a line of documentation to the top of the affected file and most of the time it will regenerate the proper file. I've seen it happen with different models, but I am mostly using Claude Sonnet 4.5.

[lijie-lee]

Hi @drefrajo @rolandsmeenk, thanks for reaching out. This issue is already on track. We’ll prioritize it and address it as our first priority.

[silenceJialuo]

Thanks for the input @drefrajo and @rolandsmeenk, we will try to fix these ASAP.

[eliasisrael]

I'm getting this consistently as well, and it causes mid-flight changes to get lost. The confusion in the agent between what's in memory and what's on disk compounds the problem.