continuedev / continuedev/continue

Better support for different configurations on remote projects

Open
#3,889 5 comments 1 reaction 1 assignee View on GitHub

@sestinj is already working on this.

Since Jan 29, 2025.

area:configuration ide:vscode kind:enhancement needs-triage
Dominant language
TypeScript
Stars
36k
Forks
5.4k
PR merge metrics
No merged PRs in 30d

Description

Validations
  • I believe this is a way to improve. I'll try to join the Continue Discord for questions
  • I'm not able to find an open issue that requests the same enhancement
Problem

Keeping config.json in ~/.continue/ feels awkward for folks (like me) who develop solely on remote hosts via SSH or in devcontainers. For example, at work (where we develop on cloud infrastructure via Coder), we have a shared server running open-source LLMs (for HIPAA compliance), which is only accessible via the company VPN. In contrast, I develop personal open source projects locally in Docker via the Remote Development extension, and don't want to use the company's LLMs for that. So at that point there really isn't any shared config between work and personal projects.

The current solution I've landed on is to include a dummy ~/.continue/config.json:

{
  "models": []
}

just so that the extension doesn't fail the config validation. Then I put all the actual configuration on a per-project basis in .continuerc.json.

Solution

It would be nice if there was a cleaner way to separate configs between projects, beyond .continuerc.json:

Ideally:

  • Extension should be installable on remote hosts rather than local-only
  • Configs should be saved where the VS Code server is running (remote SSH hosts or devcontainers) rather than the VS Code client machine

One stop-gap solution could be as simple as not requiring the presence of ~/.continue/config.json and just using .continuerc.json on a per-workspace basis.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.