Related Pages

Related topics: Core Engine: LLM Providers, Context, Tools, Indexing, and MCP, Configuration, Rules, Prompts, and Customization, IDE and CLI Surfaces: VS Code, JetBrains, and the Continue CLI

Continue Overview and System Architecture

1. Project Purpose and Distribution Model

Continue is described in the project README as a "coding agent" distributed in three first-party surfaces: a command-line interface (CLI), a Visual Studio Code extension, and a JetBrains plugin. The repository reached a "Final 2.0.0 Release" that polished all three surfaces, removed anonymous telemetry, and pulled authentication out of the client code; after that release the README explicitly states that the continuedev/continue repository is "no longer actively maintained and is read-only for all users." Source: README.md:14-26.

The repository is therefore a snapshot of the last open-source distribution of Continue, packaged as an Apache-2.0 monorepo (see the license field in extensions/cli/package.json:8-10 and the badge in README.md:6). External integrations — for example, governance proxies in front of MCP servers — have historically been evaluated through third-party integration requests, indicating that the project design anticipates an ecosystem of plugins around the core agent (community reference: #12492).

2. Workspace Layout and Core Packages

Continue is organized as a multi-package monorepo. The extensions/ tree contains the per-IDE surfaces; extensions/cli/package.json declares runtime dependencies such as fdir, find-up, fzf, and js-yaml, and dev dependencies that reference the local SDKs and adapters used at runtime (e.g. @continuedev/sdk, @continuedev/openai-adapters, @continuedev/config-yaml, @continuedev/terminal-security) Source: extensions/cli/package.json:13-31.

Shared configuration behavior lives under packages/:

The Python SDK ships generated OpenAPI documentation and uses bearer-token authentication, exposing endpoints for organizations and secret synchronization Source: packages/continue-sdk/python/api/README.md:1-15.

3. Configuration Pipeline: YAML and Markdown Frontmatter

User-facing configuration is expressed as YAML plus Markdown with frontmatter. The @continuedev/config-yaml package centralizes round-trip serialization:

• createMarkdownWithPromptFrontmatter joins YAML frontmatter (typed as PromptFrontmatter with name, description, invokable) with the prompt body using yaml.stringify. Source: packages/config-yaml/src/markdown/createMarkdownPrompt.ts:11-23.
• createPromptMarkdown is the high-level helper; it trims input, conditionally adds description and invokable, and delegates to the frontmatter composer. Source: packages/config-yaml/src/markdown/createMarkdownPrompt.ts:25-46.
• Rule files follow the same pattern, exposed through createMarkdownWithFrontmatter, createRuleMarkdown, and markdownToRule. The unit tests demonstrate the supported frontmatter shape: name, description, globs (string or array), and alwaysApply (boolean). Sources: packages/config-yaml/src/markdown/createMarkdownRule.test.ts:1-120, packages/config-yaml/src/markdown/markdownToRule.test.ts:9-40.

The markdown/index.ts barrel re-exports all of the above helpers, which is the entry point consumed by the extensions Source: packages/config-yaml/src/markdown/index.ts:1-6.

4. Codebase Indexing, Model Routing, and Automation

Codebase context is produced by the Rust crate under sync/, which keeps a per-tag Merkle tree of the workspace and returns four diff buckets (compute, delete, add label, remove label). The hash of the file contents is the index key, which keeps results shared across workspaces and branches. Source: sync/src/README.md:3-30.

Local embeddings can be performed in-process via the vendored @xenova/transformers package, which wraps ONNX runtime (web and node) and depends on @huggingface/jinja for templating Source: core/vendor/modules/@xenova/transformers/package.json:16-23.

For model metadata, @continuedev/llm-info defines LlmInfo and ModelProvider objects; providers are declared in providers/ and models in models/, with per-provider overrides (e.g. contextLength, recommendedFor) applied via spread. Cohere's provider entry illustrates the schema, with chat, embed, and rerank model families declared explicitly Source: packages/llm-info/src/providers/cohere.ts:1-120.

Automation around the agent is delivered via GitHub Actions; the published continuedev/continue/actions/general-review@main action requires continue-api-key, continue-org, and continue-config inputs and writes a single summary comment to the pull request Source: actions/README.md:1-46.

5. Known Limitations Reflected in the Community

Several recurring failure modes surface in the issue tracker and are worth documenting alongside the architecture:

• Tool execution drift: edit_existing_file can fail silently in the VS Code integration even when chat reports success (#12317), suggesting a gap between the agent layer and the IDE edit protocol.
• Reasoning payload contract: requests to certain GPT-5.x endpoints have been rejected with "'message' was provided without its required 'reasoning' item" (#12620), indicating that the OpenAI adapter must thread reasoning items through every message when the model expects them.
• Local model interop: system prompts were dropped when targeting LM Studio (#10781), and Ollama-derived errors include Error parsing Ollama response (#11006) and ECONNRESET against 127.0.0.1:11434 (#11027). These point to the local-provider adapters as a common failure surface.
• Context-length validation: a 400 from siliconflow for Qwen 2.5 Coder 32b (max_total_tokens (33802) must be less than or equal to max_seq_len (32768), #10993) indicates that BaseLLM must clamp maxTotalTokens against the model's contextLength from llm-info.
• Terminal security: @continuedev/terminal-security already recognizes high-risk package-manager verbs, but does not yet catch typosquatted package names such as npm install lodahs (#12573) — an open gap in the rule logic that isHighRiskPackageManager does not address.
• Editor coverage: long-standing requests for Neovim (#917), full Visual Studio (#759), and Zed (#1889) remain unresolved because the 2.0.0 release retired first-party extension development.

See Also

• @continuedev/config-yaml reference
• @continuedev/llm-info reference
• Codebase indexing (sync crate)
• Continue PR Review Actions
• @continuedev/terminal-security

Related Pages

Related topics: Continue Overview and System Architecture, Configuration, Rules, Prompts, and Customization, IDE and CLI Surfaces: VS Code, JetBrains, and the Continue CLI

Core Engine: LLM Providers, Context, Tools, Indexing, and MCP

Overview

Continue is positioned in README.md as a "pioneering open-source coding agent" distributed as a CLI, VS Code extension, and JetBrains plugin. The core engine is the shared substrate that drives every surface: it abstracts LLM providers, assembles context from indexed code and rules, exposes tools (including Model Context Protocol servers), and persists an incrementally maintained codebase index. Although the repository is now read-only following the final 2.0.0 release, the engine remains the canonical reference for understanding Continue's behavior end to end.

The engine is implemented as a set of focused npm packages under packages/ plus a Rust workspace at sync/. The CLI extension in extensions/cli/ is the primary consumer of these packages and is where the wiring is most visible — its extensions/cli/package.json shows direct file: dependencies on @continuedev/config-yaml, @continuedev/openai-adapters, @continuedev/sdk, and @continuedev/terminal-security, plus @modelcontextprotocol/sdk and OpenTelemetry instrumentation.

LLM Providers and Model Metadata

Provider-specific knowledge is centralized in the @continuedev/llm-info package. Per packages/llm-info/README.md, the package is responsible for templates, capabilities (tool use, images, streaming, predicted outputs), and model aliases, while @continuedev/openai-adapters performs the actual API translation. The design goal stated in the README is that adding a new model should require only "editing a single LlmInfo object" and registering it with a supporting ModelProvider.

Two primary types organize the data:

• LlmInfo — model-level metadata such as contextLength, maxCompletionTokens, recommendedFor, and free-form description.
• ModelProvider — provider-level grouping that reuses models with provider-specific overrides.

Providers are organized by file under packages/llm-info/src/providers/. For example, packages/llm-info/src/providers/cohere.ts declares embed/rerank/chat variants with explicit contextLength values (4096 for rerank and embed models, up to 128000 for chat variants), and packages/llm-info/src/providers/cometapi.ts enumerates Claude, DeepSeek, and Qwen3 derivatives each carrying their own context windows. The package is published as @continuedev/llm-info (v1.0.10) per packages/llm-info/package.json.

Common provider-side failures observed in the community (e.g. parsing Ollama chat responses #11006, missing system prompts on LM Studio #10781, and max_total_tokens exceeding max_seq_len on Qwen via SiliconFlow #10993) are precisely the cases where per-model metadata in llm-info would need to be accurate to prevent misconfiguration.

Configuration, Context, and Rules

User-facing configuration is normalized through @continuedev/config-yaml and @continuedev/config-types (Zod-based). The package README at packages/config-yaml/src/README.md describes a four-stage loading pipeline:

1. Unrolling — A source config.yaml is recursively expanded so all referenced packages are merged into a single document (performed on the server, unless using local mode).
2. Client rendering — User secret template variables are replaced with values; other secrets become secret locations.
3. Publishing — npm run build followed by npm publish --access public after bumping the version in package.json.

Context authoring uses markdown files with YAML frontmatter. The helper at packages/config-yaml/src/markdown/createMarkdownPrompt.ts builds prompts with name, optional description, and an invokable flag via a small PromptFrontmatter interface. Agents are parsed in packages/config-yaml/src/markdown/agentFiles.ts, which validates frontmatter against a Zod schema (name, description, model, tools, rules) and exposes a ParsedAgentTools structure distinguishing MCP server references, built-in tools, and allBuiltIn shorthand. Telemetry and event schemas are versioned in packages/config-yaml/src/schemas/data/index.ts (devDataVersionedSchemas) covering autocomplete, quick edit, chat feedback, tool usage, and edit/next-edit outcomes.

Codebase Indexing

Indexing is a Rust component living in sync/. The README at sync/src/README.md defines a *tag* as a (workspace, branch, provider_id) triple and explains that sync_results returns four lists: Compute, Delete, Add label, Remove label. Each tuple is (file_path, content_hash), and downstream stores (Meilisearch, Chroma) key items by content hash with optional chunk suffix — enabling deduplication across tags.

flowchart LR
  A[Source tree] --> B[Merkle build<br/>respects .gitignore<br/>and .continueignore]
  B --> C{Compare with<br/>persisted tree}
  C -->|diff| D[sync_results]
  D --> E1[Compute]
  D --> E2[Delete]
  D --> E3[Add label]
  D --> E4[Remove label]
  E1 --> F[(Meilisearch / Chroma)]

The first sync builds the tree from scratch; subsequent syncs diff against the persisted tree, update .last_sync, and emit only the deltas. This content-addressed design is what allows workspace/branch labels to be attached and detached cheaply without re-embedding unchanged files.

Tools, Terminal Security, and MCP

Tool execution is anchored by @modelcontextprotocol/sdk and @continuedev/terminal-security, both wired into the CLI per extensions/cli/package.json. The terminal-security package gates high-risk package-manager invocations (npm install, yarn add, pnpm i, etc.) behind a permission check, as documented in issue #12573; community discussion there notes the rule currently answers "is this an install?" but not "what is being installed" — leaving typosquat targets like npm install lodahs unflagged.

MCP integration is referenced through the SDK and surfaced in the config layer: AgentToolReference in packages/config-yaml/src/markdown/agentFiles.ts distinguishes MCP server slugs (owner/package or https://...) from built-in tools, and ParsedAgentTools.mcpServers lists unique slugs that must be added to the active config. Governance of those MCP servers via third-party proxies was proposed in #12492. Auto-approval of tool calls is tracked separately in #12623.

See Also

• Continue Docs: <https://docs.continue.dev>
• VS Code Extension Marketplace: <https://marketplace.visualstudio.com/items?itemName=Continue.continue>
• Codebase Indexing spec: sync/src/README.md
• LLM metadata catalog: packages/llm-info/README.md
• Config spec: packages/config-yaml/src/README.md
• Continue Hub API (TypeScript): packages/continue-sdk/typescript/api/README.md
• Continue Hub API (Python): packages/continue-sdk/python/api/README.md

Related Pages

Related topics: Continue Overview and System Architecture, Core Engine: LLM Providers, Context, Tools, Indexing, and MCP, IDE and CLI Surfaces: VS Code, JetBrains, and the Continue CLI

Configuration, Rules, Prompts, and Customization

Overview and Purpose

Continue is a coding agent distributed as a CLI, a VS Code extension, and a JetBrains plugin, and its behavior in all three surfaces is driven by a single declarative configuration file called config.yaml (README.md). The @continuedev/config-yaml package is the canonical implementation of this specification: it defines the schema, the markdown-with-frontmatter conventions for rules and prompts, the loading and unrolling logic, and the typed shapes used by the rest of the system (packages/config-yaml/package.json, packages/config-yaml/src/README.md).

The config-yaml README states that a "source" config.yaml is "unrolled" so that its packages are merged into a single effective configuration, and that unrolling happens on the server unless the user runs in local mode (packages/config-yaml/src/README.md). After unrolling, the result is rendered on the client by substituting user secret template variables with values and replacing other secrets with their secret locations. This two-phase model — server-side unrolling plus client-side secret rendering — is the foundation of how Continue separates raw configuration from runtime values.

A separate package, @continuedev/config-types, supplies shared TypeScript and Zod-based type definitions that the loader, the CLI, and the editor integrations all depend on (packages/config-types/package.json).

Block Types in config.yaml

A config.yaml is not a flat key-value file; it is partitioned into a small set of well-known top-level blocks. The exact set of recognized block types is encoded in BLOCK_TYPES and surfaced through getBlockType, which inspects a parsed ConfigYaml and returns the first block that has content (packages/config-yaml/src/load/getBlockType.ts).

The blockTypeSchema is a Zod enum over this list, so any loader that ingests a config.yaml will reject unknown top-level block keys before they reach the rest of the system (packages/config-yaml/src/load/getBlockType.ts).

Rules: Markdown with Frontmatter

Rules are authored as Markdown files with YAML frontmatter. The public API of the markdown module is re-exported from a single barrel file and includes createMarkdownWithFrontmatter, createRuleMarkdown, sanitizeRuleName, markdownToRule, and the prompt counterparts (packages/config-yaml/src/markdown/index.ts).

A rule file looks like:

Related Pages

Related topics: Continue Overview and System Architecture, Core Engine: LLM Providers, Context, Tools, Indexing, and MCP, Configuration, Rules, Prompts, and Customization

IDE and CLI Surfaces: VS Code, JetBrains, and the Continue CLI

Overview

Continue ships the same coding agent across three end-user surfaces: a VS Code extension, a JetBrains plugin, and a standalone CLI invoked as cn. The repository's top-level README.md is explicit that "the continuedev/continue repository is no longer actively maintained and is read-only for all users" and documents a "Final 2.0.0 Release" that "polished Continue and did a final 2.0.0 release of the VS Code extension, CLI, and JetBrains plugin," including removing anonymous telemetry, pulling out authentication, and squashing bugs.

Source: README.md:1-30

Under all three surfaces sits the same TypeScript "core" engine, which is bundled into a portable executable so it can be embedded in any IDE. The CLI, by contrast, runs the engine directly under Node and is also the runtime consumed by the project's GitHub Action for automated PR reviews.

The Three Surfaces

VS Code Extension

The VS Code surface is distributed through both the VS Code Marketplace and the OpenVSX registry. The source lives in extensions/vscode, and it is the surface where the majority of user-visible regressions are filed — for example, syntax highlighting failing to refresh under the "auto detect color scheme" setting, and edit_existing_file operations that report success in chat but silently fail to apply. Both stem from the chat layer and the editor buffer layer coordinating through the core binary.

Source: README.md:32-38

JetBrains Plugin

The JetBrains plugin lives in extensions/intellij and is now community-maintained. Its own README.md opens with a strong steer to the CLI: "We strongly recommend using the Continue CLI instead. It works in any environment, it's where our active development is happening, and it's a better experience than we can reliably provide through the plugin right now. Run cn in your terminal alongside your IDE and you get the same agent capabilities, the same model access, and the same configuration, without depending on a plugin framework we can't give the attention it deserves."

Source: extensions/intellij/README.md:6-9

The plugin still exposes Agent, Chat, Edit, and Autocomplete entry points, but maintainers direct new users to run the CLI alongside the IDE rather than rely on the plugin framework.

Continue CLI

The CLI is published to npm as @continuedev/cli and is invoked as cn. Its package.json shows it is built on top of @continuedev/config-yaml, @continuedev/openai-adapters, @continuedev/sdk, and @continuedev/terminal-security, plus @modelcontextprotocol/sdk for MCP tool integration and the @opentelemetry/* stack (sdk-node, exporter-metrics-otlp-{grpc,http}, instrumentation-fs, instrumentation-http) for metrics export.

Source: extensions/cli/package.json:1-60

The CLI is also the runtime that the continuedev/continue/actions/general-review@main GitHub Action shells into. The action is configured through three inputs — continue-api-key, continue-org, and continue-config — and posts a summary comment with strengths, issues, and recommendations.

Source: actions/README.md:1-60

Shared Core and the Core Binary

The binary/ directory packages the TypeScript core in core/ into a portable executable. Its README.md states: "The purpose of this folder is to package Typescript code in a way that can be run from any IDE or platform. We first bundle with esbuild and then package into binaries with pkg." The bundling configuration lives in a separate pkgJson/package.json because pkg reads assets from the package descriptor and would otherwise pull in production dependencies; the actual build is driven by build.js.

Source: binary/README.md:1-10

The binary supports two transports to the IDE. By default, VS Code spawns it as a subprocess and exchanges JSON messages over stdin/stdout. For JetBrains debugging, the binary can be switched into TCP mode: "To debug the binary with IntelliJ, set useTcp to true in CoreMessenger.kt, and then in VS Code run the 'Core Binary' debug script. Instead of starting a subprocess for the binary and communicating over stdin/stdout, the IntelliJ extension will connect over TCP to the server started from the VS Code window."

Source: binary/README.md:30-37

The core itself, in core/, depends on @continuedev/config-yaml, @continuedev/llm-info, @continuedev/openai-adapters, @continuedev/terminal-security, and @continuedev/fetch for transport, plus the Anthropic SDK, AWS Bedrock and SageMaker runtime SDKs, @modelcontextprotocol/sdk, and onnxruntime-{web,common,node} for local embeddings.

Source: core/package.json:30-60

flowchart LR
  subgraph Surfaces["User-facing surfaces"]
    VSCode["VS Code extension<br/>extensions/vscode"]
    JB["JetBrains plugin<br/>extensions/intellij<br/>(community-maintained)"]
    CLI["Continue CLI<br/>@continuedev/cli (cn)"]
    GHA["GitHub Action<br/>actions/general-review"]
  end
  subgraph Core["Shared core"]
    Engine["core/ TypeScript engine"]
    Binary["binary/<br/>esbuild + pkg"]
    Config["packages/config-yaml"]
    LLMInfo["packages/llm-info"]
    TermSec["@continuedev/terminal-security"]
    OpenAI["@continuedev/openai-adapters"]
  end
  VSCode -- "stdin/stdout JSON" --> Binary
  JB -. "TCP (useTcp=true)" .-> Binary
  CLI -- "direct Node" --> Engine
  GHA -- "spawns cn" --> CLI
  Binary --> Engine
  Engine --> Config
  Engine --> LLMInfo
  Engine --> OpenAI
  Engine --> TermSec
  CLI --> Config
  CLI --> LLMInfo
  CLI --> TermSec

Configuration, Security, and Community Pain Points

All three surfaces share the same config.yaml specification. The packages/config-yaml/src/README.md describes the load pipeline: a "source" config.yaml is unrolled — on the server by default, or locally in local mode — by recursively loading every referenced package and merging it; the resulting unrolled config is then rendered on the client by replacing user-secret template variables with their values and replacing all other secrets with secret locations.

Source: packages/config-yaml/src/README.md:1-15

The CLI in particular consumes this spec and delegates dangerous shell gating to @continuedev/terminal-security. Community issue #12573 reports that the package-manager rule there currently only answers "is this an install?" (recognising npm/yarn/pnpm install/add/i) and not "what is being installed?", so typosquats such as npm install lodahs are not yet caught. Two other recurring community concerns attach to the surfaces themselves: the auto-approve flow on VS Code is reported as fragile (#12623), and several users have asked for the Linux default config directory to move under ~/.config/continue (#5397).

Source: extensions/cli/package.json:1-60; community issue #12573

Editors that have no first-party surface — Neovim (#917), Visual Studio proper (#759), and Zed (#1889) — remain the most upvoted enhancement requests, but with active development now consolidated in the CLI, the recommended path for those environments is to run cn alongside the existing editor rather than wait for a dedicated plugin.

See Also

• Continue documentation — https://docs.continue.dev
• Core Binary build pipeline
• config.yaml specification
• Continue PR Review Action
• JetBrains plugin README
• @continuedev/llm-info package
• Codebase Indexing (sync)
• Next Edit Prediction

Doramagic Pitfall Log

Found 37 structured pitfall item(s), including 9 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/continuedev/continue/issues/11440

2. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: Integration: would a runtime governance proxy in front of MCP servers be in scope for third-party integrations?
• User impact: Developers may expose sensitive permissions or credentials: Integration: would a runtime governance proxy in front of MCP servers be in scope for third-party integrations?
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Integration: would a runtime governance proxy in front of MCP servers be in scope for third-party integrations?. Context: Observed when using python
• Evidence: failure_mode_cluster:github_issue | https://github.com/continuedev/continue/issues/12492

3. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: PR checks do not create fresh agent sessions on PR updates; stale task IDs re-post to new commits
• User impact: Developers may expose sensitive permissions or credentials: PR checks do not create fresh agent sessions on PR updates; stale task IDs re-post to new commits
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: PR checks do not create fresh agent sessions on PR updates; stale task IDs re-post to new commits. Context: Observed when using macos
• Evidence: failure_mode_cluster:github_issue | https://github.com/continuedev/continue/issues/12382

4. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: edit_existing_file fails silently in VS Code integration, despite chat confirming success
• User impact: Developers may expose sensitive permissions or credentials: edit_existing_file fails silently in VS Code integration, despite chat confirming success
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: edit_existing_file fails silently in VS Code integration, despite chat confirming success. Context: Observed when using node, python, windows
• Evidence: failure_mode_cluster:github_issue | https://github.com/continuedev/continue/issues/12317

5. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: terminal-security: package-manager rule flags installs but not typosquat targets (e.g. npm install lodahs)
• User impact: Developers may expose sensitive permissions or credentials: terminal-security: package-manager rule flags installs but not typosquat targets (e.g. npm install lodahs)
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: terminal-security: package-manager rule flags installs but not typosquat targets (e.g. npm install lodahs). Context: Observed when using node, docker
• Evidence: failure_mode_cluster:github_issue | https://github.com/continuedev/continue/issues/12573

6. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/continuedev/continue/issues/12492

7. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/continuedev/continue/issues/12382

8. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/continuedev/continue/issues/12317

9. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/continuedev/continue/issues/12573

10. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Default Linux Config Directory Should Be .config/continue
• User impact: Developers may misconfigure credentials, environment, or host setup: Default Linux Config Directory Should Be .config/continue
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Default Linux Config Directory Should Be .config/continue. Context: Observed when using linux
• Evidence: failure_mode_cluster:github_issue | https://github.com/continuedev/continue/issues/5397

11. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Docs: Document recent CLI features (hooks, ai-sdk, cn checks, MCP Apps, skills)
• User impact: Developers may misconfigure credentials, environment, or host setup: Docs: Document recent CLI features (hooks, ai-sdk, cn checks, MCP Apps, skills)
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Docs: Document recent CLI features (hooks, ai-sdk, cn checks, MCP Apps, skills). Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/continuedev/continue/issues/11758

12. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: GPT 5.5 - reoccurring 'message' was provided without its required 'reasoning' item
• User impact: Developers may misconfigure credentials, environment, or host setup: GPT 5.5 - reoccurring 'message' was provided without its required 'reasoning' item
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: GPT 5.5 - reoccurring 'message' was provided without its required 'reasoning' item. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/continuedev/continue/issues/12620

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using continue with real data or production workflows.

• autoapprove - github / github_issue
• Default Linux Config Directory Should Be .config/continue - github / github_issue
• Integration: would a runtime governance proxy in front of MCP servers be - github / github_issue
• PR checks do not create fresh agent sessions on PR updates; stale task I - github / github_issue
• terminal-security: package-manager rule flags installs but not typosquat - github / github_issue
• edit_existing_file fails silently in VS Code integration, despite chat c - github / github_issue
• GPT 5.5 - reoccurring 'message' was provided without its required 'reaso - github / github_issue
• Code syntax highlighting doesn’t update colors when using 'auto detect c - github / github_issue
• System prompt not sent to local LM Studio models - github / github_issue
• Error: Qwen 2.5 Coder 32b - 400 - github / github_issue
• Error: qwen3.5:9b - Unknown error - github / github_issue
• Error: hive-angel:latest - Unknown error - github / github_issue