fix: pass pre-read content to RegistryClient for WSL compatibility

[shanevcantwell]

Summary

• Fixes workspace .continue/ files failing to load when Windows VS Code connects to WSL
• Root cause: loadYaml.ts discarded pre-read content and passed only URIs to RegistryClient, which tried fs.readFileSync() (fails for vscode-remote:// URIs)
• Solution: Added ContentIdentifier type to pass pre-read content directly through the loading pipeline

Fixes #6242, Fixes #7810

Test plan

• Unit tests pass (297 tests in config-yaml)
• Built Linux vsix, installed in WSL via code --install-extension
• Created .continue/docs/test.yaml in WSL workspace
• Verified config loads without ENOENT errors

🤖 Generated with Claude Code

---

Continue Tasks

Status	Task	Actions
▶️ Queued	Update docs on PR	View

_{Powered by Continue}

---

Summary by cubic

Fixes WSL config loading by passing pre-read YAML content through the pipeline to avoid fs reads on vscode-remote:// URIs (Fixes #6242, #7810).

• Bug Fixes
  • Added optional content field to FileIdentifier; loadYaml now includes it.
  • RegistryClient.getContent returns pre-read content when present.
  • Added tests for file identifiers using pre-read content.

^{Written for commit 1c74659. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 18 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="core/llm/index.ts">

<violation number="1" location="core/llm/index.ts:1124">
P2: Tool prompt overrides are skipped when tools are only defined in the model’s default completionOptions, so per-model overrides never apply to default tools.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[RomneyDa]

@shanevcantwell to clarify, is there a case where it loads content from not a file or slug? I'm thinking that we could just add the content field and check if it's present rather than adding a new uriType. This would simplify the PR significantly e.g. getContent could just check if content is present and if so return it, and most other changes could be reverted.

I would also be able to merge this faster since we use this type on our backend (and other people might too) and adding a new uriType could be a breaking change

[shanevcantwell]

@shanevcantwell to clarify, is there a case where it loads content from not a file or slug? I'm thinking that we could just add the content field and check if it's present rather than adding a new uriType. This would simplify the PR significantly e.g. getContent could just check if content is present and if so return it, and most other changes could be reverted.

I would also be able to merge this faster since we use this type on our backend (and other people might too) and adding a new uriType could be a breaking change

That was definitely an excessive solution. This is much cleaner.

[RomneyDa]

Looks clean!