Benjamin Christopher SimmondsandCopilot
be2aeccba1
* agentHost: make startup session discovery registry-first (#331155) A 2026-08-17 Insiders reproduction with 941 SDK sessions and 1,437 per-session databases (~946 MB) showed the ~60s delay is not migration — `sessionRegistryBackfilled:copilotcli` was already true and migration was skipped. The time went to per-session SQLite work during discovery and listing: classification took 66.9s (113 external, 342 adoptable extension-host, 486 already known), registration of the 113 emitted candidates another 21.9s, and the first two AHP `listSessions` calls 109.8s and 91.0s, with a third 73.2s window after discovery. Each measured phase is addressed: - Classification (66.9s): discovery is now registry-first. `IAgent` gains an optional `setKnownSessionsFilter` seam that `AgentService` installs at provider registration; it answers, in one registry query for the whole candidate set, which sessions the host already owns. `CopilotAgent` drops those candidates instead of opening a session database each, so the 486 already-known sessions cost no DB opens. Tombstoned sessions are absent from the registry and therefore never reported as known, so an explicitly deleted session still reaches `register`, whose atomic tombstone check declines it. Provenance of a registered row stays owned by the explicit create/restore paths. - Classification (the 342 adoptable rows): while migrate-legacy is off, adoptable extension-host candidates are never emitted, so their Git-touching project resolution is now skipped entirely instead of being computed and then filtered away. `_emitCopilotChats` keeps its filter as a re-check, since the setting can flip mid-pass. - Registration (21.9s): `_registerDiscoveredChats` rejects an already-registered candidate with unchanged provenance before `_isChatBacking()` or any other per-session I/O. - Listing (109.8s / 91.0s / 73.2s): `listSessions()` coalesces concurrent computations per external-sessions mode, so the burst a multi-window restore produces shares one registry traversal. The shared entry records the registry epoch it started at and every registry mutation invalidates it, so a caller arriving after a mutation starts a fresh pass rather than joining a possibly pre-mutation one. Each caller gets its own array; rejections are shared only with callers already waiting. - `_readStoredSessionMetadata` / `_readSessionMetadata` now issue one bulk `getMetadataObject()` query instead of nine and six single-key reads, shrinking the cost of the fallback path that runs when no host filter is installed. Deferred deliberately: seeding a newly discovered external session as read still creates its database purely to hold one flag. Dropping the write without a durable default would flip every discovered external session to unread, because the list overlay only applies `IsRead` when the key is present. The correct default belongs on the registry row and is left to the registry list-projection change; the reasoning is recorded on `_initializeExternalSessionReadState`. Removal of `_awaitInitialProviderMigration()` is likewise not attempted: the reproduction proves migration was already skipped. Tests assert call/open counts rather than wall-clock thresholds: registry-known candidates cause zero session DB opens; disabled adoptable candidates resolve no projects; re-registering a known discovered chat performs no per-session I/O; the known-sessions filter reports registered sessions only and leaves tombstones to registration; concurrent list calls share one computation but not their arrays; a mutation during an in-flight list is not served from it; and stored metadata is read with a single bulk query. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: address discovery review feedback Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: update discovery perf fixture Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Visual Studio Code - Open Source ("Code - OSS")
The Repository
This repository ("Code - OSS") is where we (Microsoft) develop the Visual Studio Code product together with the community. Not only do we work on code and issues here, but we also publish our roadmap, monthly iteration plans, and our endgame plans. This source code is available to everyone under the standard MIT license.
Visual Studio Code
Visual Studio Code is a distribution of the Code - OSS repository with Microsoft-specific customizations released under a traditional Microsoft product license.
Visual Studio Code combines the simplicity of a code editor with what developers need for their core edit-build-debug cycle. It provides comprehensive code editing, navigation, and understanding support along with lightweight debugging, a rich extensibility model, and lightweight integration with existing tools.
Visual Studio Code is updated monthly with new features and bug fixes. You can download it for Windows, macOS, and Linux on the Visual Studio Code website. To get the latest releases every day, install the Insiders build.
Contributing
There are many ways in which you can participate in this project, for example:
- Submit bugs and feature requests, and help us verify them as they are checked in
- Review source code changes
- Review the documentation and make pull requests for anything from typos to new content.
If you are interested in fixing issues and contributing directly to the codebase, please see the document How to Contribute, which covers the following:
- How to build and run from source
- The development workflow, including debugging and running tests
- Coding guidelines
- Submitting pull requests
- Finding an issue to work on
- Contributing to translations
Feedback
- Ask a question on Stack Overflow
- Request a new feature
- Upvote popular feature requests
- File an issue
- Connect with the extension author community on GitHub Discussions or Slack
- Follow @code and let us know what you think!
See our wiki for a description of each of these channels and information on some other available community-driven channels.
Related Projects
Many of the core components and extensions to VS Code live in their own repositories on GitHub. For example, the node debug adapter and the mono debug adapter repositories are separate from each other. For a complete list, please visit the Related Projects page on our wiki.
Bundled Extensions
VS Code includes a set of built-in extensions located in the extensions folder, including grammars and snippets for many languages. Extensions that provide rich language support (inline suggestions, Go to Definition) for a language have the suffix language-features. For example, the json extension provides coloring for JSON and the json-language-features extension provides rich language support for JSON.
Development Container
This repository includes a Visual Studio Code Dev Containers / GitHub Codespaces development container.
-
For Dev Containers, use the Dev Containers: Clone Repository in Container Volume... command, which creates a Docker volume for better disk I/O on macOS and Windows.
- If you already have VS Code and Docker installed, you can also click here to get started. This will cause VS Code to automatically install the Dev Containers extension if needed, clone the source code into a container volume, and spin up a dev container for use.
-
For Codespaces, install the GitHub Codespaces extension in VS Code, and use the Codespaces: Create New Codespace command.
Docker / the Codespace should have at least 4 cores and 6 GB of RAM (8 GB recommended) to run a full build. See the development container README for more information.
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct. For more information, see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
License
Copyright (c) Microsoft Corporation. All rights reserved.
Licensed under the MIT license.