Continue.dev AGENTS.md config.yaml AI coding rules VS Code JetBrains 2026

Continue.dev and AGENTS.md: Configuration Guide for This Open-Source AI Coding Assistant (2026)

The Prompt Shelf ·

Continue.dev — the open-source AI coding assistant available as a VS Code and JetBrains extension — does read AGENTS.md. That wasn’t true for most of its history, and a fair amount of content still published in 2026 says it isn’t true today. It became true on September 22, 2025, when a pull request merged support for AGENTS.md (with AGENT.md and CLAUDE.md as fallbacks) into Continue’s core loading logic. The catch: as of this writing, Continue’s own documentation doesn’t mention it anywhere.

That gap between shipped code and published docs is the reason this guide exists. Below: exactly how Continue.dev’s native config.yaml and .continue/rules/ system works, exactly how the undocumented AGENTS.md fallback behaves (verified against the merged source, not the docs), and how to set up a project that uses either or both.


The Short Answer

Continue.dev has two separate rule systems that both run at once:

  1. .continue/rules/ — Continue’s own, fully documented system. A folder of Markdown (or legacy YAML) files with frontmatter for globs, regex, and alwaysApply, giving you per-directory and per-file-type conditional rules that AGENTS.md cannot express on its own.
  2. AGENTS.md / AGENT.md / CLAUDE.md — an undocumented fallback added in September 2025. Continue checks the workspace root for these three filenames in that priority order, loads the first one it finds, and applies it as an always-on rule alongside whatever is in .continue/rules/.

Both sources get concatenated into the system message. Nothing you write in AGENTS.md overrides or disables .continue/rules/ — they’re additive, not competing formats.


Continue.dev’s Own System: config.yaml and .continue/rules/

From config.json to config.yaml

Continue.dev’s configuration format changed once already. The original format was config.json, which is now deprecated in favor of config.yaml — Continue’s docs describe config.yaml as the format all new features are built against, and config.json as legacy-only. Two changes from that migration matter for rules specifically: the old systemMessage string property was replaced by a rules array, and contextProviders became a context array.

config.yaml lives at:

  • Global: ~/.continue/config.yaml (macOS/Linux) or %USERPROFILE%\.continue\config.yaml (Windows)
  • Project-level: created and managed through the Continue sidebar’s Agent selector, or committed directly to the repo

A minimal config.yaml:

name: My Project Config
version: 1.0.0
schema: v1
models:
  - name: GPT-4
    provider: openai
    model: gpt-4
    roles:
      - chat
      - edit
context:
  - provider: code
rules:
  - Give concise responses
  - Always assume TypeScript rather than JavaScript

rules here accepts three kinds of entries: a plain string (inline instruction), a reference to a shared block on Continue Hub (uses: sanity/sanity-opinionated), or a reference to a local file (uses: file://path/to/rules.md). This block-referencing system — Continue calls the referenced units “blocks” — is specific to config.yaml and has no equivalent in the .continue/rules/ folder format below.

The .continue/rules/ folder

For most day-to-day rule writing, Continue’s docs point to a dedicated folder rather than the rules key in config.yaml:

your-project/
├── .continue/
│   └── rules/
│       ├── 01-typescript-standards.md
│       ├── 02-database.md
│       └── 03-testing.md
├── config.yaml
└── src/

Files load in lexicographical order, which is why numeric prefixes (01-, 02-) are the convention — same pattern used by Cline’s .clinerules/. Continue supports two file formats here: Markdown with YAML frontmatter (current, recommended) and a legacy pure-YAML format that still works but isn’t the documented default going forward.

A Markdown rule file:

---
name: TypeScript Best Practices
globs: ["**/*.ts", "**/*.tsx"]
---

# TypeScript Rules

- Always use TypeScript interfaces for object shapes
- Use type aliases sparingly, prefer interfaces
- Include proper JSDoc comments for public APIs
- Use strict null checks
- Prefer readonly arrays and properties where possible

The frontmatter fields, and exactly what each one does:

FieldRequired?Behavior
nameRequired for legacy YAML rules; optional for MarkdownDisplay title shown in the Continue UI
globsOptionalSingle glob string or array (e.g. ["src/**/*.ts", "tests/**/*.ts"]). Rule only applies when a matching file is in context
regexOptionalContent-pattern matching within included files, in addition to (or instead of) globs
descriptionOptionalExplanation shown to the agent, useful when the agent has to choose whether a rule is relevant
alwaysApplyOptionaltrue = always included regardless of file context. false = included only if globs/regex match, or the agent explicitly selects it. Left unset = included if the rule has no globs, or included when globs match

This is meaningfully more granular than what AGENTS.md can express on its own — AGENTS.md has no schema and no scoping mechanism, so a rule that should only apply to src/db/** has no way to say so inside AGENTS.md itself. That gap is exactly what .continue/rules/ with globs is built to fill.


Does Continue.dev Support AGENTS.md? Yes — Here’s the Exact History

In July 2025, GitHub issue #6716 proposed that Continue detect a root-level AGENTS.md and load it as a default, always-applied rule — the same pattern Cline, Cursor, and a dozen other tools had already adopted. The proposal described the change as small: roughly 20–30 lines of code, fully backward-compatible with .continue/rules/.

What actually happened, reconstructed from the issue thread and the merged code:

  • September 22, 2025PR #7717, “feat: support for AGENTS.md,” merged into main. The core of the change lives in core/config/markdown/loadMarkdownRules.ts, which defines:

    export const SUPPORTED_AGENT_FILES = ["AGENTS.md", "AGENT.md", "CLAUDE.md"];
  • October–December 2025 — Users in the original issue thread independently confirmed the behavior in production (one posting a screenshot of Continue picking up their AGENTS.md), months after the PR shipped and without any documentation update to point to.

  • January 28, 2026 — the original issue was finally closed, with a maintainer comment reading simply “Fixed by #7717.”

Because this shipped as a fallback inside the rules loader rather than as an advertised feature, it never made it into docs.continue.dev. The Rules deep-dive page and the Agent Mode Quick Start page — the two most likely places to document this — make no mention of AGENTS.md, AGENT.md, or the fallback chain as of this writing. That’s also why a search for “Continue.dev AGENTS.md” still surfaces plenty of 2026-dated content repeating the pre-September-2025 answer (“not supported, tracked in issue #6716”). That answer was correct for the fourteen months the issue was open. It stopped being correct in September 2025.

Exactly how the fallback behaves

Reading the merged implementation directly (rather than guessing from the feature name) matters here, because the specifics are easy to get wrong:

  • Priority order, first match wins: Continue checks for AGENTS.md, then AGENT.md, then CLAUDE.md, in that order, and stops at the first one it finds. It does not merge all three if more than one exists.
  • Workspace root only: the check runs via getWorkspaceDirs() against the top level of the first workspace folder. It does not look in subdirectories, and in a multi-root workspace, only the first workspace folder is checked.
  • Loaded as alwaysApply: true: whichever file matches is treated as a global, always-on rule — the equivalent of setting alwaysApply: true on a .continue/rules/ file — tagged internally with source: "agent-file".
  • Loads before .continue/rules/: the agent file is processed first in the rule list, with .continue/rules/ files following. Both sets of rules are concatenated into the system message; the agent file does not suppress or override the folder.
  • File-watched: changes to any of the three filenames trigger a live config reload, same as editing a file inside .continue/rules/ does.

One practical consequence worth flagging: if your project has a CLAUDE.md written specifically for Claude Code and no AGENTS.md or AGENT.md, Continue.dev will pick up that CLAUDE.md and apply it as a global rule — even though you may not have intended Continue to read it at all. There’s no setting to opt out of the fallback chain short of not having any of the three filenames in the workspace root.


Step-by-Step Setup

1. Write a project AGENTS.md (Continue reads it automatically)

No configuration needed. Create AGENTS.md at the workspace root:

# AGENTS.md

## Project
Next.js 15 app, TypeScript strict mode, Drizzle ORM + PostgreSQL, pnpm.

## Conventions
- Server Components by default; "use client" only when required
- Database queries live in src/db/queries/, never inline in components
- No default exports from utility files

## Commands
- pnpm dev — dev server
- pnpm test — Vitest
- pnpm typecheck — tsc --noEmit

## Never
- Modify files under generated/ directly
- Install a new dependency without asking first

Open the project in VS Code or JetBrains with the Continue extension installed, and this loads automatically as an always-on rule — no entry in config.yaml, no file in .continue/rules/ required.

2. Add Continue-specific conditional rules

For anything that should apply only to certain files — the thing AGENTS.md structurally can’t do — add a scoped file to .continue/rules/:

---
name: Database Rules
globs: ["src/db/**", "drizzle/**"]
alwaysApply: false
---

# Database Rules

- Never drop columns in migrations; mark deprecated instead
- All new tables need created_at and updated_at timestamps
- Foreign keys must have explicit ON DELETE behavior

Because alwaysApply is false here and globs is scoped, this rule only enters context when Continue is working with files under src/db/ or drizzle/ — it won’t consume tokens on unrelated tasks.

3. Reference a shared rule block from config.yaml (optional)

If your team maintains rules centrally on Continue Hub, or wants a rule shared across repos without copy-pasting Markdown:

rules:
  - uses: your-org/typescript-standards
  - uses: file://../shared-rules/security.md
  - Keep answers under 200 words unless asked for detail

4. Verify what Continue is actually reading

Open the Continue sidebar (Cmd/Ctrl+L), click the Agent selector, and open the gear icon to see the assembled configuration — this is the fastest way to confirm both AGENTS.md and any .continue/rules/ files are being picked up, since there’s no dedicated “agent file detected” indicator in the UI.


Comparison: Continue.dev vs. Cline vs. Cursor

FeatureContinue.devClineCursor
Reads AGENTS.md?Yes, undocumented fallback (since Sept 2025)Yes, documented and native since Cline v3Yes, documented and native
Own primary formatconfig.yaml + .continue/rules/.clinerules/.cursor/rules/ (Project Rules; .cursorrules legacy)
Conditional/scoped rulesYes — globs + regex in frontmatterYes — paths frontmatterYes — glob scoping per rule file
Fallback priority when multiple files existAGENTS.mdAGENT.mdCLAUDE.md, first match wins, no merge.clinerules/ and AGENTS.md both load and merge.cursor/rules/ and AGENTS.md both load
Shared/hub-based rule referencesYes — Continue Hub uses: blocksNo native hubNo native hub
Workspace scopeWorkspace root only, first workspace folder in multi-rootProject root, plus global ~/Documents/Cline/Rules/Project root, plus global rules in settings
Official docs mention AGENTS.md?No, as of this writingYesYes

The distinguishing line is the last one. Cline and Cursor advertise their AGENTS.md support as a feature; Continue.dev has the same underlying capability but ships it silently. Functionally, once AGENTS.md is in place, all three read it — but only two of them tell you they will.


Migration Guidance

If you’re starting fresh with Continue.dev and already have AGENTS.md: do nothing. It’s picked up automatically. Add .continue/rules/ only for rules that need path scoping.

If you have an existing .continue/rules/ setup and want to adopt AGENTS.md for cross-tool consistency: move the rules that apply to the whole project, with no file-type scoping, into AGENTS.md. Keep anything using globs or regex in .continue/rules/, since AGENTS.md has no equivalent syntax. Remember both load together — you’re not choosing one over the other, you’re deciding which rules belong in which file based on whether they need scoping.

If you’re migrating off legacy config.json: this is a separate, older migration. Move models, tabAutocompleteModel, embeddingsProvider, and reranker entries into the models array in config.yaml with an explicit roles field for each. Any systemMessage string becomes an entry in the rules array. contextProviders becomes context. config.yaml, if present, is loaded instead of config.json — the two aren’t merged.

If you use Continue.dev alongside Claude Code and don’t want Continue reading your CLAUDE.md: be aware that with no AGENTS.md or AGENT.md present, Continue falls back to CLAUDE.md automatically. If that’s not desired, create an empty or minimal AGENTS.md — since it’s earlier in the priority list, it will be read instead of CLAUDE.md.


Frequently Asked Questions

Does Continue.dev officially support AGENTS.md?

Functionally, yes, since a pull request merged September 22, 2025. Officially — in the sense of being documented on docs.continue.dev — no, not as of this writing. The feature works but isn’t advertised, so treat this as verified-but-unofficial behavior rather than a guaranteed, permanently supported feature.

What happens if I have both AGENTS.md and .continue/rules/ files?

Both apply. The agent file (whichever of AGENTS.md, AGENT.md, or CLAUDE.md matched) loads as an always-on rule, and any matching files in .continue/rules/ load alongside it. They concatenate into the system message rather than one replacing the other.

If I have both AGENTS.md and AGENT.md, which one does Continue read?

AGENTS.md. The priority order is AGENTS.md, then AGENT.md, then CLAUDE.md — first match wins, and Continue does not merge multiple agent files even if more than one exists in the workspace root.

Does Continue.dev check subdirectories for AGENTS.md, like Claude Code’s hierarchical CLAUDE.md?

No. The fallback only checks the workspace root of the first workspace folder. There’s no per-directory or nested-file behavior, unlike Claude Code’s hierarchical CLAUDE.md loading.

Is config.json still usable?

Yes, but it’s deprecated. If a config.yaml file is present, it’s loaded instead of config.json — they don’t merge, and new Continue features are built against config.yaml going forward.

Does this apply to both the VS Code and JetBrains extensions?

Yes. The rule-loading logic lives in Continue’s shared core package, which both the VS Code and JetBrains extensions build on, rather than being duplicated per IDE.


Keep Secrets Out of Your Continue Config

AGENTS.md, config.yaml, and everything in .continue/rules/ are meant to be committed to version control — which makes all three the wrong place for a database URL, an API key, or any other credential you’d need while explaining how a service connects. It’s an easy mistake to make while writing setup instructions for an agent to follow.

The safer pattern: reference environment variable names in your rules (“read the API key from STRIPE_SECRET_KEY”), never the literal values, and keep the actual secrets in a password manager instead of a .env file that might get committed by accident. 1Password can inject secrets into your shell environment at runtime, so your Continue config — and the agent reading it — never sees a real credential in the first place.


Related Articles

Explore the collection

Browse all AI coding rules — CLAUDE.md, .cursorrules, AGENTS.md, and more.

Browse Rules