Microsoft Release Notes

All Microsoft Release Notes (294)

• Feb 12, 2026

  • Date parsed from source:
    Feb 12, 2026
  • First seen by Releasebot:
    Feb 13, 2026
  

  SQL Server 2025 by Microsoft

  Cumulative Update 2 for SQL Server 2025 (KB5075211)

  Microsoft SQL Server 2025 Cumulative Update 2 adds a set of fixes across SQL Server and Analysis Services, including parallel SESSION_CONTEXT handling and several engine and availability group corrections. A companion Excel with builds and fix lists is provided for details.

  Known issues in this update

  Incorrect behavior of SESSION_CONTEXT in parallel plans
  Queries that use the built-in SESSION_CONTEXT function might return incorrect results or trigger access violation (AV) dump files when run in parallel query plans. This issue occurs because of the manner in which SESSION_CONTEXT interacts with parallel execution threads, particularly if the session is reset for reuse.
  For more information, see the Known issues section in SESSION_CONTEXT.

  Improvements and fixes included in this update

  A downloadable Microsoft Excel workbook that contains a summary list of builds, together with their current support lifecycle, is available. The Excel file also contains detailed fix lists for SQL Server 2025, SQL Server 2022, SQL Server 2019, and SQL Server 2017. Download this Excel file now.

  Note
  Individual entries in the following table can be referenced directly through a bookmark. If you select any bug reference ID in the table, a bookmark tag is added to the URL by using the "#NNNNNNN" format. You can then share this URL with others so that they can jump directly to the desired fix in the table.

  For more information about the bugs that are fixed and enhancements that are included in this cumulative update, see the following table.

  Improvements and fixes included in this update:

  • Bug reference 4838699: Fixes an issue that causes StripedVdi tests to fail if the Sqlvdi.dll file isn't registered on running instances. Fix area: SQL Server Engine, Backup Restore, Platform: Windows
  • Bug reference 4860948: For cluster_type = NONE or EXTERNAL, availability group (AG) properties exist on only the local replica. This update writes the properties to the AG configuration so that all AG replicas receive the same properties. Fix area: SQL Server Engine, High Availability and Disaster Recovery, Platform: All
  • Bug reference 4869015: Fixes a potential inaccuracy in resource governor accounting for the tempdb space if accelerated database recovery is enabled for tempdb. Fix area: SQL Server Engine, Resource Governor, Platform: All
  • Bug reference 4924793: Fixes an issue in which an assertion and a dump file are generated around midnight on New Year’s Day during an operation that accesses Azure Blob Storage. Fix area: SQL Server Engine, Storage Management, Platform: All
  • Bug reference 4925942: Fixes an issue that triggers nonyielding scheduler dump files in PmmLogAcceptBlock on the availability group (AG) secondary replica. The issue occurs if the persistent log buffer is enabled, and the database log cache contains primarily tiny log records. Fix area: SQL Server Engine, Log Management, Platform: All
  • Bug reference 4931611: Fixes an issue in which the distributor is part of an availability group (AG) and uses case-sensitive (_CS) collation. The distribution agent incorrectly uses the AG primary replica name instead of AG listener name. Fix area: SQL Server Engine, Replication, Platform: All

  How to obtain or download this CU or the latest CU package

  File information

  Notes for this update

  How to uninstall this update

  References

  Original source Report a problem

  Show more
• Feb 11, 2026

  • Date parsed from source:
    Feb 11, 2026
  • First seen by Releasebot:
    Feb 12, 2026
  

  TypeScript by Microsoft

  Announcing TypeScript 6.0 Beta

  TypeScript 6.0 beta released with a bridge to 7.0 and a native Go port plan. Expect new defaults, deprecations, ES2025 support, Temporal types, Map upsert helpers, improved subpath imports, and migration aids for 7.0.

  Today we are announcing the beta release of TypeScript 6.0! To get started using the beta, you can get it through npm with the following command:
  npm install -D typescript@beta
  TypeScript 6.0 is a unique release in that we intend for it to be the last release based on the current JavaScript codebase. As announced last year (with recent updates here), we are working on a new codebase for the TypeScript compiler and language service written in Go that takes advantage of the speed of native code and shared-memory multi-threading. This new codebase will be the foundation of TypeScript 7.0 and beyond. TypeScript 6.0 will be the immediate precursor to that release, and in many ways it will act as the bridge between TypeScript 5.9 and 7.0. As such, most changes in TypeScript 6.0 are meant to help align and prepare for adopting TypeScript 7.0.
  With that said, there are some new features and improvements that are not just about alignment. Let’s take a look at some of the highlights of this release, followed by a more detailed look at what’s changing for 7.0 and how to prepare for it.

  Less Context-Sensitivity on this-less Functions
  When parameters don’t have explicit types written out, TypeScript can usually infer them based on an expected type, or even through other arguments in the same function call.

  Here, TypeScript can infer the type of y in the consume function based on the inferred T from the produce function, regardless of the order of the properties. But what about if these functions were written using method syntax instead of arrow function syntax?

  Strangely enough, the second call to callIt results in an error because TypeScript is not able to infer the type of y in the consume method. What’s happening here is that when TypeScript is trying to find candidates for T, it will first skip over functions whose parameters don’t have explicit types. It does this because certain functions may need the inferred type of T to be correctly checked – in our case, we need to know the type of T to analyze our consume function.

  These functions are called contextually sensitive functions – basically, functions that have parameters without explicit types. Eventually the type system will need to figure out types for these parameters – but this is a bit at odds with how inference works in generic functions because the two "pull" on types in different directions.

  To solve this, TypeScript skips over contextually sensitive functions during type argument inference, and instead checks and infers from other arguments first. If skipping over contextually sensitive functions doesn’t work, inference just continues across any unchecked arguments, going left-to-right in the argument list. In the example immediately above, TypeScript will skip over the callback during inference for T, but will then look at the second argument, 42, and infer that T is number. Then, when it comes back to check the callback, it will have a contextual type of (x: number) => void, which allows it to infer that x is a number as well.

  So what’s going on in our earlier examples?

  In both examples, produce is assigned a function with an explicitly-typed x parameter. Shouldn’t they be checked identically?

  The issue is subtle: most functions (like the ones using method syntax) have an implicit this parameter, but arrow functions do not. Any usage of this could require "pulling" on the type of T – for example, knowing the type of the containing object literal could in turn require the type of consume, which uses T.

  But we’re not using this! Sure, the function might have a this value at runtime, but it’s never used!

  TypeScript 6.0 takes this into account when it decides if a function is contextually sensitive or not. If this is never actually used in a function, then it is not considered contextually sensitive. That means these functions will be seen as higher-priority when it comes to type inference, and all of our examples above now work!

  This change was provided thanks to the work of Mateusz Burzyński.

  Subpath Imports Starting with #/
  When Node.js added support for modules, it added a feature called "subpath imports". This is basically a field called imports which allows packages to create internal aliases for modules within their package.

  This allows modules in my-package to import from #root instead of having to use a relative path like ../../index.js, and basically allows any other module to write something like
  import * as utils from "#root/utils.js";
  instead of using a relative path like the following.
  import * as utils from "../../utils.js";

  One minor annoyance with this feature has been that developers always had to write something after the # when specifying a subpath import. Here, we used root, but it is a bit useless since there is no directory we’re mapping over other than ./dist/

  Developers who have used bundlers are also accustomed to using path-mapping to avoid long relative paths. A familiar convention with bundlers has been to use a simple @/ as the prefix. Unfortunately, subpath imports could not start with #/ at all, leading to a lot of confusion for developers trying to adopt them in their projects.

  But more recently, Node.js added support for subpath imports starting with #/. This allows packages to use a simple #/ prefix for their subpath imports without needing to add an extra segment.

  This is supported in newer Node.js 20 releases, and so TypeScript now supports it under the options node20, nodenext, and bundler for the --moduleResolution setting.

  This work was done thanks to magic-akari, and the implementing pull request can be found here.

  Combining --moduleResolution bundler with --module commonjs
  TypeScript’s --moduleResolution bundler setting was previously only allowed to be used with --module esnext or --module preserve; however, with the deprecation of --moduleResolution node (a.k.a. --moduleResolution node10), this new combination is often the most suitable upgrade path for many projects.

  Projects will often want to instead plan out a migration towards either
  • --module preserve and --moduleResolution bundler
  • --module nodenext
  depending on your project type (e.g. bundled web app, Bun app, or Node.js app).

  More information can be found at this implementing pull request.

  The --stableTypeOrdering Flag
  As part of our ongoing work on TypeScript’s native port, we’ve introduced a new flag called --stableTypeOrdering intended to assist with 6.0-to-7.0 migrations.

  Today, TypeScript assigns type IDs (internal tracking numbers) to types in the order they are encountered, and uses these IDs to sort union types in a consistent manner. A similar process occurs for properties. As a result, the order in which things are declared in a program can have possibly surprising effects on things like declaration emit.

  For example, consider the declaration emit from this file:
  // Input: some-file.ts
  export function foo(condition: boolean) {
  return condition ? 100 : 500;
  }
  // Output: some-file.d.ts
  export declare function foo(condition: boolean): 100 | 500;
  // Note the order of this union: 100, then 500.

  If we add an unrelated const above foo, the declaration emit changes:
  // Input: some-file.ts
  const x = 500;
  export function foo(condition: boolean) {
  return condition ? 100 : 500;
  }
  // Output: some-file.d.ts
  export declare function foo(condition: boolean): 500 | 100;
  // Note the change in order here.

  This happens because the literal type 500 gets a lower type ID than 100 because it was processed first when analyzing the const x declaration. In very rare cases this change in ordering can even cause errors to appear or disappear based on program processing order, but in general, the main place you might notice this ordering is in the emitted declaration files, or in the way types are displayed in your editor.

  One of the major architectural improvements in TypeScript 7 is parallel type checking, which dramatically improves overall check time. However, parallelism introduces a challenge: when different type-checkers visit nodes, types, and symbols in different orders, the internal IDs assigned to these constructs become non-deterministic. This in turn leads to confusing non-deterministic output, where two files with identical contents in the same program can produce different declaration files, or even calculate different errors when analyzing the same file. To fix this, TypeScript 7.0 sorts its internal objects (e.g. types and symbols) according to a deterministic algorithm based on the content of the object. This ensures that all checkers encounter the same object order regardless of how and when they were created. As a consequence, in the given example, TypeScript 7 will always print 100 | 500, removing the ordering instability entirely.

  This means that TypeScript 6 and 7 can and do sometimes display different ordering. While these ordering changes are almost always benign, if you’re comparing compiler outputs between runs (for example, checking emitted declaration files in 6.0 vs 7.0), these different orderings can produce a lot of noise that makes it difficult to assess correctness. Occasionally though, you may witness a change in ordering that causes a type error to appear or disappear, which can be even more confusing.

  To help with this situation, in 6.0, you can specify the new --stableTypeOrdering flag. This makes 6.0’s type ordering behavior match 7.0’s, reducing the number of differences between the two codebases. Note that we don’t necessarily encourage using this flag all the time as it can add a substantial slowdown to type-checking (up to 25% depending on codebase).

  If you encounter a type error using --stableTypeOrdering, this is typically due to inference differences. The previous inference without --stableTypeOrdering happened to work based on the current ordering of types in your program. To help with this, you’ll often benefit from providing an explicit type somewhere. Often, this will be a type argument or a variable annotation for an argument you intend to pass into a call.

  Note that this flag is only intended to help diagnose differences between 6.0 and 7.0 – it is not intended to be used as a long-term feature.

  See more at this pull-request.

  es2025 option for target and lib
  TypeScript 6.0 adds support for the es2025 option for both target and lib. While there are no new JavaScript language features in ES2025, this new target adds new types for built-in APIs (e.g. RegExp.escape), and moves a few declarations from esnext into es2025 (e.g. Promise.try, Iterator methods, and Set methods). Work to enable the new target was contributed thanks to Kenta Moriuchi.

  New Types for Temporal
  The long-awaited Temporal proposal has reached stage 3 and is expected to be added to JavaScript in the near future. TypeScript 6.0 now includes built-in types for the Temporal API, so you can start using it in your TypeScript code today via --target esnext or "lib": ["esnext"] (or the more-granular temporal.esnext).

  Temporal is already usable in several runtimes, so you should be able to start experimenting with it soon. Documentation on the Temporal APIs is available on MDN, though it may still be incomplete.

  This work was contributed thanks to GitHub user Renegade334.

  New Types for "upsert" Methods (a.k.a. getOrInsert)
  A common pattern with Maps is to check if a key exists, and if not, set and fetch a default value.

  This pattern can be tedious. ECMAScript’s "upsert" proposal recently reached stage 4, and introduces 2 new methods on Map and WeakMap:
  • getOrInsert
  • getOrInsertComputed

  These methods have been added to the esnext lib so that you can start using them immediately in TypeScript 6.0.

  With getOrInsert, we can replace our code above with the following:

  getOrInsertComputed works similarly, but is for cases where the default value may be expensive to compute (e.g. requires lots of computations, allocations, or does long-running synchronous I/O). Instead, it takes a callback that will only be called if the key is not already present.

  This callback is also given the key as an argument, which can be useful for cases where the default value is based on the key.

  This update was contributed thanks to GitHub user Renegade334.

  RegExp.escape
  When constructing some literal string to match within a regular expression, it is important to escape special regular expression characters like *, +, ?, (, ), etc. The RegExp Escaping ECMAScript proposal has reached stage 4, and introduces a new RegExp.escape function that takes care of this for you.

  RegExp.escape is available in the es2025 lib, so you can start using it in TypeScript 6.0 today.

  This work was contributed thanks Kenta Moriuchi.

  The dom lib Now Contains dom.iterable and dom.asynciterable
  TypeScript’s lib option allows you to specify which global declarations your target runtime has. One option is dom to represent web environments (i.e. browsers, who implement the DOM APIs). Previously, the DOM APIs were partially split out into dom.iterable and dom.asynciterable for environments that didn’t support Iterables and AsyncIterables. This meant that you had to explicitly add dom.iterable to use iteration methods on DOM collections like NodeList or HTMLCollection.

  In TypeScript 6.0, the contents of lib.dom.iterable.d.ts and lib.dom.asynciterable.d.ts are fully included in lib.dom.d.ts. You can still reference dom.iterable and dom.asynciterable in your configuration file’s "lib" array, but they are now just empty files.

  This is a quality-of-life improvement that eliminates a common point of confusion, since no major modern browser lacks these capabilities. If you were already including both dom and dom.iterable, you can now simplify to just dom.

  See more at this issue and its corresponding pull request.

  Breaking Changes and Deprecations in TypeScript 6.0
  TypeScript 6.0 arrives as a significant transition release, designed to prepare developers for TypeScript 7.0, the upcoming native port of the TypeScript compiler. While TypeScript 6.0 maintains full compatibility with your existing TypeScript knowledge and continues to be API compatible with TypeScript 5.9, this release introduces a number of breaking changes and deprecations that reflect the evolving JavaScript ecosystem and set the stage for TypeScript 7.0.

  In the two years since TypeScript 5.0, we’ve seen ongoing shifts in how developers write and ship JavaScript:
  • Virtually every runtime environment is now "evergreen". True legacy environments (ES5) are vanishingly rare.
  • Bundlers and ESM have become the most common module targets for new projects, though CommonJS remains a major target. AMD and other in-browser userland module systems are much rarer than they were in 2012.
  • Almost all packages can be consumed through some module system. UMD packages still exist, but virtually no new code is available only as a global variable.
  • tsconfig.json is nearly universal as a configuration mechanism.
  • Appetite for "stricter" typing continues to grow.
  • TypeScript build performance is top of mind. Despite the gains of TypeScript 7, performance must always remain a key goal, and options which can’t be supported in a performant way need to be more strongly justified.

  So TypeScript 6.0 and 7.0 are designed with these realities in mind. For TypeScript 6.0, these deprecations can be ignored by setting "ignoreDeprecations": "6.0" in your tsconfig; however, note that TypeScript 7.0 will not support any of these deprecated options.

  Some necessary adjustments can be automatically performed with a codemod or tool. For example, the experimental ts5to6 tool can automatically adjust baseUrl and rootDir across your codebase.

  Up-Front Adjustments
  We’ll cover specific adjustments below, but we have to note that some deprecations and behavior changes do not necessarily have an error message that directly points to the underlying issue. So we’ll note up-front that many projects will need to do at least one of the following:
  • Set the "types" array in tsconfig, typically to "types": ["node"]. "types": ["*"] will restore the 5.9 behavior, but we recommend using an explicit array to improve build performance and predictability. You’ll typically know this is the issue if you see a lot of type errors related to missing identifiers or unresolved built-in modules.
  • Set "rootDir": "./src" if you were previously relying on this being inferred. You’ll often know this is the issue if you see files being written to ./dist/src/index.js instead of ./dist/index.js.

  Simple Default Changes
  Several compiler options now have updated default values that better reflect modern development practices.
  • strict is now true by default: The appetite for stricter typing continues to grow, and we’ve found that most new projects want strict mode enabled. If you were already using "strict": true, nothing changes for you. If you were relying on the previous default of false, you’ll need to explicitly set "strict": false in your tsconfig.json.
  • module defaults to esnext: Similarly, the new default module is esnext, acknowledging that ESM is now the dominant module format.
  • target defaults to current-year ES version: The new default target is the most recent supported ECMAScript spec version (effectively a floating target). Right now, that target is es2025. This reflects the reality that most developers are shipping to evergreen runtimes and don’t need to transpile down to older ECMAScript versions.
  • noUncheckedSideEffectImports is now true by default: This helps catch issues with typos in side-effect-only imports.
  • libReplacement is now false by default: This flag previously incurred a large number of failed module resolutions for every run, which in turn increased the number of locations we needed to watch under --watch and editor scenarios. In a new project, libReplacement never does anything until other explicit configuration takes place, so it makes sense to turn this off by default for the sake of better performance by default.

  If these new defaults break your project, you can specify the previous values explicitly in your tsconfig.json.

  rootDir now defaults to .
  rootDir controls the directory structure of your output files relative to the output directory. Previously, if you did not specify a rootDir, it was inferred based on the common directory of all non-declaration input files. But this often meant that it was impossible to know if a file belonged to a project without trying to load and parse that project. It also meant that TypeScript had to spend more time inferring that common source directory by analyzing every file path in the program.

  In TypeScript 6.0, the default rootDir will always be the directory containing the tsconfig.json file. rootDir will only be inferred when using tsc from the command line without a tsconfig.json file.

  If you have source files any level deeper than your tsconfig.json directory and were relying on TypeScript to infer a common root directory for source files, you’ll need to explicitly set rootDir.

  Likewise, if your tsconfig.json referenced files outside of the containing tsconfig.json, you would need to adjust your rootDir to include those files.

  See more at the discussion here and the implementation here.

  types now defaults to []
  In a tsconfig.json, the types field of compilerOptions specifies a list of package names to be included in the global scope during compilation. Typically, packages in node_modules are automatically included via imports in your source code; but for convenience, TypeScript would also include all packages in node_modules/@types by default, so that you can get global declarations like process or the "fs" module from @types/node, or describe and it from @types/jest, without needing to import them directly.

  In a sense, the types value previously defaulted to "enumerate everything in node_modules/@types". This can be very expensive, as a normal repository setup these days might transitively pull in hundreds of @types packages, especially in multi-project workspaces with flattened node_modules. Modern projects almost always need only @types/node, @types/jest, or a handful of other common global-affecting packages.

  In TypeScript 6.0, the default types value will be [] (an empty array). This change prevents projects from unintentionally pulling in hundreds or even thousands of unneeded declaration files at build time. Many projects we’ve looked at have improved their build time anywhere from 20-50% just by setting types appropriately.

  This will affect many projects. You will likely need to add "types": ["node"] or a few others.

  You can also specify a * entry to re-enable the old enumeration behavior.

  If you end up with new error messages like the following:
  Cannot find module '...' or its corresponding type declarations.
  Cannot find name 'fs'. Do you need to install type definitions for node? Try npm i --save-dev @types/node and then add 'node' to the types field in your tsconfig.
  Cannot find name 'path'. Do you need to install type definitions for node? Try npm i --save-dev @types/node and then add 'node' to the types field in your tsconfig.
  Cannot find name 'process'. Do you need to install type definitions for node? Try npm i --save-dev @types/node and then add 'node' to the types field in your tsconfig.
  Cannot find name 'Bun'. Do you need to install type definitions for Bun? Try npm i --save-dev @types/bun and then add 'bun' to the types field in your tsconfig.
  Cannot find name 'describe'. Do you need to install type definitions for a test runner? Try npm i --save-dev @types/jest or npm i --save-dev @types/mocha and then add 'jest' or 'mocha' to the types field in your tsconfig.

  it’s likely that you need to add some entries to your types field.

  See more at the proposal here along with the implementing pull request here.

  Deprecated: target: es5
  The ECMAScript 5 target was important for a long time to support legacy browsers; but its successor, ECMAScript 2015 (ES6), was released over a decade ago, and all modern browsers have supported it for many years. With Internet Explorer’s retirement, and the universality of evergreen browsers, there are very few use cases for ES5 output today.

  TypeScript’s lowest target will now be ES2015, and the target: es5 option is deprecated. If you were using target: es5, you’ll need to migrate to a newer target or use an external compiler. If you still need ES5 output, we recommend using an external compiler to either directly compile your TypeScript source, or to post-process TypeScript’s outputs.

  See more about this deprecation here along with its implementing pull request.

  Deprecated: --downlevelIteration
  --downlevelIteration only has effects on ES5 emit, and since --target es5 has been deprecated, --downlevelIteration no longer serves a purpose.

  Subtly, using --downlevelIteration false with --target es2015 did not error in TypeScript 5.9 and earlier, even though it had no effect. In TypeScript 6.0, setting --downlevelIteration at all will lead to a deprecation error.

  See the implementation here.

  Deprecated: --moduleResolution node (a.k.a. --moduleResolution node10)
  --moduleResolution node encoded a specific version of Node.js’s module resolution algorithm that most-accurately reflected the behavior of Node.js 10. Unfortunately, this target (and its name) ignores many updates to Node.js’s resolution algorithm that have occurred since then, and it is no longer a good representation of the behavior of modern Node.js versions.

  In TypeScript 6.0, --moduleResolution node (specifically, --moduleResolution node10) is deprecated. Users who were using --moduleResolution node should usually migrate to --moduleResolution nodenext if they plan on targeting Node.js directly, or --moduleResolution bundler if they plan on using a bundler or Bun.

  See more at this issue and its corresponding pull request.

  Deprecated: amd, umd, and systemjs values of module
  The following flag values are no longer supported
  • --module amd
  • --module umd
  • --module systemjs

  AMD, UMD, and SystemJS were important during the early days of JavaScript modules when browsers lacked native module support. Today, ESM is universally supported in browsers and Node.js, and both import maps and bundlers have become favored ways for filling in the gaps. If you’re still targeting these module systems, consider migrating to an appropriate ECMAScript module-emitting target, adopt a bundler or different compiler, or stay on TypeScript 5.x until you can migrate.

  This also implies dropped support for the amd-module directive, which will no longer have any effect.

  See more at the proposal issue along with the implementing pull request.

  Deprecated: --baseUrl
  The baseUrl option is most-commonly used in conjunction with paths, and is typically used as a prefix for every value in paths. Unfortunately, baseUrl is also considered a look-up root for module resolution.

  For example, given the following tsconfig.json
  {
  "compilerOptions": {
  // ...
  "baseUrl": "./src",
  "paths": {
  "@app/": ["app/"],
  "@lib/": ["lib/"]
  }
  }
  }

  and an import like
  import * as someModule from "someModule.js";

  TypeScript will probably resolve this to src/someModule.js, even if the developer only intended to add mappings for modules starting with @app/ and @lib/.

  In the best case, this also often leads to "worse-looking" paths that bundlers would ignore; but it often meant that that many import paths that would never have worked at runtime are considered "just fine" by TypeScript.

  path mappings have not required specifying baseUrl for a long time, and in practice, most projects that use baseUrl only use it as a prefix for their paths entries. In TypeScript 6.0, baseUrl is deprecated and will no longer be considered a look-up root for module resolution.

  Developers who used baseUrl as a prefix for path-mapping entries can simply remove baseUrl and add the prefix to their paths entries:
  {
  "compilerOptions": {
  // ...
  "paths": {
  "@app/": ["./src/app/"],
  "@lib/": ["./src/lib/"]
  }
  }
  }

  Developers who actually did use baseUrl as a look-up root can also add an explicit path mapping to preserve the old behavior:
  {
  "compilerOptions": {
  // ...
  "paths": {
  "": ["./src/"],
  "@app/": ["./src/app/"],
  "@lib/": ["./src/lib/"]
  }
  }
  }

  However, this is extremely rare. We recommend most developers simply remove baseUrl and add the appropriate prefixes to their paths entries.

  See more at this issue and the corresponding pull request.

  Deprecated: --moduleResolution classic
  The moduleResolution: classic setting has been removed. The classic resolution strategy was TypeScript’s original module resolution algorithm, and predates Node.js’s resolution algorithm becoming a de facto standard. Today, all practical use cases are served by nodenext or bundler. If you were using classic, migrate to one of these modern resolution strategies.

  See more at this issue and the implementing pull request.

  Deprecated: --esModuleInterop false and --allowSyntheticDefaultImports false
  The following settings can no longer be set to false:
  • esModuleInterop
  • allowSyntheticDefaultImports

  esModuleInterop and allowSyntheticDefaultImports were originally opt-in to avoid breaking existing projects. However, the behavior they enable has been the recommended default for years. Setting them to false often led to subtle runtime issues when consuming CommonJS modules from ESM. In TypeScript 6.0, the safer interop behavior is always enabled.

  If you have imports that rely on the old behavior, you may need to adjust them:
  // Before (with esModuleInterop: false)
  import * as express from "express";
  // After (with esModuleInterop always enabled)
  import express from "express";

  See more at this issue and its implementing pull request.

  Deprecated: --alwaysStrict false
  The alwaysStrict flag refers to inference and emit of the "use strict" directive. In TypeScript 6.0, all code will be assumed to be in JavaScript strict mode, which is a set of JS semantics that most-noticeably affects syntactic corner cases around reserved words. If you have "sloppy mode" code that uses reserved words like await, static, private, or public as regular identifiers, you’ll need to rename them. If you relied on subtle semantics around the meaning of this in non-strict code, you may need to adjust your code as well.

  See more at this issue and its corresponding pull request.

  Deprecated: outFile
  The --outFile option has been removed from TypeScript 6.0. This option was originally designed to concatenate multiple input files into a single output file. However, external bundlers like Webpack, Rollup, esbuild, Vite, Parcel, and others now do this job faster, better, and with far more configurability. Removing this option simplifies the implementation and allows us to focus on what TypeScript does best: type-checking and declaration emit. If you’re currently using --outFile, you’ll need to migrate to an external bundler. Most modern bundlers have excellent TypeScript support out of the box.

  Deprecated: legacy module Syntax for namespaces
  Early versions of TypeScript used the module keyword to declare namespaces:
  // ❌ Deprecated syntax - now an error
  module Foo {
  export const bar = 10;
  }

  This syntax was later aliased to the modern preferred form using the namespace keyword:
  // ✅ The correct syntax
  namespace Foo {
  export const bar = 10;
  }

  When namespace was introduced, the module syntax was simply discouraged. A few years ago, the TypeScript language service started marking the keyword as deprecated, suggesting namespace in its place.

  In TypeScript 6.0, using module where namespace is expected is now a hard deprecation. This change is necessary because module blocks are a potential ECMAScript proposal that would conflict with the legacy TypeScript syntax.

  The ambient module declaration form remains fully supported:
  // ✅ Still works perfectly
  declare module "some-module" {
  export function doSomething(): void;
  }

  See this issue and its corresponding pull request for more details.

  Deprecated: asserts Keyword on Imports
  The asserts keyword was proposed to the JavaScript language via the import assertions proposal; however, the proposal eventually morphed into the import attributes proposal, which uses the with keyword instead of asserts.

  Thus, the asserts syntax is now deprecated in TypeScript 6.0, and using it will lead to an error:
  // ❌ Deprecated syntax - now an error.
  import blob from "./blahb.json" asserts { type: "json" }
  // error: Import assertions have been replaced by import attributes. Use 'with' instead of 'asserts'.

  Instead, use the with syntax for import attributes:
  // ✅ Works with the new import attributes syntax.
  import blob from "./blahb.json" with { type: "json" }

  See more at this issue and its corresponding pull request.

  Deprecated: no-default-lib Directives
  The /// directive has been largely misunderstood and misused. In TypeScript 6.0, this directive is no longer supported. If you were using it, consider using --noLib or --libReplacement instead.

  See more here and at the corresponding pull request.

  Specifying Command-Line Files When tsconfig.json Exists is Now an Error
  Currently, if you run tsc foo.ts in a folder where a tsconfig.json exists, the config file is completely ignored. This was often very confusing if you expected checking and emit options to apply to the input file.

  In TypeScript 6.0, if you run tsc with file arguments in a directory containing a tsconfig.json, an error will be issued to make this behavior explicit:
  error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.

  If it is the case that you wanted to ignore the tsconfig.json and just compile foo.ts with TypeScript’s defaults, you can use the new --ignoreConfig flag.

  See more at this issue and its corresponding pull request.

  Preparing for TypeScript 7.0
  TypeScript 6.0 is designed as a transition release. While the options deprecated in TypeScript 6.0 will continue to work without errors when "ignoreDeprecations": "6.0" is set, they will be removed entirely in TypeScript 7.0 (the native TypeScript port). If you’re seeing deprecation warnings after upgrading to TypeScript 6.0, we strongly recommend addressing them before trying to adopt TypeScript 7 (or its native previews) in your project.

  As to the schedule between TypeScript 6.0 and 7.0, we plan for 7.0 to be released soon after 6.0. This should help us keep some continuity in our development with the chance to address issues sooner after the release of 7.0.

  What’s Next?
  At this point, TypeScript 6.0 is "feature stable", and we don’t plan on any new features or breaking changes. Over the next few weeks, we’ll be addressing any new issues reported on the 6.0 codebase, so we encourage you to leave feedback and report any issues you encounter. And while the beta release is a great way to try out the next version of TypeScript, we also publish nightly builds on npm and in your editor which are typically very stable. These releases can often give you a better snapshot of which issues have been fixed.

  We are also continuing to work on TypeScript 7.0, and publish nightly builds of our native previews along with a VS Code extension too. Feedback on both 6.0 and 7.0 are very much appreciated, and we encourage you to try out both if you can.

  So try TypeScript 6.0 beta in your project today, and let us know what you think!

  Happy Hacking!
  – Daniel Rosenwasser and the TypeScript Team

  Original source Report a problem

  Show more
• All of your release notes in one place

  Join Releasebot and get updates from Microsoft and hundreds of other software products.

  Create account

  Subscribe with: RSS Email API Slack n8n Zapier
• Feb 11, 2026

  • Date parsed from source:
    Feb 11, 2026
  • First seen by Releasebot:
    Feb 12, 2026
  

  Microsoft Teams by Microsoft

  February 11, 2026

  Microsoft Teams gains a first‑party admin migration tool to move content from third‑party workspaces into Teams channels, plus a policy for explicit consent in 1:1 call recording and transcription, a restart option for live town halls, and automated troubleshooting guidance in Admin Center.

  Migration tool for Teams

  This feature enables customers to move content seamlessly from public and private channels in a third-party solution to Teams standard channels. A new first-party Migration tool on Microsoft Admin Center (MAC) will allow admins to connect to the third-party solution workspace, plan, and perform content migration to Teams.

  New policy setting to require explicit consent for recording and transcription in Teams 1:1 calls

  We're expanding the capability to require explicit consent for recording and transcription to include 1:1 calls in Microsoft Teams. A new setting in the Teams Calling policy allows enforcement of this requirement through the admins before recording or transcription can begin. When a user with the policy initiates recording, transcription, or both in a 1:1 call, the other participant is automatically muted, with their camera and content-sharing turned off. The participant will see a prompt asking whether they consent to be included in the recording and transcription.

  Restart your town hall event

  This feature enables Teams town hall producers to restart a live event while the event is active to address technical issues that might arise during the execution of an instance. Whether technical, network, or other issues, this feature enables those managing the event to quickly resolve problems for attendees. This feature is designed to prevent the need for scheduling entirely new events.

  Teams admin center - Troubleshoot meetings and calls with automatic issue identification and recommendations

  This feature enables administrators to troubleshoot Teams meetings and calls in Teams admin center with ease with a streamlined flow (that focuses on the meeting-quality issues) and detailed telemetry.

  Original source Report a problem

  Show more
• Feb 10, 2026

  • Date parsed from source:
    Feb 10, 2026
  • First seen by Releasebot:
    Feb 11, 2026
  

  Microsoft Copilot by Microsoft

  February 10, 2026

  Microsoft 365 Copilot Extensibility unlocks faster admin setup with guided OAuth, live Adaptive Card refresh, and champion connectors while enabling URL-based dialogs. New connectors for ServiceNow, Miro, and GitHub Server boost workflow continuity and cross‑tool collaboration.

  Microsoft 365 Copilot extensibility

  Admins can set up connector authentication faster with a simplified experience [Web]

  Admins can now set up connector authentication faster through a simplified and guided OAuth experience.

  Details:

  What changed: Previously, connector authentication required manual steps and extensive documentation. The new experience introduces a streamlined, guided OAuth flow that significantly reduces setup time.

  Why: This change modernizes the authentication framework and reduces friction for admins configuring connectors.

  Try this:

  • Open connector setup and follow the guided OAuth flow.
  • Complete authentication for supported connectors such as Gong, GitHub, or Monday.

  Why this matters:

  Business impact: Reduces configuration time and operational overhead for IT teams.

  Personal impact: Makes connector setup faster and easier for admins.

  Additional resources:
  Learn:
  Set up Microsoft 365 Copilot connectors in the Microsoft 365 admin center

  Users can refresh Adaptive Cards in agents to view the latest information [Web]

  Users can refresh Adaptive Cards in agents to ensure they always see the most current information in their workflows.

  Details:

  What changed: Users can now refresh Adaptive Cards inside their agents to view updated information. Previously, cards remained static unless the agent was recreated or reloaded.

  Why: This improvement helps users stay aligned with the latest data, reducing confusion and improving workflow accuracy.

  Try this:

  • Select the refresh option on an Adaptive Card inside your agent.
  • Use the updated card to continue your workflow with the latest information.
  • Check refreshed cards when reviewing time‑sensitive or changing data.

  Why this matters:

  Business impact: Ensures teams work with accurate, up‑to‑date information.

  Personal impact: Reduces manual steps and helps individuals stay current with ongoing changes.

  Additional resources:
  Learn:
  Allow inline editing of Adaptive Card responses (preview)

  Field teams can accelerate Copilot adoption using champion connectors [Web]

  Field teams can use getting started guides of champion connectors to guide customers through Copilot adoption with clear, consistent resources.

  Details:

  What changed: Field teams can now use getting started guides champion connectors to guide Copilot adoption in top accounts. This adds structured resources and best practices that were not available in earlier workflows.

  Why: This change gives field teams consistent tools that help customers adopt Copilot more quickly and confidently.

  Try this:

  • Review champion connector resources available to your field team.
  • Share the connector with top accounts beginning their Copilot journey.
  • Use the resources to guide conversations about adoption planning.

  Why this matters:

  Business impact: Supports faster and more consistent Copilot adoption across key customer accounts.

  Personal impact: Makes it easier for individuals to provide clear, ready-to-use guidance.

  Additional Resources:
  Learn:
  Set up Microsoft 365 Copilot connectors in the Microsoft 365 admin center

  Declarative Agents help users stay in their workflow [Web]

  URL‑based dialogs in Declarative Agents allow users to open linked experiences without leaving Copilot, helping them stay focused.

  Details:

  What changed: Developers can now enable URL‑based dialogs in Declarative Agents. This lets users open external pages or forms directly within Copilot. Previously, these workflows required switching apps or breaking context.

  Why: This feature helps users complete tasks without interruption, supporting smoother and more connected workflows.

  Try this:

  • Open a Declarative Agent that includes a URL‑based dialog.
  • Follow the dialog link to continue your workflow inside Copilot.
  • Use the dialog to complete tasks that require external pages or forms.

  Why this matters:

  Business impact: Reduces context switching and improves workflow continuity.

  Personal impact: Helps individuals complete tasks more efficiently without leaving Copilot.

  Additional resources:
  Learn:
  Allow inline editing of Adaptive Card responses (preview)

  More frequent ticket status updates for the ServiceNow Tickets Copilot connector [Web]

  The ServiceNow Tickets Copilot connector updates ticket status more frequently by ingesting both active and inactive tickets.

  Roadmap ID:
  505437

  Details:

  What changed: The ServiceNow Tickets Copilot connector now ingests both active and inactive tickets by default, improving how often ticket status changes appear in Copilot responses. Admins can also edit the data query filter to include inactive tickets for existing connections.

  Why: Inactive tickets were not previously ingested, which could lead to outdated ticket status information in Copilot responses.

  Try this:

  • Review the query filter for existing ServiceNow Tickets connections.
  • Update the filter to include both active and inactive tickets if needed.
  • Communicate the change to your ServiceNow stakeholders and Copilot users.

  Why this matters:

  Business impact: Improves the quality of Copilot responses that reference ServiceNow tickets by keeping ticket status information current.

  Personal impact: Reduces confusion by showing more up-to-date ticket statuses in Copilot answers.

  Additional Resources:
  Learn:
  Manage indexed properties

  Query Miro boards and diagrams with Copilot connectors [Web]

  Connect Microsoft 365 Copilot to Miro with Copilot connectors so you can query visual boards and diagrams in Copilot.

  Roadmap ID:
  515166

  Details:

  What changed: Microsoft 365 Copilot now supports a Miro Copilot connector, which makes Miro boards discoverable and usable in Microsoft 365 Copilot and Microsoft Search.

  Why: This change helps people access Miro boards and visual planning work without leaving Microsoft 365.

  Try this:

  • Connect Microsoft 365 Copilot to Miro with a Copilot connector.
  • Ask Copilot to summarize the content of a Miro board for a project.
  • Ask Copilot to list action items on a Miro board.

  Why this matters:

  Business impact: Brings Miro board knowledge into Microsoft 365 Copilot so teams can find and use visual artifacts in the flow of work.

  Personal impact: Reduces time spent switching tools when you need context from a Miro board.

  Additional Resources:
  Learn:
  Deploy the Miro Microsoft 365 Copilot connector

  Connect Copilot to GitHub Server with Copilot Connector [Web]

  Connect Copilot to your GitHub Server to retrieve and collaborate on issues, pull requests, and knowledge base content.

  Details:

  What changed: The Copilot Connector enables a direct connection to GitHub Server. Users can bring issues, pull requests, and knowledge base content into Copilot to view and collaborate.

  Why: Centralizing software work items and documentation in Copilot saves time and reduces context switching during development and review activities.

  Try this:

  • Connect your GitHub Server and ask Copilot to list open issues for a repository.
  • Use Copilot to summarize a pull request and highlight reviewers’ comments.
  • Retrieve knowledge base articles to prepare a project briefing.

  Why this matters:

  Business impact: Speeds up review cycles and keeps development work aligned by consolidating information in one place.

  Personal impact: Makes it easier for individuals to find and act on relevant GitHub items.

  Original source Report a problem

  Show more
• Feb 6, 2026

  • Date parsed from source:
    Feb 6, 2026
  • First seen by Releasebot:
    Feb 7, 2026
  

  Playwright by Microsoft

  v1.58.2

  Highlights

  • #39121 fix(trace viewer): make paths via stdin work
  • #39129 fix: do not force swiftshader on chromium mac

  Browser Versions

  • Chromium 145.0.7632.6
  • Mozilla Firefox 146.0.1
  • WebKit 26.0

  Original source Report a problem
• Feb 5, 2026

  • Date parsed from source:
    Feb 5, 2026
  • First seen by Releasebot:
    Feb 7, 2026
  

  Microsoft Edge by Microsoft

  Version 144.0.3719.115: February 5, 2026

  Fixed various bugs, fixes and performance issues.

  Stable channel security updates are listed here.

  Fixes

  • Fixed a macOS issue that caused Microsoft Edge to fully saturate one CPU core under certain conditions.

  Original source Report a problem
• Feb 4, 2026

  • Date parsed from source:
    Feb 4, 2026
  • First seen by Releasebot:
    Feb 13, 2026
  

  Visual Studio Code by Microsoft

  January 2026 (version 1.109)

  VS Code January 2026 release expands multi‑agent capabilities with Claude compatibility, Plan and hooks, advanced agent sessions, Copilot memory and external indexing, terminal sandboxing, an integrated browser, plus performance and security boosts.

  Release date: February 4, 2026
  Update 1.109.1: The update addresses these security issues.
  Update 1.109.2: The update addresses these issues.
  Update 1.109.3: The update addresses these issues and introduces several notable features:
  • Message steering and queueing: send follow-up messages while a request is still running
  • Agent hooks: run custom shell commands at key agent lifecycle points
  • Claude compatibility: reuse your Claude configuration files directly in VS Code
  • Use skills as slash commands: invoke agent skills on demand from chat
  Downloads: Windows: x64 Arm64 | Mac: Universal Intel silicon | Linux: deb rpm tarball Arm snap
  Welcome to the January 2026 release of Visual Studio Code. In this release, we are further evolving VS Code to make it the home for multi-agent development.
  • Chat UX - chat just feels better and snappier with faster streaming, improved reasoning results, and a revamped editor inline chat
  • Agent Session Management - it's now easier to delegate tasks to agents across local, background, and cloud and jump in when needed
  • Agent Customization - build your own workflows using agent orchestrations, and have consistent results with Agent Skills and organization-wide customizations
  • Agent Extensibility - reuse your knowledge with Claude agent support and new Anthropic model capabilities, and enjoy rich chat interactions with MCP Apps
  • Agent Optimizations - agents work smarter with Copilot Memory and experience faster code search with external indexing
  • Agent Security & Trust - feel confident running terminal commands with sandboxing and effective auto-approval rules
  • Workbench & productivity - test your apps without leaving the editor with the new integrated browser
  • Terminal Enhancements - quality-of-life improvements to make your terminal experience smoother and more reliable
  • Coding & Editor - several impactful improvements to make everyday coding smoother
  • Extensions & API - new capabilities for extension authors to build richer experiences
  Happy Coding!
  Watch our VS Code 1.109 release highlights video to hear about these features!
  If you'd like to read these release notes online, go to Updates on code.visualstudio.com.
  Insiders: Want to try new features as soon as possible? You can download the nightly Insiders build and try the latest updates as soon as they are available.
  Upcoming events
  Agent Sessions Day
  Join us for Agent Sessions Day on Feb 19th to see these latest updates demoed live! Discover how VS Code has evolved into a unified agent UX, while staying true to its core values of openness, extensibility, and developer choice.
  Chat UX
  Faster responses, clearer reasoning, and less friction. This release brings streaming improvements that show progress as it happens, a revamped inline chat that stays out of your way, and better visibility into what the model is thinking, so you can stay in flow while the AI works.
  Message steering and queueing (Experimental)
  Setting: chat.requestQueuing.enabled, chat.requestQueuing.defaultAction
  Update 1.109.3: When working on longer tasks, you often think of the next task before the current or notice the agent heading in the wrong direction. Previously, you had to wait for a response to complete or cancel it entirely. Now you can send follow-up messages while a request is still running.
  While a request is in progress, the Send button changes to a dropdown with three options:
  • Add to Queue: your message waits and sends automatically after the current response completes.
  • Steer with Message: signals the current request to yield after finishing the active tool execution, then processes your new message immediately. Use this to redirect the agent when it's heading in the wrong direction.
  • Stop and Send: cancels the current request entirely and sends your new message immediately.
  When you have multiple pending messages, drag and drop them to change the order in which they are processed.
  Use chat.requestQueuing.defaultAction to set the default action of the Send button to steer (default) or queue.
  Learn more about message steering and queueing in the documentation.
  Anthropic models now show thinking tokens
  Settings: chat.thinking.style, chat.agent.thinking.collapsedTools, chat.agent.thinking.terminalTools, chat.tools.autoExpandFailures
  Many of you are using Anthropic's Claude models in VS Code. These models now support thinking tokens to give you more visibility into the model's reasoning process.
  In this release, we've enhanced the chat UX to surface thinking tokens more effectively. More information, less noise!
  • Choose between detailed or compact thinking styles to suit your preference (chat.thinking.style).
  • You'll see the model's thought process interleaved with tool calls and responses (chat.agent.thinking.terminalTools).
  • Failing tool calls automatically expand to show more context (chat.tools.autoExpandFailures).
  • Various visual enhancements to make following model activity more intuitive, like scrollable thinking content and shimmer animations.
  Mermaid diagrams in chat responses
  Chat responses can now render interactive Mermaid diagrams with the renderMermaidDiagram tool. This lets models use flowcharts, sequence diagrams, and other visualizations to visually break down complex concepts. The diagrams are interactive, so you can pan and zoom to explore them in detail, or open them in a full-sized editor for easier viewing.
  Interact with Mermaid diagrams using the following controls:
  • Pan and zoom - Hold Alt/Option and use the mouse wheel to zoom, or pinch to zoom on a trackpad. Hold Alt/Option and drag to pan around the diagram.
  • Click to zoom - Hold Alt/Option and click to zoom in. Add Shift to zoom out.
  • Open in editor - Use the button to open the diagram in a full-sized editor for better viewing of larger diagrams.
  • Copy source - Right-click on a diagram and select Copy diagram source to copy its Mermaid source code.
  Ask Questions tool (Experimental)
  Setting: chat.askQuestions.enabled
  Instead of making assumptions when something is unclear, the agent can now use the askQuestions tool to ask clarifying questions during chat conversations. It presents one or more questions directly in chat with single/multi-select options, free text input, and recommended answers highlighted for quick decisions.
  Use the keyboard to navigate between answers with Up and Down, or type the number that matches the corresponding answer (use Escape to skip remaining questions).
  We have revamped our Plan agent to also take advantage of the askQuestions tool to make sure your implementation plans align with your expectations and beyond!
  Plan agent
  The built-in Plan agent lets you create a structured implementation plan before starting to code. This helps ensure that the AI understands the task requirements and produces high-quality code that meets your expectations.
  • The Plan agent now follows a structured 4-phase iterative workflow that produces higher-quality implementation plans:
  • Discovery - Autonomously explores your codebase, searching for relevant files and understanding project structure.
  • Alignment - Pauses to ask clarifying questions before committing to a plan, catching ambiguities early.
  • Design - Drafts a comprehensive implementation plan with clear steps, file locations, and code snippets.
  • Refinement - Adds verification criteria and documents decisions made during planning.
  • You can now invoke the Plan agent by typing /plan in chat, followed by your task description. This provides a quick entry point for planning complex tasks before switching to implementation.
  Context window details
  To keep track of how the model is using its context window, you can now see a context window indicator in the chat input area. Hover over the indicator to see a breakdown of token usage by category.
  Inline chat UX revamp (Preview)
  Settings: inlineChat.affordance, inlineChat.renderMode
  We continue to revamp the inline chat experience and have two preview features:
  • An affordance that makes it easier to trigger inline chat when selecting text (inlineChat.affordance)
  • A lightweight and easier-to-use contextual rendering (inlineChat.renderMode)
  Model descriptions in the model picker
  On hover or keyboard focus of a model in the model picker, you can now see its details at a glance.
  Terminal command output
  Richer command details
  To make it clearer what command is being run, the terminal tool now shows additional details:
  • Syntax highlighting for inline Node, Python, and Ruby
  • Working directory
  • Description of the command's intent
  Output streaming
  Terminal output now automatically expands when a command takes time to execute, giving you immediate visibility into what's happening. Quick commands stay collapsed to reduce visual noise.
  Interactive input
  Embedded terminals are now fully interactive. You can focus the terminal and type directly, which is useful when a command prompts for confirmation or requires user input. The cursor is now visible, making it clear when a terminal is ready for input.
  Delete all hidden terminals
  The Hidden Terminals item in the terminal panel now includes a delete icon to clear all hidden terminals with one action.
  Tell us what you think about our new themes (Experimental)
  We are developing new experimental VS Code Light and VS Code Dark themes to increase focus and bring a sense of elevation and lightness to the UI, through the use of shadows and transparency. These themes are a work-in-progress.
  Let us know what works and where we can improve by giving feedback in the vscode repository.
  VS Code Dark (Experimental):
  VS Code Light (Experimental):
  Agent Session Management
  Delegate, monitor, and switch without losing focus. You can now run multiple agent sessions in parallel across local, background, and cloud environments, all from a single unified view. Jump between sessions, track progress at a glance, and let agents work independently while you stay productive.
  Switching and delegating between agent types
  VS Code makes it easy to start agent sessions across different environments: locally in VS Code, in the background, in the cloud, or with other agent providers. We've made it easier to switch between these different agent types by introducing a new session type picker in the chat input area.
  The picker serves two main purposes:
  • Choose the type of agent session you want to start
  • Hand off an ongoing session to a different agent type (for example, plan a task locally and implement in the cloud)
  Tip: We've added a new workbench.action.chat.newLocalChat command for creating a new local chat session. Bind this command to a keyboard shortcut for even faster access.
  Keeping track of agent sessions
  Keeping track of your active agent sessions is essential when working with multiple agents, especially when you have multiple parallel session across different environments.
  Agent Sessions view
  We've further improved the Agent Sessions view in VS Code to make this task easier:
  • Resize the sessions list when showing side-by-side
  • Multi-select sessions to perform operations in bulk
  • Better stacked view to improve navigating sessions and applying filters
  Agent status indicator
  Settings: chat.agentsControl.enabled, chat.agentsControl.clickBehavior
  In situations where you have multiple active sessions, it's important to quickly see which sessions need your attention. We added an agent status indicator (chat.agentsControl.enabled) in the VS Code command center to provide visibility into agent session updates.
  The indicator shows different types of status information: in-progress, unread, and sessions that need your attention. Select the indicator to quickly open and filter the sessions list.
  We have also updated the chat button in the command center to let you configure its behavior when clicked (chat.agentsControl.clickBehavior). By default, it now cycles through the different Chat view states: sidebar, maximized, or hidden.
  Subagents
  Setting: chat.customAgentInSubagent.enabled
  Agents can run subtasks using subagents to break down complex tasks into smaller parts. The nice thing about subagents is that they operate in their own dedicated context window and don't add up to the main agent's context window.
  Subagents can now run in parallel, which can significantly speed up tasks that can be split into independent tasks.
  To provide more visibility into what the different subagents are doing, the chat conversation now shows details such as what tasks it's doing, the custom agent used for the subagent, and whichever tool is currently used. You can expand the subagent information to show the full details of what it's doing, including the full initial prompt it was provided with and the result it returned.
  Search subagent (Experimental)
  Setting: github.copilot.chat.searchSubagent.enabled
  Searching your codebase is typically a task that can involve multiple iterations and which can quickly add up to your context window limit. We added support for a search subagent that runs in an isolated agent loop, enabling it to iteratively refine searches, try multiple queries, and explore different parts of your workspace.
  This improves the quality of search results for complex queries where a single search isn't sufficient. It also preserves the main agent's context window and enables it to continue working while the search subagent does its job.
  Cloud agents
  When you start a new cloud agent session, you now have more options to configure your session. Choose from different models, use one of your custom agents, or select from available partner agents (where available).
  • Model selection for cloud agents
  • Third-party coding agents (Preview)
  If you have third-party coding agents, such as Claude and Codex, configured as part of your GitHub Copilot subscription, VS Code will show these options after selecting the cloud agent type.
  Learn more about availability and enabling of third-party coding agents in the GitHub Changelog.
  • Custom agents for cloud agents
  Choose from custom Agents available in your target GitHub repository default branch.
  • Multi-root workspace and empty workspace improvements
  When in a multi-root workspace window or empty workspace window, you can now select the folder to be used for the cloud agents.
  • Checkout always shows
  The Checkout option for agent sessions now shows even when the GitHub Pull Requests extension is not installed. When you select this action, it installs GitHub Pull Requests if needed, and then hands off to it to perform the checkout.
  Background agents
  Aligning with local and cloud agents, we have added several improvements to background agents:
  • Custom agents for background agents
  • Attach images as context
  • Multi-root workspace improvements
  When in a multi-root workspace, you can now select the folder to be used in background agents.
  • Auto-commit at the end of each turn
  We have updated the background agent loop to commit the changes to the Git worktree at the end of each turn. This enabled us to remove the Keep/Undo actions for background sessions and simplify how changed files are shown in the working set.
  Agent sessions welcome page (Experimental)
  Setting: workbench.startupEditor
  Last but not least, we're experimenting with a new welcome page and need your help to make it great. When you have multiple agents working in parallel, keeping track of recent sessions matters. The new welcome page surfaces your agent sessions front and center.
  Enable the welcome page as your startup editor by setting workbench.startupEditor to agentSessionsWelcomePage. Let us know what you think and send us feedback in the vscode repository!
  Agent Customization
  Shape how AI works with your codebase and share it across your team. Agent Skills now let you package domain expertise into reusable workflows, organization-wide instructions ensure consistency, and new controls give you fine-grained control over how and when agents get invoked.
  Agent hooks (Preview)
  Setting: chat.hooks.enabled
  Update 1.109.3: Hooks let you execute custom shell commands at key lifecycle points during agent sessions. Unlike instructions or custom prompts that guide agent behavior, hooks run your code deterministically with guaranteed outcomes. Use them to enforce security policies, automate code quality checks, create audit trails, or inject project-specific context.
  VS Code supports eight hook events that fire at specific points during a session, including PreToolUse and PostToolUse for intercepting tool calls, SessionStart and Stop for session lifecycle, and SubagentStart and SubagentStop for tracking nested agent usage.
  VS Code uses the same hook format as Claude Code and Copilot CLI, so you can reuse existing hook configurations across tools.
  To get started, use the /hooks slash command in chat to configure a new hook, or create a hook file manually. For example, you can create a PreToolUse hook that runs a linter after every file edit, or block dangerous terminal commands before they execute.
  Learn more about agent hooks in the documentation.
  Use skills as slash commands
  Agent Skills are now available as slash commands in chat, alongside prompt files. Type / in the chat input to see all available skills and prompts, and select a skill to invoke it immediately. You can add extra context after the command, for example /webapp-testing for the login page or /github-actions-debugging PR #42.
  By default, all skills appear in the / menu. Use the user-invokable and disable-model-invocation frontmatter properties in your skill files to control how each skill is accessed:
  • Set user-invokable: false to hide a skill from the menu while still letting the model load it automatically.
  • Set disable-model-invocation: true to show the skill in the menu but prevent the model from loading it on its own.
  Learn more about using skills as slash commands in the documentation.
  Set up your workspace for AI with /init
  With always-on custom instructions like copilot-instructions.md or AGENTS.md, you can ensure that the AI uses your project's conventions for generating code.
  To prime your project with an initial set of instructions based on your codebase, you can now use the /init slash command in chat to generate or update your workspace instructions.
  When you run /init, the agent discovers existing AI conventions in your workspace (such as copilot-instructions.md or AGENTS.md), analyzes your project structure and coding patterns, and generates comprehensive workspace instructions tailored to your project. The /init command is implemented as a contributed prompt file, so you can customize its behavior by modifying the underlying prompt.
  Agent Skills are generally available
  Settings: chat.useAgentSkills, chat.agentSkillsLocations
  Agent Skills are now generally available and enabled by default. Skills provide specialized capabilities, domain knowledge, and refined workflows to help the AI produce high-quality outputs. Each skill folder contains tested instructions for specific domains like testing strategies, API design, or performance optimization.
  You can now manage skills in VS Code in the same way you manage prompt files, instructions, or custom agents. Use the Chat: Configure Skills command to view all available skills, or Chat: New Skill File to create a new skill in your workspace or user home.
  By default, VS Code looks for skills definitions in the .github/skills and .claude/skills folder of your workspace, or in the ~/.copilot/skills or ~/.claude/skills folder in your user home. You can specify custom paths where VS Code should look for skills by using the chat.agentSkillsLocations setting.
  If you're an extension author, you can also package and distribute skills with your extension by including them in the extension and registering them using the chatSkills contribution point in the package.json.
  Organization-wide instructions
  Setting: github.copilot.chat.organizationInstructions.enabled
  Previously, VS Code already added support for organization-level custom agents. In this release, VS Code now also supports organization-level custom instructions. If your GitHub organization has configured custom instructions for Copilot, they are automatically applied to your chat sessions, ensuring consistent guidance across your team.
  This feature is enabled by default. You can disable organization instructions by setting github.copilot.chat.organizationInstructions.enabled to false.
  Learn more about Custom Instructions in the documentation.
  Custom agent file locations
  Setting: chat.agentFilesLocations
  Like for other customization files, such as prompt files, instructions, and skills, you can now configure where VS Code looks for custom agent definitions (.agent.md).
  By default, VS Code searches for agent files in your workspace's .github/agents folder. With the new chat.agentFilesLocations setting, you can add additional directories to search, making it easier to organize and share agents across projects or keep them in a central location outside your workspace.
  Control how custom agents are invoked
  Settings: chat.customAgentInSubagent.enabled
  Custom agents now support additional attributes in the frontmatter header that give you more control over how agents can be invoked. This is particularly useful for setting up agent orchestrations to handle complex tasks with confidence.
  • user-invokable: controls whether the agent can be selected from the agents dropdown in chat. Set to false to create agents that are only accessible programmatically or as subagents.
  • disable-model-invocation: prevents the agent from being invoked as a subagent by other agents when enabled. This is useful for agents that should only be triggered explicitly by users.
  • agents: limits which subagents the current agent can invoke. When specified, the agent can only hand off work to the listed agents. Use the agent tool to enable subagent invocation.
  The use of custom agents as subagents is currently still behind a setting. Enable chat.customAgentInSubagent.enabled to enable custom agents as subagents.
  Multiple model support for custom agents
  Custom agents can now specify more than one model in the frontmatter header. The first available model in the list is used, providing fallback options if a preferred model is unavailable.
  Chat customization diagnostics
  Chat customization files can originate from various locations, including your user profile, workspace, extensions, and your GitHub organization. When troubleshooting issues with custom agents, prompts, instructions, or skills, it can be challenging to determine which files are currently loaded and whether any errors occurred during loading.
  A new diagnostics view helps you troubleshoot chat customization issues by showing all currently loaded custom agents, prompt files, instruction files, and skills. To access it, right-click in the Chat view and select Diagnostics. This opens a Markdown document listing all active customization files, their load status, and any errors that occurred during loading.
  Language Models editor
  The Language Models editor in VS Code provides a centralized interface for managing and configuring language models used in chat. This iteration, we further enhanced this experience:
  • Multiple configurations per provider: create multiple configurations for the same model provider, each with a different API key. This is useful for separating personal and work accounts, or using different API keys for different projects. For example, you might have one Gemini configuration with your personal API key and another with your team's API key.
  • Configuring models from Azure provider: when configuring Azure models, VS Code opens the chatLanguageModels.json configuration file and inserts a snippet template. This snippet includes the required properties such as model ID, name, endpoint URL, and token limits. You can then fill in the values for each model you want to add.
  • Manage provider groups: configure an existing provider group by selecting the configure action, for example to update the API key. You can also remove a provider group entirely by using the remove action.
  • Additional UI improvements: several usability improvements, such as keyboard access for toggling model visibility, context menu actions, and multi-select for bulk actions.
  • Language-model configuration file: model configurations are now stored in a dedicated chatLanguageModels.json file. Open this file directly by selecting the file icon in the top-right corner of the Language Models editor. This makes it easy to view, edit, or share your model configurations.
  • Model provider configuration UI: model providers can declare their configuration schema, and VS Code provides the UI for users to enter their configuration. See Chat Model Provider Configuration for details on this new proposed API. Existing model configurations from the GitHub Copilot Chat extension are automatically migrated.
  Language model configuration
  Settings: github.copilot.chat.implementAgent.model, inlineChat.defaultModel
  • Default model for plan implementation (Experimental): You can now configure a default language model for the implementation step of the Plan agent (github.copilot.chat.implementAgent.model). Leave the setting empty to use the default model. The model value should be a qualified model name in the format Model Name (vendor), for example GPT-5 (copilot) or Claude Sonnet 4.5 (copilot).
  • Default model for inline chat: By default, editor inline chat uses the default model of the selected vendor. This enables extensions to provide a model that's specifically tailored for inline chat scenarios. If you prefer to use a different model, you can configure this with the inlineChat.defaultModel setting. This setting lets you choose a consistent default language model for inline chat, so your preferred model is used automatically whenever you start an inline chat session, without needing to select it manually each time.
  • Specify language model for agent handoffs: Agent handoffs now support an optional model parameter that lets you specify which language model to use when the handoff executes. This enables you to control the model that is used for specific agent workflows directly from your .agent.md file. The model value should be a qualified model name in the format Model Name (vendor), for example GPT-5 (copilot) or Claude Sonnet 4.5 (copilot).
  Agent customization skill (Experimental)
  Setting: chat.agentCustomizationSkill.enabled
  A new agent-customization skill teaches the agent how to help you customize your AI coding experience. When you ask about creating custom agents, instructions, prompts, or skills, the agent automatically loads this skill to provide accurate guidance.
  The skill covers:
  • Custom Agents - Creating .agent.md files with frontmatter configuration for tools, models, and behavior
  • Custom Instructions - Writing .instructions.md files with applyTo patterns for context-specific guidance
  • Prompt Files - Building reusable .prompt.md templates for common tasks
  • Skills - Packaging domain expertise in SKILL.md files
  • Workspace Instructions - Setting up project-wide conventions in copilot-instructions.md and AGENTS.md
  Agent Extensibility
  This release adds Claude Agent support so you can leverage Anthropic's agent SDK directly, MCP Apps that render interactive visualizations in chat, and new provider capabilities are giving you more ways to extend what agents can do.
  Claude compatibility
  If you use both VS Code and Claude, you no longer need to maintain separate configuration files. VS Code now reads Claude configuration files directly, so your agents, skills, instructions, and hooks work across both tools without duplication.
  VS Code detects the following Claude file locations:
  • Instructions: CLAUDE.md files in your workspace root, .claude/CLAUDE.md, and ~/.claude/CLAUDE.md. VS Code also reads instruction files from the .claude/rules folder.
  • Agents: .md files in the .claude/agents folder, following the Claude sub-agents format.
  • Skills: Skill definitions in .claude/skills and ~/.claude/skills folders.
  • Hooks: Hook configurations in .claude/settings.json and ~/.claude/settings.json.
  This compatibility extends across instructions, agents, skills, and hooks so that teams using multiple AI tools can share a single set of configuration files.
  Agent orchestration
  Agent orchestration is a powerful pattern for building complex AI workflows where multiple specialized agents collaborate to achieve a common goal. Instead of relying on a single agent to handle everything, orchestration distributes work across purpose-built agents, each optimized for a specific role like planning, implementation, code review, or research.
  This approach provides several key benefits:
  • Context efficiency: Each subagent operates in its own dedicated context window, preventing context overflow
  • Specialization: Different agents can use different models optimized for their task
  • Parallel execution: Independent tasks can run in parallel across multiple subagents
  VS Code has all the building blocks for setting up your agent orchestration flow with custom agents, subagents, and extra control over how agents are invoked.
  The community has created excellent examples of agent orchestration systems that you can use directly or adapt to your needs:
  • Copilot Orchestra - A multi-agent system with a "Conductor" that orchestrates planning, implementation, and code review subagents through a complete development cycle
  • GitHub Copilot Atlas - An extended orchestration system with specialized agents like "Prometheus" for planning, "Oracle" for research, "Sisyphus" for implementation, and "Explorer" for rapid codebase discovery
  Claude Agent (Preview)
  This release, we are introducing Claude Agent support, now in preview. This gives you the power to delegate tasks to the Claude Agent SDK using the Claude models included in your GitHub Copilot subscription.
  This integration uses the official Claude Agent harness by Anthropic, which means it shares the same prompts, tools, and overall architecture as other Claude Agent implementations. You can learn more about the Claude Agent SDK in the Anthropic documentation.
  This integration is in active development and we plan to add more features and improvements over the coming months. In the meantime, we would love to hear your feedback on how you are using Claude Agents in VS Code and what features you would like to see next. Don't hesitate to provide feedback on GitHub!
  Anthropic models
  Settings: github.copilot.chat.anthropic.thinking.budgetTokens, github.copilot.chat.anthropic.toolSearchTool.enabled, github.copilot.chat.anthropic.contextEditing.enabled
  We've made several improvements to Anthropic model support in VS Code:
  • Messages API with interleaved thinking: Anthropic models now use the Messages API, which includes support for interleaved thinking. This enables Claude to reason between tool calls, providing more thoughtful and contextual responses during complex multi-step tasks. Configure the thinking budget with the github.copilot.chat.anthropic.thinking.budgetTokens setting, or set it to 0 to disable extended thinking entirely.
  • Tool search tool: We enabled the tool search tool to help Claude discover and select the most relevant tools for your task from a larger pool of available tools. This feature can be toggled with the github.copilot.chat.anthropic.toolSearchTool.enabled setting.
  • Context editing (Experimental): We added support for context editing to help manage longer conversations more efficiently. This feature clears tool results and thinking tokens from previous turns, helping to defer summarization and maintain more context in chat sessions. Try it out by enabling the github.copilot.chat.anthropic.contextEditing.enabled setting.
  Support for MCP Apps
  In this release VS Code has added support for MCP Apps. MCP Apps allow servers to display rich, interactive UI in the client.
  Apps are displayed automatically when servers return them. If you're an MCP server developer you can learn more about MCP Apps by checking out:
  • MCP Apps demo repository
  • MCP Apps SDK and examples
  • VS Code MCP documentation
  • MCP server development guide
  Support for custom registry base URLs for MCP packages
  VS Code now supports the registryBaseUrl property in MCP server manifest files. This enables organizations to deploy MCP servers from private or alternative package registries, such as internal Azure DevOps feeds or custom PyPI repositories.
  Agent Optimizations
  Smarter context, faster search, better results. With Copilot Memory, agents remember what matters across sessions. External indexing brings fast semantic search to non-GitHub workspaces. And agents can now read files outside your workspace when needed, with your permission.
  Copilot Memory (Preview)
  Setting: github.copilot.chat.copilotMemory.enabled
  If you find yourself repeatedly providing the same context to the AI, you can now use Copilot Memory to store and recall important information across sessions.
  With the new memory tool, your chat can now access and update Copilot Memory directly. This enables the agent to retrieve relevant context from your stored memories and save new learnings as you work. Enable the memory tool by setting github.copilot.chat.copilotMemory.enabled to true.
  The memory tool should recognize when to store a particular piece of information as a memory ("always ask clarifying questions when in doubt") and when to retrieve relevant memories to inform its responses.
  You can view and manage all your memories from GitHub's Copilot settings.
  External indexing for non-GitHub workspaces (Preview)
  Setting: github.copilot.chat.advanced.workspace.codeSearchExternalIngest.enabled
  Workspaces that are not hosted on GitHub can now be remotely indexed for faster code search when using agents. When you use #codebase in a non-GitHub workspace, VS Code builds an index of your codebase that enables quick semantic search, providing the same powerful code search capabilities that are available for GitHub-hosted repositories.
  The index is built on the first request and might take a few minutes depending on the repository size and your network connection. Subsequent requests are much faster, as they use the cached index. The index automatically updates when you modify and save files.
  We'll be rolling out external indexing gradually over the next few weeks. Note that any workspaces that are hosted on GitHub already support remote indexing and do not require a more expensive call to build up the index on first request.
  Read files outside workspace
  Agents can now read files and list directories outside your current workspace with your permission. Previously, access attempts were automatically denied. Now, when an agent needs to access external files or folders, VS Code prompts you to allow or deny the request.
  You can also allow access for the entire session to avoid repeated prompts for future reads under the same folder.
  Performance improvements
  This iteration, we've made numerous performance improvements:
  • Large chats: Long chat conversations should now feel smoother to open and scroll around in. We've also optimized how conversations are persisted to make them more reliable overall.
  • Parallel dependent tasks: When running tasks via agents, dependent tasks are now processed in parallel instead of sequentially. This can significantly improve build times for projects with multiple independent build steps. Check our microsoft/vscode repo to notice the difference!
  Agent Security and Trust
  Run agent commands with confidence. New terminal sandboxing restricts file and network access for agent-executed commands, auto-approval rules skip confirmation for safe operations, and improved presentation shows exactly what's running and why, so you're always in control.
  Terminal sandboxing (Experimental)
  Settings: chat.tools.terminal.sandbox.enabled, chat.tools.terminal.sandbox.linuxFileSystem, chat.tools.terminal.sandbox.macFileSystem, chat.tools.terminal.sandbox.network
  Agents have the same permissions as your user account. To help mitigate risks associated with terminal commands executed by agents, we have introduced experimental terminal sandboxing capabilities. Terminal sandboxing restricts file system access to only your workspace folder and also lets you restrict network access to trusted domains only.
  Note: terminal sandboxing is currently supported on macOS and Linux only. On Windows, the sandbox settings have no effect.
  To enable terminal sandboxing, set the chat.tools.terminal.sandbox.enabled setting to true.
  When sandboxing is enabled:
  • Commands have read and write access to the current working directory by default
  • Commands run without the standard confirmation dialog because they operate in a controlled environment
  • Network access is blocked for all domains by default
  Learn more about configuring terminal sandboxing in our documentation.
  Terminal tool lifecycle improvements
  Several changes were made in this release to help solve problems around incorrect background terminal behavior:
  • You can now manually push a terminal tool call to the background, freeing up the agent to continue with other work.
  • A new timeout property is required to be filled in by the agent when a call to the terminal tool is made, where 0 means no timeout. This gives an extra escape to return control back to the agent when something unexpected happens.
  • The new awaitTerminal tool gives the agent the ability to wait for background terminals to complete, this also requires the timeout property. Provided the model leverages this tool, the expectation is that it prevents echo "successful" and sleep n calls that were previously used to wait for background commands to finish.
  • The new killTerminal tool gives the agent the ability to kill background terminals to clean up after itself. This aims to prevent how the agent would sometimes kill processes to achieve the same thing in a roundabout way, for example when it wants to stop an old in-progress server command.
  • Several instruction changes around how the current working directory works since the active non-background terminal always persists the current working directory, whereas background terminals always start in the workspace directory.
  Terminal auto-approval
  Settings: chat.tools.terminal.enableAutoApprove
  The following commands are now auto approved by default when terminal auto approve is enabled (chat.tools.terminal.enableAutoApprove):
  • Set-Location
  • dir
  • od
  • xxd - flags and a single input file
  • docker - All safe sub-commands
  • npm, yarn, pnpm - All safe sub-commands
  Terminal enhancements
  A smoother, more capable terminal. Terminal commands in chat now show richer details including syntax highlighting and working directory. Kitty keyboard protocol support improves key handling in terminal apps, and new options let you customize sticky scroll and use terminals in restricted workspaces.
  Selectively ignore sticky scroll
  Setting: terminal.integrated.stickyScroll.ignoredCommands
  Some commands previously appeared in sticky scroll when that behavior was undesirable, for example commands like clear. From this release, you can customize which commands are ignored, and it already includes some common agentic CLIs (that run in the normal buffer) such as copilot, claude, codex, and gemini.
  Removal of winpty support
  Support for winpty has been removed from node-pty, which means terminals will no longer work in Windows versions before Windows 10 version 1809 (Fall 2018). ConPTY is the modern mechanism for terminals so we recommend upgrading to a newer version of Windows 10 or move to Windows 11. You may be able to get terminals to work by setting "terminal.integrated.windowsUseConptyDll": true, but note that this is currently experimental.
  Allow terminals to be opened in restricted workspaces
  Setting: terminal.integrated.allowInUntrustedWorkspace
  When workspace trust is not granted, opening the terminal is blocked to protect the user from attacks where the shell may execute code such as by setting variables via an .env file. Security conscious users often configure their shells to prevent this from being a possibility, so there is a new opt-in setting that allows opening terminals in restricted workspaces.
  New VT features
  Setting: terminal.integrated.enableKittyKeyboardProtocol (Experimental)
  The Kitty keyboard protocol has been implemented and will be rolling out to stable this release. This feature aims to fix a bunch of limitations around how keystrokes are traditionally encoded, specifically:
  • Allows the terminal to encode more modifiers and multiple modifiers, not just alt and ctrl
  • Handle both press and release events as well as repeated pressed (holding a key down)
  • Disambiguates many keystrokes, such as Escape which normally sends the ESC (\x1b) sequence which also happens to be the start of all escape sequences.
  This requires the program running in the terminal to support the protocol and request to enable it when it runs. A big benefit you will see immediately is shift+enter should work in some agentic CLIs without the need to run something like /terminalSetup.
  Setting: terminal.integrated.enableWin32InputMode (Experimental)
  Similar to the above, there's an experimental version of the win32 input mode which accomplishes similar but is tuned specifically for Windows and its pseudoterminal backend ConPTY. This will remain off for this release, let us know if you have any problems with it.
  Other:
  • Independent control of bold and faint SGR properties (SGR 222, SGR 221). This sequence is rarely used, but it's unambiguous and can corrupt output when used, so we decided to support it.
  Coding and editor
  Small refinements that add up. Double-click to select bracket or string contents. Customize bracket matching colors. Scope snippets to specific files. Detect TypeScript shebangs correctly. These focused improvements make everyday editing just a bit smoother.
  Bracket matching foreground color
  You can now customize the text color of matching brackets using the new editorBracketMatch.foreground color theme token. Previously, you could only customize the background (editorBracketMatch.background) and border (editorBracketMatch.border) colors. The new color token lets you make matching brackets stand out more clearly by changing the actual bracket characters' color.
  The setting defaults to null, meaning brackets inherit their normal text color. Configure it in your settings.json under workbench.colorCustomizations:
  {
  "workbench.colorCustomizations": {
  "editorBracketMatch.foreground": "#ff0000"
  }
  }
  Select bracket and string content with double-click
  You can now double-click immediately after an opening bracket or immediately before a closing bracket to select all the content inside. This also works for strings - double-click right after an opening quote or right before a closing quote to select the string contents. This provides a quick way to select, copy, or replace the content within brackets or strings without manually positioning your cursor.
  Rename suggestions for TypeScript
  Rename suggestions for TypeScript now also work when typing over an existing declaration. In the following video the user changes the declaration let index = 0; into let chunkIndex = 0; by typing the new identifier name instead of using the rename refactoring. Next edit suggestions still proposes to rename index to chunkIndex using Shift+Tab.
  Note: this feature is only available for TypeScript for now.
  Improved ghost text visibility
  Inline suggestions (ghost text) now display a dotted underline when showing short suggestions of fewer than three continuous non-whitespace characters. This visual indicator makes it easier to distinguish ghost text from actual code in your editor. This is particularly useful when the suggestion is a single character like ) that might be confused with existing code.
  Snippet file patterns
  You can now control which files a snippet appears in using include and exclude glob patterns. Use this to restrict snippets to specific files or project contexts, preventing them from appearing in unrelated files.
  For example, to create a snippet that only appears in Travis CI configuration files:
  {
  "Travis CI node_js": {
  "include": ".travis.yml",
  "prefix": "node",
  "body": [
  "language: node_js",
  "node_js:",
  " - $1"
  ],
  "description": "Node.js configuration for Travis CI"
  }
  }
  Patterns match the absolute file path if they contain a path separator, otherwise they match just the file name. Both include and exclude can be a single pattern or an array of patterns. Use exclude to prevent snippets from appearing in specific files, even when they would otherwise match the snippet's language scope.
  Improved shebang language detection
  VS Code now has improved shebang language detection support, particularly for files using /usr/bin/env with additional flags. Files with shebangs like #!/usr/bin/env -S deno -A are now correctly detected as TypeScript. This enables better language support for scripts written in TypeScript using runtimes like Deno or Bun, even without a .ts file extension.
  Workbench and productivity
  Test, debug, and ship without switching windows. A new integrated browser lets you preview and inspect localhost sites directly in VS Code, complete with DevTools and authentication support.
  Integrated browser (Preview)
  Settings: workbench.browser.openLocalhostLinks, simpleBrowser.useIntegratedBrowser, livePreview.useIntegratedBrowser
  VS Code has long included the Simple Browser for opening basic web pages, such as localhost sites during development. However, because it relied on iframes, there were several limitations: website authentication wasn't possible, and common sites like Google, GitHub, and Stack Overflow couldn't be opened.
  This release introduces a new integrated browser for VS Code desktop that overcomes these restrictions. You can now sign into websites and browse any page, just as you would in a regular browser.
  Highlights include:
  • Persistent data storage with configurable scope (global, workspace, or in-memory / ephemeral)
  • Add element to chat: select an element and send it to an agent for assistance
  • Fully-featured DevTools
  • Keyboard shortcuts
  • Find in page
  And more...
  To try it out, run the Browser: Open Integrated Browser command. If you'd like to use the integrated browser more broadly, you can enable workbench.browser.openLocalhostLinks to open localhost links directly in the new browser.
  You can also configure the integrated browser to replace the Simple Browser with the simpleBrowser.useIntegratedBrowser setting, or to be used by the Live Preview extension using the livePreview.useIntegratedBrowser setting.
  Restore editors on workspace open
  Setting: workbench.editor.restoreEditors
  Previously, VS Code would always restore all open editors when reopening a workspace. With the new workbench.editor.restoreEditors setting, you can control whether editors should restore when opening a workspace or not. When the setting is disabled, VS Code starts with a clean editor area instead of reopening the tabs from your previous session.
  Note: Dirty (unsaved) editors always restore regardless of this setting to prevent data loss.
  Advanced settings
  Setting: workbench.settings.alwaysShowAdvancedSettings
  You can now configure VS Code to always show advanced settings in the Settings editor without having to apply the @tag:advanced filter each time. Enable the workbench.settings.alwaysShowAdvancedSettings setting to have advanced settings visible by default.
  Import profiles via drag and drop
  You can now import a settings profile by dragging and dropping a .code-profile file onto the VS Code window. This provides a similar experience to dragging and dropping a .code-workspace file, making it easier to share and apply profiles.
  Output channel filter improvements
  The Output panel filter now supports negative patterns and multiple filters. Use ! to exclude specific lines from the output, for example !debug hides all lines containing "debug". You can also combine multiple patterns with commas for more precise filtering.
  Filter problems by source
  The Problems panel now supports filtering by the source or owner of diagnostics. This is useful when you want to focus on specific types of issues, such as build errors, while temporarily hiding diagnostics from other sources like spell checkers or linters. For example, type source:ts in the filter box to show only TypeScript diagnostics, or use !source:cSpell to hide all spell checker warnings.
  Extension editor shows configuration defaults
  The Feature Contributions tab in the extension editor now displays configuration defaults contributed by extensions. This makes it easier to see what default settings an extension provides, such as language-specific editor configurations.
  Include additional files in git worktrees (Experimental)
  Setting: git.worktreeIncludeFiles
  When using background agents, a git worktree is created in order to isolate the changes. With the new git.worktreeIncludeFiles setting, you can specify additional files or glob patterns that are copied to the worktree folder after the worktree is created. This is useful when your project depends on files that are git ignored and are not part of the git repository (ex: local configuration files or build artifacts).
  Collapse All action in SCM view
  When viewing files as trees in the Changes section of the Source Control view, you can now use the Collapse All action in the context menu of a root node to collapse all expanded directory structures at once, making it easier to navigate large sets of changes.
  Git: Delete command
  A new Git: Delete command lets you run git rm on the currently open file directly from the Command Palette. This removes the file from both the working directory and the Git index, then closes the editor. This provides a safer alternative to regular file deleti

  Original source Report a problem

  Show more
• Feb 4, 2026

  • Date parsed from source:
    Feb 4, 2026
  • First seen by Releasebot:
    Feb 4, 2026
  • Modified by Releasebot:
    Feb 11, 2026
  

  Visual Studio Code by Microsoft

  January 2026 (version 1.109)

  VS Code’s January 2026 release unleashes multi‑agent development with faster chat, session management, customization, extensibility, and security. It adds an integrated browser, terminal sandboxing, and richer extension APIs for a smarter, more productive coding workspace.

  January 2026 release

  Welcome to the January 2026 release of Visual Studio Code. In this release, we are further evolving VS Code to make it the home for multi-agent development.

  • Chat UX - chat just feels better and snappier with faster streaming, improved reasoning results, and a revamped editor inline chat
  • Agent Session Management - it's now easier to delegate tasks to agents across local, background, and cloud and jump in when needed
  • Agent Customization - build your own workflows using agent orchestrations, and have consistent results with Agent Skills and organization-wide customizations
  • Agent Extensibility - reuse your knowledge with Claude agent support and new Anthropic model capabilities, and enjoy rich chat interactions with MCP Apps
  • Agent Optimizations - agents work smarter with Copilot Memory and experience faster code search with external indexing
  • Agent Security & Trust - feel confident running terminal commands with sandboxing and effective auto-approval rules
  • Workbench & productivity - test your apps without leaving the editor with the new integrated browser
  • Terminal Enhancements - quality-of-life improvements to make your terminal experience smoother and more reliable
  • Coding & Editor - several impactful improvements to make everyday coding smoother
  • Extensions & API - new capabilities for extension authors to build richer experiences

  Happy Coding!

  [The release notes continue with detailed descriptions of features such as Chat UX improvements, Anthropic model enhancements, Mermaid diagrams in chat, Ask Questions tool, Plan agent improvements, Agent Session Management, Agent Customization, Agent Extensibility including Claude Agent support, Agent Optimizations like Copilot Memory and external indexing, Agent Security and Trust with terminal sandboxing, Terminal enhancements, Coding and editor improvements, Workbench and productivity features including an integrated browser, Extensions and API updates, Engineering improvements, Notable fixes, and acknowledgments.]

  For full details, please refer to the official release notes on the Visual Studio Code website.

  Original source Report a problem

  Show more
• Feb 3, 2026

  • Date parsed from source:
    Feb 3, 2026
  • First seen by Releasebot:
    Feb 4, 2026
  

  Microsoft 365 by Microsoft

  Version 2601: February 03

  Version 2601 (Build 19628.20166)

  • Various fixes to functionality and performance.

  Original source Report a problem
• Jan 30, 2026

  • Date parsed from source:
    Jan 30, 2026
  • First seen by Releasebot:
    Jan 30, 2026
  

  Playwright by Microsoft

  v1.58.1

  Highlights

  • #39036 fix(msedge): fix local network permissions
  • #39037 chore: update cft download location
  • #38995 chore(webkit): disable frame sessions on fronzen builds

  Browser Versions

  • Chromium 145.0.7632.6
  • Mozilla Firefox 146.0.1
  • WebKit 26.0

  Original source Report a problem