Fixing file path for saving new files from chat in windows

[arafatkatze]

Solves Linear issue

Problem

On Windows systems, file operations were failing due to incorrect URI handling, specifically:

• Windows paths (e.g., C:\path\to\file) were being incorrectly interpreted as URIs
• Backslashes were being URL-encoded (%5C) causing path resolution failures
• The system was interpreting drive letters (e.g., "C:") as URI schemes instead of part of the path

This resulted in errors like:

• Provider "C" not installed
• The network path was not found
• URISyntaxException with "Expected scheme-specific part"

Solution

Added proper Windows path normalization in CodyEditorUtil.kt to handle file paths correctly before URI creation:

1. Added path normalization for Windows-style paths:

2. Applied this normalization in both findFileOrScratch and createFileOrScratchFromUntitled methods

Test plan

• Follow the steps of this video in windows
• Notice that the file will be saved successfully without errors
• Check the logs which will be clean

Changelog

[olafurpg]

defaultUri is a URI so it should be parsed into a path like this

Paths.get(URI.create(params.defaultUri))

This has accidentally worked on other platforms because it assumes file:// is part of the path name. Wrapping in try/catch won't fix the root problem.

[pkukielka]

@olafurpg maybe it's a good time to rewrite agent API to use Path objects instead of strings? There is quite a few corner cases in the way paths can be encoded (especially on windows) and discrepancies between agent and client path parsing hit us many times in past.

[olafurpg]

You mean the auto-generated bindings? We encode these as TypeScript string on the cody side and don't have a static type to distinguish between URIs and normal strings.

[olafurpg]

For good and bad, we rely on JSON.stringify, which doesn't expose hooks to customize serialization of URI instances, so we need to rely on some form of discipline