Bug: sanity init does not detect VS Code Insiders (especially in WSL) re: `detectAvailableEditors`

[ChrisNolan]

Describe the bug

When creating a new Sanity project, I see the following output:

⚠ No supported AI editors detected (Cursor, VS Code, Claude Code)

This happens even though I am running the command inside a terminal window inside VS Code Insiders. I believe VS Code Insiders should be detected the same way as VS Code stable.

---

To Reproduce

1. Install VS Code Insiders (nightly build) instead of the regular VS Code:
   https://code.visualstudio.com/insiders
2. Run sanity init from a terminal inside VS Code Insiders.

Variant (WSL / Remote case)

1. On Windows, install VS Code Insiders.

2. Enable WSL.

3. From WSL, run:

   code-insiders .

4. Open the integrated terminal in VS Code Insiders.

5. Run sanity init.

---

Expected behavior

VS Code Insiders should be detected as a supported editor, just like VS Code stable — including when running remotely via WSL.

---

Actual behavior

The CLI reports that no supported AI editors are detected.

---

Screenshots

This screenshot shows the two locations in the codebase where the editor detection output is processed differently:

While touching this code, it might be worth refactoring so the messaging is derived from the same source as detectAvailableEditors. Right now:

• One location suggests where to go next
• The other only reports the absence of editors

If the list of supported editors changes, this duplication could easily drift.

---

Versions

• Sanity: 5.1.0 (latest)
• OS: Windows 10

---

Additional context

There appear to be two related but distinct issues:

1. VS Code Insiders on Windows

The current detection logic looks for VS Code config folders such as:

path.join(process.env.APPDATA, 'Code/User')

However, VS Code Insiders uses:

Code - Insiders/User

As a result, Insiders is not detected even on a standard Windows setup.

2. VS Code Insiders + WSL (remote case)

In the WSL scenario, the problem is deeper:

• VS Code runs on Windows
• The Sanity CLI runs in Linux (WSL)
• Editor config folders do not exist in the Linux filesystem

So even expanding the folder check to include Code - Insiders would not work reliably for WSL or other remote scenarios.

---

Suggested improvements

Relying solely on the presence of editor config directories seems brittle, especially for:

• Insiders builds
• WSL / SSH / containerized remote development
• Portable or nonstandard installs

A more robust detection strategy might be:

1. If running inside a VS Code integrated terminal, assume VS Code is available

   • e.g. TERM_PROGRAM=vscode

2. Otherwise, check for code or code-insiders on $PATH

3. On Windows, optionally fall back to registry entries or known install locations

4. Treat config-directory checks as a best-effort signal rather than a requirement

This would allow VS Code (stable and Insiders) to be detected correctly across local and remote environments.

FYI this came in 3 weeks ago via PR #11434 by @jwoods02

---

Summary

• VS Code Insiders is not detected due to hard-coded assumptions about config paths
• The issue is more pronounced (and not solvable via paths alone) in WSL
• Environment-based detection would be more reliable and future-proof

Happy to help test or validate a fix if needed.

[stipsan]

cc @sgulseth

[jwoods02]

Hey @ChrisNolan thanks for the report, the detailed analysis was really helpful

I don't think the suggested TERM_PROGRAM approach would quite work for us because we're not just detecting which editor is running - we need to know the specific config file path so we can write the MCP configuration to it. That's why we deliberately look for known config directories rather than environment variables.

For WSL/remote scenarios, even if we detected VS Code via TERM_PROGRAM, we'd still have no way to locate or write to the config file on the Windows side.

This feature is knowingly brittle, not expected to support all editors/setups and more a "nice to have" to ease the installation of the MCP for most users on common setups. I don't think our warning/error message explains this very well!

To fix we will:

1. Improve the messaging to make it clearer that if we can't find an editor it's just because we can't find your config file to write to and you need to manually setup MCP in your config (Code Insiders, WSL, portable installs, etc.) it doesn't mean you don't have a "supported AI editor installed"
2. Add VS Code Insiders build to the list of more editors / config setups we're looking to support in the future

Also nice catch of the warn message duplication, I'll improve that also while I'm there

Thanks again for the detailed writeup

[ChrisNolan]

Thanks for the followup and improving the messaging @jwoods02 .

I guess since it is about writing out the config, the flag that was discussed on discord too about whether those settings are written to the 'global' install for the current project install would something as well. In that case, just seeing a '.vscode' folder in the project could be it?

But backing up... maybe there is a 'recommended way' of doing this... my assistant says that is making an 'extension' that allows the user to decide to install the server, and then use its API for updating the settings.json. It seems the consensus is to not be editing the json directly, especially globally? idk.

For a content editor who is non technical I can see we want to make it easy to give them a way to access to tools... but for a dev, this feels a bit heavy handed.