fix: use config.yaml name for default Local Config profile

[MumuTW]

Summary

• read the default profile title from ~/.continue/config.yaml when loading the global local profile
• keep the existing Local Config fallback when the file is missing, unreadable, or unparseable
• add a focused LocalProfileLoader regression test covering custom name plus fallback cases

Testing

• npm run -s vitest -- config/profile/LocalProfileLoader.vitest.ts (fails in this workspace due unresolved local package entry for @continuedev/config-yaml)

---

Continue Tasks: 🔄 7 running — View all

---

Summary by cubic

Use the name from ~/.continue/config.yaml as the default Local Config profile title. Falls back to "Local Config" when the file is missing, unreadable, malformed, or the name is blank; empty override files no longer trigger a fallback.

• Bug Fixes
  • Read title from the global config; fallback to "Local Config" if invalid. Tests include the required version field, cover name/fallback cases, and scope afterEach to avoid resetting doLoadConfig mocks.
  • Use a strict undefined check for override content so empty override files don’t trigger a global fallback.

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

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="core/config/profile/LocalProfileLoader.ts">

<violation number="1" location="core/config/profile/LocalProfileLoader.ts:46">
P2: Falsy check on override content causes empty override files to fall back to global config and potentially assign the wrong profile title.</violation>
</file>

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

[MumuTW]

Rebased onto latest main to resolve merge conflicts in LocalProfileLoader.vitest.ts. The conflict was between the newly added override-file tests on main and this PR's config.yaml name tests — resolved by keeping both test suites in separate describe blocks. All 3 original commits preserved.

[RomneyDa]

@MumuTW this would be a great improvement. I think the config file is already loaded and parsed in doLoadConfig, and the name is available in configYamlResult but lost since ConfigResult doesn't have a name/title.

Could this be fixed by just somehow just passing it back up as an optional name in ConfigResult or similar? Bit funky to follow the logic with RegistryClient but I think adding optional name to that or to ContinueConfig could be fine

The main problem is I think this current approach would fail every call for various environments like WSL, so even though it's in a try/catch I'd like to avoid the duplicate read and have it work for those envs as well