Repository navigation
feat: Add mcp.json to Visual Studio gitignore exceptions - #4735
BenjaminMichaelis wants to merge 2 commits into
Conversation
As mcp's are becoming more common, sharing a workspace configuration of mcp servers is becoming more and more common with the mcp.json file. (https://code.visualstudio.com/docs/copilot/customization/mcp-servers#_add-an-mcp-server) Adding this file as an exclusion to the default template so that it can be utilized by the editors and shared via source control. This file can also be picked up by Visual Studio as seen [here](https://learn.microsoft.com/visualstudio/ide/mcp-servers?view=vs-2022&WT.mc_id=8B97120A00B57354#file-locations-for-automatic-discovery-of-mcp-configuration)
There was a problem hiding this comment.
Pull Request Overview
This PR adds an exception for the mcp.json file in the Visual Studio gitignore template to support sharing Model Context Protocol (MCP) server configurations. The change allows the .vscode/mcp.json file to be tracked in version control alongside other VS Code workspace configuration files.
- Adds
!.vscode/mcp.jsonas an exception to the gitignore pattern - Enables sharing of MCP server configurations across development teams
- Aligns with existing patterns for other VS Code configuration files
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
TBH I'd go as far as removing the |
|
This PR is stale because there have been no updates in 90 days. It will close after 365 days of inactivity. Leave a comment if you want to keep it open. |
|
Keep open please |
dooleydevin
left a comment
There was a problem hiding this comment.
There are many valid reasons to include files like settings.json and launch.json, so we can't ignore the whole directory like this.
By our contribution guidelines, these rules really belong in the Global/VisualStudioCode.gitignore file, but they are already here and I'd rather not remove them as a part of this PR.
I'm also not sure that the mcp.json file really should be included in source control. From the VSCode docs here it seems they include an inputs parameter that is intended to include secrets:
"inputs": []: an optional array of input variable definitions for sensitive information like API keys.
If we want to include this, I'd ask for a few changes:
- Revert your last commit that ignores the whole
vscodedirectory - Include the rule as a comment like so
#!.vscode/mcp.json - Include a comment above it that explains why someone might choose to include it in their repository, and the risks of including secrets
- Duplicate this change in
Global/VisualStudioCode.gitignore
|
This PR is stale because there have been no updates in 90 days. It will close after 365 days of inactivity. Leave a comment if you want to keep it open. |
… its own undoing CreateProcessW's command line was declared ref char and called as ref commandLine[0]. Microsoft's own Win32 metadata gives that parameter a span, and ref char was weaker in three ways at once: no length, an empty buffer that becomes IndexOutOfRangeException at the indexer rather than the null the API accepts, and nothing saying which of the two buffers Windows writes back into. Span<char> for the command line and ReadOnlySpan<char> for the environment now say exactly that. The span is pinned rather than copied, so the mutation still lands in our array, and the call site is unchanged apart from losing the [0]. Nothing was known to be wrong with the old shape. That is the point: it is a declaration that presents as a plausible wrong answer rather than as an error, which is the class this repository spends the most on. The two invariants it silently relied on are now stated and asserted -- both buffers NUL-terminated, neither ever empty -- and the empty environment block is the one that matters, because it reaches Windows as null and means inherit the parent's environment. The layout oracle cannot check any of this: NativeMethods.txt admits structs only, deliberately, so a generated P/Invoke is never a second way to call Windows from the test assembly. The .gitignore item had three parts and the first one was a claim that was not true. Upstream's VisualStudio.gitignore was re-fetched and compared: blob d5a18de, unmoved since 2026-04-17, identical to our half except in one place. That one place is why the marker comment's instruction -- refresh it wholesale, in one paste -- was dangerous. artifacts/ and .artifacts/ are root-anchored here, and unanchored they matched src/BrowserAI/Artifacts/ on case-insensitive Windows and made five product source files invisible to git while every other signal read green. So the procedure now says paste, re-apply, run the suite. NoSourceFileIsInvisibleToGit makes forgetting a red build; the comment is what stops the next person having to rediscover why it went red. .vscode/mcp.json is re-admitted below the marker: github/gitignore#4735 is still open, and for a project that IS an MCP server a workspace registration used for testing was silently untracked. Proved with a positive control rather than an absence -- the file was created, git listed it, and the negation was the rule that matched. The third part was already done: /staging/ went on 2026-08-16 with its reason recorded in the file, and the item had gone stale.
Reasons for making this change
As mcp's are becoming more common, sharing a workspace configuration of mcp servers is becoming more and more common with the mcp.json file. (https://code.visualstudio.com/docs/copilot/customization/mcp-servers#_add-an-mcp-server)
Adding this file as an exclusion to the default template so that it can be utilized by the editors and shared via source control.
This file can also be picked up by Visual Studio as seen here
Links to documentation supporting these rule changes
VSCode itself commits this file: https://github.com/microsoft/vscode/blob/main/.vscode/mcp.json
If this is a new template
Link to application or project’s homepage: TODO
Merge and Approval Steps