Skip to main content

Buyer guide

Running Continue's Final Release: A Team Playbook

Pin the release, keep a single shared config.yaml and rule set, set tool policies, and review Continue's changes before they merge.

Reading time
3 min read
Sources
16 cited
In this piece
Continue−9 Mixed

A team that keeps Continue now owns a frozen release. The last VS Code extension is 2.0.0 from June 19, 2026, with a 2.1.0 pre-release build the same day, and users report that the last JetBrains plugin, 1.0.67, fails to load on 2026.2 IDEs. Every fix after those builds falls to your team, so keep tool approvals on and review Continue's changes like a colleague's.

When you need this

  • Engineers still use Continue after the June 2026 acquisition, and you have not decided whether to move.
  • Each engineer configured models differently, and results vary from one machine to the next.
  • Agent mode edits files and runs commands under approval settings nobody chose deliberately.
  • Security asks what Continue sends where, now that no vendor answers for it.

Steps

  1. Pin the release

    Which build runs on every machine, and who changes it?

    What to setInstall VS Code extension 2.0.0, the final stable build from June 19, 2026, from the Marketplace or from a VSIX downloaded from Open VSX. Turn extension auto-update off so nothing changes under you. GitHub Releases carry VSIX files only up to the June 15 builds. The JetBrains plugin's last release is 1.0.67 from March 27, 2026, and the repository recommends the cn CLI over it. Users report that 1.0.67 fails to load on JetBrains 2026.2 IDEs, and on 2026.3 preview builds, because it does not declare the JCEF plugin dependency. The one-line fix sits in an unmerged pull request, so keep JetBrains users on 2026.1 IDEs or move them to the CLI.

  2. Share one configuration

    Do all engineers run the same models for the same roles?

    What to setKeep one reviewed config.yaml with its name, version, and schema. List models by role (chat, edit, apply, autocomplete, embed), and reference keys as secrets from a .env file kept out of Git. The IDE extensions cannot read shell environment variables, so every machine needs that .env file. Companies that run their own model gateway hand engineers a pre-generated config.yaml.

  3. Write the project rules down

    Does every engineer's Continue follow the same conventions?

    What to setCommit Markdown rules in .continue/rules with the code, and set alwaysApply on the conventions every request needs.

  4. Set tool policies on purpose

    What can Continue run without asking?

    What to setIn the IDE, Agent mode asks before each tool call unless that tool's policy is Automatic, and Plan mode offers only read-only tools. In the cn CLI, edits, writes, and Bash default to ask, choices persist in ~/.continue/permissions.yaml, and --auto allows everything. Outside a sandbox, keep terminal commands on ask.

  5. Keep each change reviewable

    Can a reviewer see exactly what Continue changed?

    What to setKeep requests small and read the diff before accepting. One engineer reports Continue writing a different block than it proposed, so treat its output as a draft until a reviewer accepts it.

  6. Know where data goes

    What does Continue record, and where does it send it?

    What to setContinue writes development data to .continue/dev_data on each machine and can send it to a team endpoint at level noCode, which drops file contents, prompts, and completions. The final release removed anonymous telemetry and sign-in. One team built its traceability on these local files.

Questions for your team

  1. Who owns our pinned build or fork if a security issue appears, now that upstream will ship no fix?
  2. Which model endpoints is config.yaml allowed to point at, and how do we check that on each machine?
  3. Which engineers use the JetBrains plugin, and are they hitting the freezes reported against it?
  4. When do we decide between staying, forking, and moving, and what evidence will decide it?

Red flags

  • Extension auto-update left on, with no record of which build each machine runs.
  • API keys pasted into config.yaml and committed to a repository.
  • Terminal commands set to Automatic on machines that hold production credentials.
  • Agent-written changes merged without the review a human change would get.

Products in this piece

Sources

Official documentation
11
Public source
5
  1. Continue on GitHub (continuedev/continue)Official documentationgithub.com
  2. Continue releases on GitHubOfficial documentationgithub.com
  3. Continue on the Visual Studio MarketplaceOfficial documentationmarketplace.visualstudio.com
  4. Continue on Open VSXOfficial documentationopen-vsx.org
  5. Continue on JetBrains MarketplaceOfficial documentationplugins.jetbrains.com
  6. Continue docs: config.yaml referenceOfficial documentationdocs.continue.dev
  7. Continue docs: FAQsOfficial documentationdocs.continue.dev
  8. GitHub issue #13185: JetBrains plugin fails to load in 2026.2 IDEs (Aug 24, 2026)Public sourcegithub.com
  9. GitHub issue #6399: a pre-generated config.yaml for a company LLM gateway (Jul 2, 2025)Public sourcegithub.com
  10. Continue docs: RulesOfficial documentationdocs.continue.dev
  11. Continue docs: How Agent mode worksOfficial documentationdocs.continue.dev
  12. Continue docs: CLI tool permissionsOfficial documentationdocs.continue.dev
  13. Continue docs: Development dataOfficial documentationdocs.continue.dev
  14. Hacker News, codingdave: Continue writes a different block than it proposed (Jan 20, 2025)Public sourcenews.ycombinator.com
  15. GitHub issue #12876: impact of the Cursor acquisition on traceability built on Continue's data files (Jun 22, 2026)Public sourcegithub.com
  16. GitHub issue #8085: JetBrains sidebar freezes 3 to 4 times a day across endpoints (Oct 3, 2025)Public sourcegithub.com