Version 2.0.0 is an endpoint, not a fresh beginning
Continue is a coding agent with three faces: a CLI, a VS Code extension, and a JetBrains plugin. That range once made it easy for a team to keep one agent configuration across editors and terminals. The Apache 2.0 code is still available, and the final packages remain linked from the repository. The decisive fact is now printed near the top of the README: Continue is no longer actively maintained and is read-only for users.
The maintainers describe 2.0.0 as the final release. They say it removed anonymous telemetry and authentication, fixed bugs, and polished the VS Code extension, CLI, and JetBrains plugin. That is a cleaner stopping point than an unexplained abandoned branch. It is still a stopping point. A team adopting Continue in August 2026 should assume it will pin that release, carry patches in a fork, or later migrate rather than wait for an ordinary next version.
Three clients remain, but the CLI is the recommended one
The repository presents the same basic agent through VS Code, JetBrains IDEs, and a command line. That is useful if developers move between an editor and scripted terminal work. Source links are provided for each client, the VS Code build remains listed in both Microsoft's marketplace and OpenVSX, and the CLI is distributed through npm. Continue specifically recommends the CLI instead of the JetBrains plugin, which is unusually direct guidance and should shape a new install.
Client choice also changes the risk. Open issue 13185 reports that JetBrains plugin 1.0.67 fails during startup on 2026.2 IDEs because a JCEF dependency is not declared. The reporter says adding that dependency fixes the load failure and opened a corresponding change. Open issue 13158 describes VS Code extension 2.0.0 registering one command twice under WSL2. The extension still opens, but the error returns after reinstalling it. Neither report makes every installation broken. Both show why a final release needs testing against your actual editor updates.
What happened when we ran it
Our sandbox cloned commit 5522c6f and installed 319 npm packages in 16 seconds. Those dependencies occupied 107 MB, and npm audit reported 0 known vulnerabilities across all severity levels. The install result is better than the repository's size might suggest: 3,001 files, roughly 331,015 lines of source, and 281.9 MB checked out. The container had 3 CPUs and 8 GB of RAM, with no secrets.
There was no build script or target exposed to our harness, so we skipped the build. The same was true of tests: no test script or target was available for the run, and we did not substitute another command. This does not prove the code has no internal tests or validation. The repository contains 31 CI workflow files. It means a fresh npm-oriented checkout did not offer the conventional top-level verification commands our runner could execute.
That distinction matters for a fork. Installation tells you the dependency graph resolves at commit 5522c6f. It does not tell you that all three clients compile together or that an editor release works with the final package. A team taking ownership should map the relevant workflow files, identify the per-package commands, and reproduce those jobs before changing agent behavior. The absent top-level targets make that handoff more work than the 16-second install suggests.
Unattended shell use has an unresolved safety report
Open issue 13001 is the strongest reason to avoid treating the CLI as a finished automation appliance. The report says headless and auto modes allow Bash by default and depend on a terminal-security evaluator to stop destructive commands. Its submitted examples include paths and command forms that the reporter says are not blocked, including an environment-variable form that expands to a home directory when the shell runs it. The issue remained open when we researched the project.
That is a report, not a security advisory or a maintainer-confirmed verdict. The prudent response is still clear. Do not feed untrusted repository text, fetched pages, or tool output into an unattended Continue session that has broad filesystem access. Run it inside a disposable workspace, restrict credentials, and require permission for shell commands. A coding agent can encounter hostile instructions inside the material it reads; a denylist is a thin boundary when the upstream project has ended normal maintenance.
Recent pushes do not reverse the maintenance notice
GitHub recorded the last push on August 25, 2026, and the open queue contained 940 issues and pull requests. Recent entries include fixes for provider routing, command permissions, JetBrains loading, streaming, and pricing. That activity shows contributors are still touching the repository. It does not cancel the maintainer's explicit statement that the project is read-only for users or turn the June 19 final release into an ongoing release line.
The queue should not be called 940 bugs because GitHub combines issues and pull requests in that number. It is still a large body of unresolved work for a repository whose README says maintenance has stopped. Community patches may be valuable to a fork, but there is no basis for assuming they will become another supported release.
New teams should choose a maintained agent
Continue remains useful as readable source, a pinned tool for current users, and a base for organizations willing to own a fork. Its multi-client design and permissive license are real advantages. The final release also gives existing users a named version from which to plan a migration instead of forcing an emergency move.
For a new deployment, maintenance status outweighs the pleasant install. Aider is the closer terminal-first choice, Cline fits teams committed to VS Code, and OpenAI Codex is another current CLI option. Continue makes sense only when a specific part of its 2.0.0 implementation is worth taking responsibility for. The 16-second dependency install is easy; inheriting fixes across 3 clients is the lasting cost.