CLI not reading config block directories or per-project configs

[bdeggleston]

I’m trying to setup continue.dev CLI with global and per-project configs using the yaml docs, and am having a hell of a time getting it working. It’s picking up ~/.continue/config.yaml and the models I’ve defined there no problem, but per-project configs (<project_dir>/.continue/config.yaml) or per-project agents (<project_dir>/.continue/agents/cassandra.yaml) seem to be completely ignored. I’m on the most recent version (1.4.38), and am not seeing any complaints in the debug logs. Any tips or tricks for getting this working properly?

[bdougie]

Hey @bdeggleston, sorry to hear of the issues. I can share my config that works with local models ollama.

If you don't mind sharing yours i'd be happy to help, I just need more information to understand.

note autodetect does not work currently and you need to be explicit in the models you'd like to use.

name: Continue Config
version: 0.0.1
context:
  - provider: diff
  - provider: currentFile
  - provider: docs
  - provider: terminal
  - provider: url
models:
  - name: qwen2.5-coder:14b
    provider: ollama
    model: qwen2.5-coder:14b
    roles:
      - chat
      - edit
      - apply
      - autocomplete
    capabilities:
      - tool_use
  - name: gpt-oss
    model: gpt-oss:20b
    provider: ollama
    roles:
      - chat
      - edit
      - apply
      - autocomplete
    capabilities:
      - tool_use
  - name: Autodetect
    provider: ollama
    model: AUTODETECT
    roles:
      - chat
      - edit
      - apply
      - rerank
      - autocomplete

[bdeggleston]

Thanks @bdougie . So I have something like this in ~/.continue/config.yaml:

name: DefaultAgent
version: 1.0.0
schema: v1

models:
  - name: LocalLLM
    provider: openai
    model: local-model
    apiKey: dummy
    apiBase: http://localhost:1234/v1

This mostly meant as a placeholder

then in ~/.continue/models/corp_proxy.yaml

I have this:

name: corp_proxy
version: 1.0.0
schema: v1

models:
  - name: claude-4-sonnet
    model: "anthropic.claude-sonnet-4-20250514-v1:0"
    provider: anthropic
    apiBase: "http://localhost:12345/forward/api/anthropic/v1"
    roles:
      - chat
      - edit
      - apply

Next, for a specific project I'll have this in <project_dir>/.continue/config.yaml

name: ProjectAgent
version: 1.0.0
schema: v1

models:
  - uses: corp_proxy

Now, it I start cn from the project directory, it will start with DefaultAgent (ignoring the project config), and won't use the project specific config. If I run cn --config $CWD/.continue/config.yaml then it will use the specified config, but won't pick up any of the model data in ~/.continue/models. Actually if I change ~/.continue/config.yaml to use the model in ~/.continue/models/corp_proxy.yaml by setting -uses: corp_proxy as the model - it won't find that either.

So I haven't been able to setup local blocks as described here: https://docs.continue.dev/reference#local-blocks

There also seems to be a bug specificying relative config paths. If I run cn --config .continue/continue.yaml , it will print Fatal error: Failed to load config from ".continue/config.yaml": ENOENT: no such file or directory, open '.continue/.continue/config.yaml' and fail to start

[bdougie]

It seems you may be trying to leverage workspace blocks similar to how they work in the extension. The cli is still in beta and just over a month old. We don't have it at feature parity to the extensions and would be happy to explore making this work, but would need to get more of an understanding of the use case for workspace blocks. Let me know if you if you'd be interested in sharing more. We can move this to a call if needed as well in case there are a lot of moving parts.

[bdeggleston]

Ok I see, that makes more sense. I'd read this: https://docs.continue.dev/guides/cli#how-to-configure-continue-cli and interpreted it to mean that the entire configuration system for the CLI works the same as the plugin. Honestly I'm not familiar with the plugin and learned of continue.dev from the cli, so wasn't expecting there to be a gap, especially since it has a version >1.

Regarding use case, I'm trying to be able to compose configurations from global and per-project settings without having a bunch of duplicated configs. Different projects are able to use different models and have different rules, different languages need different mcp servers (and each project has different settings - etc).