Visual Studio Code 1.139.1 ships as a small patch, fixing managed settings that kept vanishing
The remote-agent features in the release notes landed in 1.139. This update instead stops enterprise policies from quietly evaporating and sweeps in a little CI housekeeping.
Visual Studio Code 1.139.1 is out now. Microsoft pushed the patch on September 25, 2026, with the release credited to VS Code engineer Christof Marti. On paper it's a maintenance release: four commits, three of them pure housekeeping. Buried in there is one change that fixes a real wart, though.
Two commits are just the merge and the version bump, standard release plumbing that updates package.json, the lockfiles, and the Copilot engines target to ^1.139.1. Then there's a commit that skips a flaky Linux end-to-end test on the release branch. Windows already skips it. It had just failed four Linux builds in Azure DevOps build 477081, and the author is clear the underlying defect isn't actually fixed here.
Why managed settings kept vanishing
This is the only commit that changes product behavior. It lives in src/vs/workbench/services/accounts/browser/defaultAccount.ts and concerns server-managed settings, the policy controls your org applies to VS Code, which includes GitHub Copilot telemetry configuration.
Here's the bug. A cached managed-settings response expires an hour after its last successful fetch. If a refresh failed afterward with no response, a 401 or 403, a 429, a 5xx, or a malformed body, so the policy got dropped instead of kept.
Then Copilot reworked its OpenTelemetry reload notification in #336701, and that exposed the regression hard. Enterprise users started seeing a warning every few hours, usually after the app went idle. The message told them their Copilot OTel endpoint would flip to http://localhost:4318 after reload, and reloading cleared their chat. Because every other server-managed control flipped the same way, restrictions were being silently lifted for the whole window.
The fix keeps the last known good response, however old, along with its original timestamp whenever a refresh fails without an explicit forceRemoteSettingsRefresh. A failed fetch no longer counts as a refresh, so it doesn't renew the cache. A 401 or 403 now counts as transient, since that error is often just an access token refreshing itself.
The parts that should still clear policy work as before. A 200 replaces it. A 404 or 466 clears it. Sign-out or an account change drops it. forceRemoteSettingsRefresh still fails closed. Tests gained 49 new passing cases.
What this means for you
For most developers, you won't notice this at all. Keep in mind that the managed-settings problem mostly bites organizations with enforced policies, and even then only when a refresh happens to fail in the right window. If you're one of those people, or if you've watched your Copilot telemetry settings do a little dance, this is a solid, targeted fix. It's a rather boring change, which is arguably the best possible thing about it.
If you came for the 1.139 features, you already have them: the remote agent sessions, the faster session lists that help once you've hoarded hundreds of them, and the Dev Container-on-remote-host capability that drags agent workflows closer to something production-like. The patch just layers a stabilization pass on top without breaking any of that out.
Four commits. Three of them noise. The one that counts closes a gap where enterprise restrictions quietly evaporated and Copilot settings bounced around every few hours. Not flashy. Useful.
To get it, head to the Visual Studio Code download page or just check for updates inside the editor.
