mirror of
https://github.com/microsoft/vscode.git
synced 2026-08-22 13:13:08 +01:00
a1c7d1be7e
* Collect and package Agent Host debug logs on the host "Export Agent Host Debug Logs" previously had the client guess the paths of host-owned log files and open them one by one. The Agent Host now discovers and packages its own diagnostics, including the Copilot SDK runtime logs obtained via the SDK's own collectLogs API rather than by searching the disk. Ownership is split: the host packages host-owned logs into an artifact, while the client keeps contributing the logs it owns (renderer, shared process, AHP transport JSONL, usage and customization sidecars). Native exports flatten the host archive into the single resulting zip; browser builds keep folder export. This is exposed as a private, non-spec AHP extension command (vscode/collectAgentHostDebugLogs) so the shape can settle before it is proposed for the protocol. Hosts that predate it answer MethodNotFound and the client falls back to the previous discovery path. Remote hosts return an artifact URI whose bytes are streamed back through a second private command (vscode/readAgentHostDebugLogsChunk) in bounded 1 MiB chunks, so a whole archive never has to be Base64-encoded into one JSON-RPC message. Only artifacts the collector itself produced are readable, so this is not a general-purpose file read. A local Agent Host returns a plain file URI and its bytes never cross IPC at all. Artifacts are size-capped, expire on a lease, and are cleaned up on shutdown. Host-side collection failures are non-fatal: the export falls back to client-side collection so it still produces the logs the client owns. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Don't let host-side log collection hang the debug-logs export Manual end-to-end testing of "Export Agent Host Debug Logs" found the command could appear to do nothing at all: no save dialog, no error, no log output. Host-side collection goes through the agent host management channel, which waits for the host to reach a connected state. When the host never gets there -- easy to hit by running the command during startup, or when the protocol channel handshake times out -- that request stays pending forever, and since the export awaited it directly, the whole command hung silently. Bound the collection and fall back to client-side discovery when it does not finish in time, so an export always produces the logs the client owns. The previous change already treated collection *failures* as non-fatal; this extends the same guarantee to a host that never answers. A late-arriving artifact is discarded rather than leaked, since nothing is waiting for it by the time it lands. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Give host-side log collection a longer bound Raise the host-collection timeout from 20s to 30s. Manual testing showed a real collection has to zip the host's logs, which can be large, so the original bound was tight enough to risk dropping host logs from a host that was merely slow rather than stuck. Also correct the comment: the failure this guards against is a host that never answers at all, not merely one that is unreachable. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix local agent host management calls hanging forever Every call through the local agent host management channel -- Network Diagnostics, and the new debug-log collection -- could hang forever with no error and no output. `_getManagementService()` was an `async` method that returned the management service. That service is a `ProxyChannel` proxy whose `get` trap answers *every* string property with a function, including `then`. Resolving a promise with such an object makes the runtime treat it as a thenable and invoke `then` as if it were a remote method, so the promise never settles and the caller waits forever. It also puts a bogus `agentHostManagement.then` request on the wire, whose malformed reply is the source of the "Unexpected end of JSON input" deserialization errors seen in the agent host log. Split the wait from the lookup: `_whenManagementConnected()` resolves `void`, and the proxy is obtained synchronously afterwards, so it is never passed through a promise. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Collect debug logs on the Agent Host only, with no client-side fallback The export had two implementations of host-log discovery: the Agent Host's own collector, and a client-side path-guessing fallback used whenever the host artifact was missing or incomplete, guarded by a 30s timeout. That is a lot of machinery to keep a second, less accurate implementation alive. Make the host path the only path. The client now contributes only the logs it genuinely owns (window/shared-process output channels, AHP transport JSONL, and the client-local capture sidecars); everything host-owned comes from the artifact. If collection fails, the failure surfaces to the user instead of being silently replaced by a lesser result. The host can now produce those logs in the case that previously forced the fallback. `collectDebugLogs` no longer requires a live session: with no session to reach the SDK through, the provider copies the most recent Copilot process log straight off the host's own disk, where it knows the real location rather than guessing it from the client. Because those logs can reach hundreds of megabytes, the collector now keeps only the trailing bytes of any file over a per-file cap. That bounds the artifact whether the file came from the SDK bundle or was copied in directly, and the tail is the part that explains a recent failure. In practice this takes a local export from ~44 MB to ~2.5 MB. Also drops the remaining whole-file Base64 copy that a remote export could silently fall back to when streaming was unavailable; streaming is now required. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Require a live session for Agent Host debug-log collection Remove the remaining no-session implementation and make the live session URI required through the client, private extension protocol, management bridge, AgentService, collector, and provider contracts. The workbench command now reports an error when there is no active Agent Host chat. The Agents Window no longer substitutes its most recently updated, possibly closed session. On the host, the session must resolve to its owning provider, and Copilot must resolve it to a live SDK session before invoking `session.rpc.debug.collectLogs` with events, process logs, and shell logs. Providers without additional diagnostics still contribute the Agent Host process log through the same collector. If a provider implements collection, its failure propagates and fails the export rather than silently returning a partial archive. This leaves one success path and no client-side or direct-disk fallback. (Written by Copilot) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Allow Agent Host debug-log export without an active session A host-wide export is valid without an active chat. Keep the session optional through the client, private protocol, management bridge, AgentService, collector, and provider contracts. With a live session, Copilot asks that exact SDK session for events, process logs, and shell logs. Without a live session (including a New Session placeholder whose SDK session has not started yet), it uses any live Copilot SDK session only as the gateway for process logs, explicitly excluding that unrelated session's events and shell logs. If no SDK session is live, the same host collector still packages the Agent Host process log. The client still adds the logs it owns: window/shared output, all applicable AHP JSONL logs, remote-forwarded output channels, and capture sidecars. No direct process-log path scan or client-side host-log fallback is reintroduced. (Written by Copilot) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Require debug-log collection on Agent Host connections Every real Agent Host connection implements debug-log collection and bounded artifact reads. Make both methods required on `IAgentConnection`, implement them as explicit unsupported operations on the browser null service, and remove workbench guards that could never detect an older remote server. Provider-specific diagnostics remain optional: that controls what the host adds to its artifact, not whether the connection supports the collection API. (Written by Copilot) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Harden Agent Host debug-log artifacts and remote export Enforce the same 1,000-file limit while staging that the native ZIP merger uses, and include an exact normalized file manifest in each artifact. Remote clients validate the manifest's paths, entry sizes, uniqueness, aggregate size, and entry count. Use that manifest to stream browser remote-directory files through bounded 1 MiB artifact reads instead of whole-file Base64 resource reads. Retained directory artifacts whitelist only the regular files that were enumerated, so the chunk endpoint remains artifact-scoped. Local browser copies verify the manifest against file type, symlink state, and size before copying. Restore the active remote Agent Host forwarded output channel, and preserve text MIME types in resourceRead while retaining binary Base64 support. Align archive validation with the collection contract: at most 16 MiB on the wire, while highly-compressible archives may expand to the bounded 256 MiB staging limit. (Written by Copilot) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Stabilize debug-log artifact cleanup tests Replace fixed 20 ms sleeps with bounded polling for the actual temporary directory state. Artifact expiration triggers asynchronous filesystem removal, so a busy CI machine can observe the timer firing before `rm` has completed. (Written by Copilot) 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.