CLI Feedback

[bdougie]

🚀 We just launched Continue CLI - async AI agents in your terminal!
We'd love your feedback on the new CLI tool for building async coding agents. What workflows would you automate? Any feature requests or use cases we should consider?

Try it: npm i -g @continuedev/cli

Docs: https://docs.continue.dev/guides/cli
Announcement: https://x.com/continuedev/status/1958591429804269906

[Igorgro]

I have a negative experience with getting started on Linux. When I first launched a cli it caused excessive disk load while showing nothing. After a 5 minutes of empty console it showed a prompt asking for either logging in to Continue or to use Anthropic key. I wanted to use local models and nothing of that options was suitable for me, so I tried to exit the cli, but it does not react to Ctrl-C, neither Ctrl-d. The only way to exit is to send SIGKILL. I hope the next updates will make it at least runnable

[Igorgro]

I used lsof and noticed that during that long startup it scans the whole home directory. What the hell is going on here? Is that freaking malware?

[Igorgro]

I found the code resposible for that

continue/extensions/cli/src/systemMessage.ts

Line 93 in 3543454

${getDirectoryStructure()}

. While it is not a malware, I think it's totally incorrect to send such data as current working directory, OS name and the whole directory tree to external services without explicit user consent. Also, I noticed that this project uses sentry to catch error, then me as a user cannot be sure that that info won't be sent to third-parties without my agreement

[bdougie]

Thanks for the feedback @Igorgro

[bdougie]

Looks like a related question came up in the discord. Cross linking here https://discord.com/channels/1108621136150929458/1156679146932535376/1412737814768128001

Points to #7528

[chrisbratlien]

Trying out @continuedev/cli v1.4.35 (beta) on Windows PowerShell and also WSL.

I use the VS Code extension all the time. When trying out CLI, I noticed a few things which could improve:

1. The default config.yaml is not detected on WSL or on Windows without supplying --config path parameter

2. CLI can't find Ollama AUTODETECT models in the config below whether using CLI in PowerShell or WSL bash. Continue VS Code extension has no problem finding them in either PowerShell or WSL bash.

  - name: Ollama Autodetect
    provider: ollama
    model: AUTODETECT
    apiBase: http://ollama.local:11434
    capabilities:
      - tool_use
    roles:
      - apply
      - edit
      - chat
      - summarize
      - autocomplete

It shows up as one entry in the Select Model list:

[aaronpliu]

experiencing the issue as @Igorgro , it often stuck and no response, and hard to exit even if press cmd+C/ctrl+C, and wait for a long time after input /exit.
I have a proxy setting in my machine, and add the apiBase IP in bypass list since it no need proxy to access. But in CLI (v1.5.7), cannot access remote API, in spite of running command cn --config ~/.continue/config.yaml, using same config as continue.

[lagosr-github]

Trying the continue.dev cli on debian. - some feedback.

1 - The cn cli ignores the stream: false directive from the config.yaml file (it always uses streaming, would be nice to support non-streaming too if possible)

2 - have not found an ollama model that works well with cn cli .. either you get "Error: 400 registry.ollama.ai/library/ does not support tools" . or the model does poorly when function calling (like qwen 2.5 coder)

A section in the docs for suggested models to use would be awesome.

Some positive feedback -- worked great with Gemini 2.5 Pro.

[juan-3ds]

Continue CLI v1.5.10 is not recognizing the MCP servers in the ~/.continue/mcpServers directory. I am starting it as cn --config ~/.continue/config.yaml .
EDIT: I was able to load it manually using --mcp ~/.continue/mcpServers/server.yaml, but it would be nice if these got loaded automatically.

[bdougie]

Continue CLI v1.5.10 is not recognizing the MCP servers in the ~/.continue/mcpServers directory. I am starting it as cn --config ~/.continue/config.yaml .

EDIT: I was able to load it manually using --mcp ~/.continue/mcpServers/server.yaml, but it would be nice if these got loaded automatically.

The cli is does not have feature parity to the extension and leverages mcp hosted in the hub exclusively. This is an attempt to focus on making it work but open to feedback here.

[juan-3ds]

Thanks for clarifying about the feature parity. For now, the manual approach using --mcp and --rules works, but it is very tedious, especially if I have many rules/mcp servers. I would definitely put this on my wish list.

[erigrus]

For me it does not work at all.

I have a config which works perfectly fine in the VSCode extension but not at all in the CLI. See my question here: #8628

[bdougie]

I responded there

[natasaasteve-dotcom]

ok

[AlanNggg]

Continue CLI v1.5.14 doesn't load custom prompts from .continue/prompts directory while the IDE version does - is there a plan to support this functionality in the CLI in the future?

[daryltucker]

Here's a polite GitHub issue summary that captures all the problems you've encountered:

---

Title: CLI setup wizard lacks "Use Local Models" option and doesn't detect existing config

Description:

First, thank you for creating Continue.dev! I'm excited to use it with local models like Ollama, but I've encountered some UX issues with the CLI setup that make it difficult to get started without cloud services.

Problems:

1. Missing local model option in setup wizard

   • When running cn config, only two options are presented:
     • 1. ⏩ Log in with Continue
     • 2. 🔑 Enter your Anthropic API key
   • There's no third option like "Use Local Models" or "Skip"
   • This creates the impression that Continue requires cloud services or accounts

2. Option 2 doesn't allow skipping

   • Selecting option 2 and leaving the API key blank results in: Fatal error: API key is required
   • The documentation incorrectly suggests this as a workaround

3. Setup wizard ignores existing config

   • Even with a valid ~/.continue/config.json already configured with Ollama, running cn still shows the setup wizard
   • Expected behavior: CLI should detect and use existing configuration

Current workaround:

• Press Ctrl+C to exit the wizard
• Manually edit ~/.continue/config.yaml
• Use cn -p "prompt" to bypass the wizard entirely

Suggested improvements:

1. Add a third option: "Use Local Models" or "Skip Setup"
2. Allow option 2 to accept empty input to skip
3. Detect and respect existing configuration files
4. Consider making the setup wizard optional if config already exists

Environment:

• Continue CLI installed via: npm i -g @continuedev/cli
• Existing config with Ollama at ~/.continue/config.json

Again, thank you for this project! These changes would make the local-first experience much smoother for new users.

---

I acknowledge the gap between "technically possible" and "actually usable" for local-only setups.
However, you're right that none of this gets you to a working Continue setup if you're being pushed toward Mission Control at every turn. The local configuration path exists but is clearly designed with friction to drive adoption of the hosted service.

[daryltucker]

Here's a polite GitHub issue that captures the .env file configuration problem:

---

Title: Allow configurable .env filename to prevent conflicts with project environment files

Description:

Thank you for creating Continue! I'm excited to use it with local models, but I've encountered a significant UX issue with how Continue handles environment variables.

The Problem:

Continue currently searches for and uses .env files in this order:

1. Workspace root (.env)
2. Workspace .continue/ folder (.continue/.env)
3. Global user folder (~/.continue/.env)

This creates conflicts when projects already use .env files for their own configuration. In my case, I'm getting:

Error reading .env file at /home/daryl/Projects/myProject/.env: EISDIR: illegal operation on a directory, read

Why This Matters:

Many development tools (including aider and cn) default to using the project's .env file, which pollutes project configuration with tool-specific secrets. This is similar to naming a binary continue when bash has an internal continue command - it creates namespace conflicts.

Suggested Solutions:

1. Change the default filename to .continue.env instead of .env to avoid stomping on project environment files
2. Make the env filename configurable in config.yaml, allowing users to specify their preferred filename:

   envFile: .continue.env

3. Prioritize tool-specific locations - Search .continue.env before falling back to .env

Current Workarounds:

• Using ~/.continue/.env for global secrets (but this doesn't solve the workspace-level issue)
• Manually ensuring .env is a file, not a directory (error-prone)

Impact:

This affects any Continue user whose projects already use .env files for application configuration, which is extremely common in modern development workflows.

Again, thank you for this excellent project! This change would make the local-first experience much smoother and prevent conflicts with existing project tooling.

Environment:

• Continue CLI installed via: npm i -g @continuedev/cli
• Projects using .env for application configuration

[daryltucker]

Based on the documentation, here's a polished bug report for you:

---

Title: defaultCompletionOptions naming is misleading - applies to all model interactions, not just completions

Description:

The configuration property defaultCompletionOptions has a misleading name that causes confusion for users. Despite its name suggesting it only applies to autocomplete/completion functionality, it actually controls parameters for all model interactions including chat, edit, apply, and other roles.

Current Behavior:

When configuring Ollama models (or any provider), parameters like num_ctx, temperature, maxTokens, etc. must be placed under defaultCompletionOptions:

models:
  - name: gpt-oss
    provider: ollama
    model: gpt-oss:20b-fp16
    apiBase: http://192.168.1.69:11435
    defaultCompletionOptions:
      num_ctx: 32768  # This applies to ALL roles, not just completion

    requestOptions:
      extraBodyProperties:
        num_ctx: 32768

This didn't work, and was recommended by the Documentation Agent.

The Problem:

1. The name defaultCompletionOptions implies it only affects the autocomplete/completion role
2. Users who aren't using autocomplete (like myself) naturally assume this setting doesn't apply to their use case
3. The documentation confirms this applies to all model roles, making the "Completion" terminology a misnomer
4. This leads to configuration errors where users place settings in incorrect locations (like requestOptions.extraBodyProperties)

Expected Behavior:

The property name should accurately reflect its scope. Suggested alternatives:

• defaultModelOptions - Clearly indicates it applies to the model generally
• modelOptions - Simpler and more accurate
• defaultOptions - Generic but clearer than current naming

Suggested Solution:

1. Rename the property to better reflect its actual scope (e.g., defaultModelOptions)
2. Maintain backward compatibility by supporting both old and new names during a deprecation period
3. Update documentation to clarify the property's scope across all model roles
4. Add migration warnings when the old property name is detected

Additional Context:

According to the config.yaml reference, defaultCompletionOptions controls settings for all model roles including chat, edit, apply, and summarize - not just autocomplete. The historical naming likely stems from LLM terminology where "completion" refers to any text generation, but this conflicts with Continue's specific "autocomplete" role, creating ambiguity.

Impact:

This naming issue affects user experience and leads to:

• Wasted troubleshooting time
• Incorrect configurations
• Confusion about where to place model-specific parameters

Thank you for considering this improvement to make Continue's configuration more intuitive!

---

Edit: It seems defaultCompletionOptions doesn't work to set num_ctx. So maybe it's not a misnomer, but the Documentation Agent is adamant this is how to solve the problem.

[daryltucker]

Here's a bug report you can post on the GitHub tracker:

---

Title: TUI mode shows diff but no permission prompts or interactive UI in xterm

Description:

I'm using the cn CLI tool with the --allow writeFile flag, but the TUI is not displaying any permission prompts, buttons, or interactive UI elements when a diff is generated.

Expected Behavior:
According to the documentation, when using cn with --allow writeFile, I should see:

• The diff displayed
• Permission prompts with "Cancel" and "Continue" buttons
• Ability to accept/reject changes using keyboard shortcuts

Actual Behavior:

• The diff is displayed
• No permission prompts or buttons appear
• Immediately returns to the prompt to ask a new question
• Keyboard shortcuts (Ctrl+Alt+Y, Ctrl+Shift+Enter) have no effect
• The file is never written despite the --allow writeFile flag

Environment:

• Terminal: xterm
• Command used: cn --config ~/.continue/config.yaml --allow writeFile

Configuration:

name: default
version: 0.0.1
schema: v1
allowAnonymousTelemetry: false
models:
  - name: gpt-oss
    provider: ollama
    model: gpt-oss:20b-fp16
    apiBase: http://192.168.69.69:11435
    requestOptions:
      extraBodyProperties:
        num_ctx: 32768
    defaultCompletionOptions:
      num_ctx: 32768
    roles:
      - chat
      - edit
      - apply
embeddingsProvider:
  provider: ollama
  model: qwen3-vl:2b-instruct-q4_K_M
  apiBase: http://192.168.69.169:11434

Questions:

1. Are there specific terminal emulator requirements for the TUI to display interactive elements?
2. Is xterm supported for the interactive permission prompts?
3. Should the keyboard shortcuts work even without visible UI elements?

The TUI appears to be missing the permission interface entirely, making it impossible to approve file writes even with the --allow writeFile flag.

Thank you for your help!

[daryltucker]

Here's a complete, polite bug report for GitHub:

---

Title: Unexpected Network Requests to Amazon Servers with Local-Only Configuration

Description:

I've configured Continue with allowAnonymousTelemetry: false and exclusively local Ollama models, yet the application appears to be making network requests to Amazon servers. According to the documentation, Continue should only contact external servers when using cloud AI providers, when telemetry is enabled, or when using Continue Mission Control for cloud-managed configs.

Configuration:

name: default
version: 0.0.1
schema: v1
allowAnonymousTelemetry: false
models:
  - name: gpt-oss
    provider: ollama
    model: gpt-oss:20b-fp16
    apiBase: http://10.X.X.X:11435
    roles: [chat, edit, apply]
  - name: Qwen3 Embedder
    provider: ollama
    model: qwen3-vl:2b-instruct-q4_K_M
    apiBase: http://10.X.X.X:11434
    roles: [embed]

Expected Behavior:

With telemetry disabled and only local Ollama models configured, Continue should not make any external network requests, including to Amazon servers.

Actual Behavior:

Network monitoring shows connections to Amazon servers despite the local-only configuration.

Additional Context:

I've verified that:

• allowAnonymousTelemetry is explicitly set to false
• All model providers point to local Ollama instances
• No Continue Mission Control features are in use

This may indicate unexpected behavior that warrants investigation. Thank you for looking into this issue.

---