feat(extensions): an extension's context file is unconditionally resident, with no path gating, budget, or attribution #12030

Part of #12028. Closely related to #11631, which asks for the same thing from the workflow side.

What happens today

Every active extension's context file is concatenated into the system prompt of every request, with no relevance gating of any kind:

1. packages/core/src/extension/extensionManager.ts:1710-1714 — resolve contextFileName per extension, filtered only by fs.existsSync.
2. packages/core/src/config/config.ts:8958-8966 — flat-map contextFiles over getActiveExtensions(). The only filter is "extension is active".
3. packages/core/src/memory/memoryDiscovery.ts:201-204 — added unconditionally to the QWEN.md hierarchy.
4. memoryDiscovery.ts:385-406 — concatenated verbatim, no size cap.
5. packages/core/src/core/prompts.ts:698-706 — injected as the contextFiles layer.

There is no path gating, no per-extension budget, no truncation, no attribution, and no way to opt one extension's context out short of deactivating the extension entirely.

Why it matters

In a real session with nine active extensions, their context files totalled 9,989 tokens — 21% of all non-conversation context, present on every request regardless of what the session was doing. Sizes, largest first:

2,164  1,602  1,548  1,487  1,124  1,078  650  172  164

The distribution is the point: two extensions account for a third of the total, and nothing in the system tells their authors that. The remaining context-file budget in the same session was 4,021 tokens of project QWEN.md, 1,180 of auto-memory and 210 of an output-language file — so extensions were the majority of the always-on context layer, at 65% of it.

The same session listed 84 skills for a combined 4,620 tokens — about 55 tokens each, with bodies loaded on demand. Nine context files cost more than twice what eighty-four skills cost.

The same extensions already ship skills. A skill costs 100–200 tokens in the listing and loads its body only when invoked, and SkillConfig.paths (packages/core/src/skills/types.ts:155-157) gates it out of the listing entirely until a tool call touches a matching file (packages/core/src/skills/skill-activation.ts:42-56). So the eager path and the lazy path carry overlapping content, and the eager one is 10–20x more expensive per extension.

Two more asymmetries point the same direction:

• .qwen/rules/ supports paths:-conditional context (packages/core/src/config/rulesDiscovery.ts:7-15), but loadRules() scans only <QWEN_HOME>/rules/ and <projectRoot>/.qwen/rules/ (:305-324) — extensions cannot contribute rules.
• The newer agent-plugins-v1 format skips contextFileName altogether (extensionManager.ts:1702-1705) and ships skills only. The decision has effectively already been made for plugins; classic extensions never got it.

Suggestions

Any one of these would help; they are not exclusive.

1. Let an extension's context file carry paths: frontmatter, reusing the rules/skill activation machinery, so it only enters the prompt when relevant.
2. Let extensions contribute .qwen/rules/-style conditional rules.
3. Document the migration — "put scenario-specific guidance in a paths:-gated skill, keep only always-true facts in the context file" — and say it in the extension authoring docs, since today nothing signals that a context file is the expensive option.
4. Attribute and warn per extension. The existing warning (config.ts:4702-4727) is a single aggregate line that names no file; with nine extensions it cannot tell an author their extension is the problem. See Percentage-of-context-window budgets scale the wrong way: ToolSearch preload never engages, and the always-on context warning never fires, on large windows #12029 for why the threshold also never fires on large windows.

2,164  1,602  1,548  1,487  1,124  1,078  650  172  164