Agent keeps rolling SDK version backward in global.json as first step

[AArnott]

Describe the bug

Regardless of the issue I assign to Copilot, the first thing it does is push a commit to rollback the .NET SDK version specified in global.json:

https://github.com/microsoft/vs-threading/pull/1465/files/e8cdfd6f6f8d529ac45600f60b77a7abb95b268d..b82695bc0f24c882f13fd1e901f7754f8aee8fe7

This is unnecessary, annoying, and something I'll have to revert before merging.

Expected behavior

Leave the SDK version alone. My repo is known to work with this version, and rolling it backward will quite likely break something.

Screenshots

[nhu-do]

Hi @AArnott, it may very well be that the agent doesn't have the knowledge that 9.0.300 is the newest version to use. My recommendation here is to create a copilot-setup-steps.yml file to install the latest version. Let me know if this helps!

[AArnott]

Thanks. Is there any reason to believe setup steps I'd write would fail due to a firewall? I think most or all copilot PRs warn me that a firewall is in place and limiting its activities. I don't know why. sample PR.

[AArnott]

I added the copilot-setup-steps.yml file you suggested, as you can see.

But after assigning an issue to copilot to fix, I can see from its session logs that it didn't appear to use that new file. I can't see any evidence that it did, and I see a note about how a shallow clone led to a failure, that it had to workaround. But my file would have prevented a shallow clone had it been used.

[swettstein]

@AArnott if you look at the detail action of the session, you can see that it did run your workflow steps: https://github.com/AArnott/Xunit.SkippableFact/actions/runs/15594871607/job/43922777549

[AArnott]

Yes, I see. But then my workflow isn't being followed.
It clearly asks for a non-shallow git checkout:

https://github.com/AArnott/Xunit.SkippableFact/blob/4678496dc57610b6b2d4635f5f7ce4d887a5caf6/.github/workflows/copilot-setup-steps.yml#L29-L31

But the agent session complains:

The build failed due to Git versioning issues with shallow clone.

I see in the log you linked to that it disregarded my fetch depth 0 parameter:

https://github.com/AArnott/Xunit.SkippableFact/actions/runs/15594871607/job/43922777549#step:4:53

/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=2 origin +208c2f6de8c67d3f42d7f4cf3822cd6b6843a02e:refs/remotes/origin/copilot/fix-31

Notice the depth=2 switch.

Why is it disregarding my explicit step that is designed to avoid the trouble that copilot ended up having?