JetBrains (Rider): project paths containing spaces are URI-encoded (%20) when creating the project .continue directory on Windows

[antsam23]

Summary

When using Continue in JetBrains Rider on Windows, creating or editing the project-specific Continue configuration causes the plugin to create a .continue directory under a URI-encoded filesystem path.
Instead of using the actual project path containing spaces, Continue creates directories where spaces are replaced with %20, resulting in an incorrect location outside the real project directory.

Environment

OS: Windows 11
IDE: JetBrains Rider 2026.2.0.2
Continue: 1.0.67
Project type: Unity/Rider project

Steps to reproduce

• Create or open a project located at: C:\Unity Projects\My Project
• Open the project in JetBrains Rider.
• Use Continue to create or modify the project-specific Continue configuration.
• Check where the .continue directory is created.

Expected behavior

The project configuration should be created inside the actual project directory:

C:\Unity Projects\My Project\.continue

Actual behavior

Continue creates the directory under a URI-encoded path instead:

C:\Unity%20Projects\My%20Project\.continue

As a result, the configuration is written to an incorrect location.

[MilkyWay008]

That's a classic URI-encoding leak — the plugin's writing to the URL-encoded form of the path instead of the raw filesystem path. Quick workaround: manually create the .continue folder at the real path (C:\Unity Projects\My Project\.continue) with a config.json inside, it should pick it up fine from there. Or if you can, move the project to a path without spaces and reopen in Rider, that sidesteps it entirely. Oh also, btw, I built a portable Hermes OTG and I run it on USB as my rescue agent; super handy doing quick diagnose & fix, check it, imo it'll help you. https://github.com/MilkyWay008/Hermes-OTG

[AbarnaaSree]

I’d like to work on this issue. I’ll investigate the URI/path encoding in the JetBrains integration, add a regression test for paths containing spaces, and submit a fix.

[antsam23]

That's a classic URI-encoding leak — the plugin's writing to the URL-encoded form of the path instead of the raw filesystem path. Quick workaround: manually create the .continue folder at the real path (C:\Unity Projects\My Project\.continue) with a config.json inside, it should pick it up fine from there. Or if you can, move the project to a path without spaces and reopen in Rider, that sidesteps it entirely. Oh also, btw, I built a portable Hermes OTG and I run it on USB as my rescue agent; super handy doing quick diagnose & fix, check it, imo it'll help you. https://github.com/MilkyWay008/Hermes-OTG

HI! I tested the suggested workaround, but unfortunately it doesn't solve the underlying issue.

Additional observations:

The MCP Servers UI does not detect the YAML file placed in the real project .continue directory.
Clicking "Add MCP Server" creates a new YAML file under the URI-encoded path (Unity%20Projects) instead of the actual project path (Unity Projects).
This suggests the JetBrains plugin is consistently resolving the project root using the encoded URI path, and both the MCP discovery and MCP creation flows are using that incorrect path.

So this appears to affect more than just the initial .continue folder creation—it also affects the project-scoped MCP configuration workflow.

[antsam23]

I’d like to work on this issue. I’ll investigate the URI/path encoding in the JetBrains integration, add a regression test for paths containing spaces, and submit a fix.

Hi! That would be great, thanks!
I tested the suggested workaround, but unfortunately it doesn't solve the underlying issue.
From the behavior, it looks like the JetBrains plugin is using a URI-encoded project path (with %20) where a filesystem path should be used.
After investigating a bit more, I think the issue is likely happening at the project-root resolution layer rather than only during .continue creation.
The same incorrect path (Unity%20Projects) is used by multiple features:

• Project .continue creation
• MCP server discovery
• Add MCP Server (writes the YAML to the encoded path)

This makes me suspect the JetBrains plugin is passing a URI-encoded project path (for example file:///.../Unity%20Projects/...) instead of the corresponding filesystem path.

The IntelliJ Platform APIs distinguish between URL-style paths and filesystem paths (for example VirtualFile.getUrl() vs VirtualFile.getPath() or project.getBasePath()), so the fix may be near the shared project-root resolution used by these features.

I'm happy to test a PR on Windows + Rider if you put together a fix.

[youlemei2022-web]

This is a URL leaking into filesystem-land: something takes the IDE's project URL, keeps the encoded form, and joins a path onto it. %20 is URL encoding, so the value needs decoding once before any path.join - decodeURIComponent, or better fileURLToPath from node:url if it arrived as a file:// URI.The rule that stops it recurring: never round-trip a filesystem path through a URL. If the project location has to travel through a JSON payload or a webview message, pass it as a plain string and encode only at the boundary that actually needs encoding.Worth checking the other places that derive a project path from the same source too - config path, workspace root, and watcher registration usually share one helper, so they tend to break together.