/model switch notices and error banners are stored as system-role messages and replayed mid-conversation, breaking strict chat templates

[garymarkowitz-source]

Before submitting your bug report

• I've tried finding an answer on the Continue docs site
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Windows 11
  - Continue version: CLI (cn) v1.5.47, interactive TUI mode
  - IDE version: n/a (CLI)
  - Model: qwen/qwen3.6-35b-a3b (Q6_K, lmstudio-community) via LM Studio; second provider
  OpenRouter
  - config: two providers in one config — LM Studio (local, OpenAI-compatible) + OpenRouter

Description

Summary

When switching models mid-session with /model, cn records its UI notices — Switched to model: <name> and even transport errors like Error: Connection error. — as system-role messages in the conversation history, and replays them to the server inside the messages array of every subsequent request.

Many chat templates hard-reject a system message anywhere but position 0. Qwen3's template contains:

{%- if message.role == "system" %}
    {%- if not loop.first %}
        {{- raise_exception('System message must be at the beginning.') }}
    {%- endif %}

so the first prompt after switching onto such a model fails with an HTTP 400 from LM Studio:

Unable to generate parser for this template. Automatic parser generation failed:
...
Error: Jinja Exception: System message must be at the beginning.

Every subsequent prompt to that model fails the same way for the rest of the session. /clear does not recover — the switch notice is re-injected (tested clearing both before and after the switch). Only restarting cn recovers.

The failure is easy to misdiagnose: whether it triggers depends on the destination model's template strictness (Qwen3.x Max via OpenRouter tolerates mid-history system messages; local Qwen3.6 35b does not), so it presents as "switching to my local provider breaks the session."

Related issue

#12963 reports the same defect class (a system-role message injected mid-conversation, rejected with the identical "System message must be at the beginning" error) with a different trigger — tool-request cancellation in the IDE extension. This report covers the CLI's /model switch and error-banner paths, which that issue's proposed fix (scoped to the cancellation handler) would not address.

Source pointer

extensions/cli/src/ui/hooks/useModelSelector.ts emits the switch notice as:

onMessage({
  role: "system",
  content: `Switched to model: ${modelInfo?.name}`,
  messageType: "system",
});

messageType: "system" suggests this was intended as a UI-only display classification, but role: "system" places it in the conversation history that gets replayed to the provider. The same pattern appears in useConfigSelector.ts, useChat.ts, and compaction.ts (likely the source of the replayed Error: Connection error. banners).

Evidence: captured request body

LM Studio's DEBUG log shows the request cn sent after several switches (trimmed; note the system entries between turns):

{
  "model": "qwen/qwen3.6-35b-a3b",
  "messages": [
    { "role": "system", "content": "You are an agent in the Continue CLI. ..." },
    { "role": "user", "content": "what is the solution name" },
    { "role": "assistant", "content": "", "tool_calls": [ "..." ] },
    { "role": "tool", "content": "...", "tool_call_id": "..." },
    { "role": "assistant", "content": "The solution file is ..." },
    { "role": "system", "content": "Switched to model: Qwen3.7 Max" },
    { "role": "user", "content": "what's the airspeed velocity of an unladen swallow?" },
    { "role": "assistant", "content": "African or European?" },
    { "role": "user", "content": "I don't know" },
    { "role": "assistant", "content": "You have been cast into the Gorge of Eternal Peril ..." },
    { "role": "system", "content": "Switched to model: Qwen3 Coder 30b" },
    { "role": "user", "content": "What's the airspeed velocity of an unladen swallow?" },
    { "role": "system", "content": "Error: Connection error." },
    { "role": "user", "content": "what is today's date" },
    { "role": "system", "content": "Error: Connection error." },
    { "role": "system", "content": "Switched to model: Qwen3.7 Max" },
    { "role": "user", "content": "what is today's date" },
    { "role": "assistant", "content": "Today is **July 25, 2026**." },
    { "role": "system", "content": "Switched to model: Qwen3.6 35b A3b" },
    { "role": "user", "content": "what is today's date" }
  ],
  "stream": true,
  "tools": [ "..." ]
}

A fresh session against the same model, config, rules, and tools works perfectly (tool calls included) — the defect is purely the mid-history system entries.

Suggested fix

Keep the display classification (messageType: "system") but stop assigning role: "system" to UI events — store switch notices and error banners as UI-only/display events excluded from the replayed history (or, if they should be model-visible, emit them as user-role context). A system message after position 0 is rejected outright by a growing set of chat templates, so any replayed system-role event breaks those models for the remainder of the session.

Workaround (for anyone else hitting this)

Either restart cn after switching onto a strict-template model, or edit the model's Jinja template in LM Studio so the non-first system branch renders '<|im_start|>system\n' + content + '<|im_end|>\n' instead of raising. Verified working — but it's per-model, local, and lost if the model is re-downloaded.

To reproduce

Steps to reproduce

1. Config with two chat models, at least one served by LM Studio with a strict template (any current Qwen3 works).
2. Start cn, send any prompt.
3. /model → switch to the strict-template model.
4. Send any prompt.

Expected: the new model answers.
Actual: 400 as above; model unusable until cn is restarted.

Log output

2026-07-25 18:03:46 [DEBUG]
   Received request: POST to /v1/chat/completions with body  {
    "model": "qwen/qwen3.6-35b-a3b",
    "messages": [
      ...
      { "role": "system", "content": "Switched to model: Qwen3.7 Max" },
      ...
      { "role": "system", "content": "Error: Connection error." },
      ...
      { "role": "system", "content": "Switched to model: Qwen3.6 35b A3b" },
      { "role": "user", "content": "what is today's date" }
    ],
    ...
  }
  2026-07-25 18:03:46  [INFO]
   [qwen/qwen3.6-35b-a3b] Running chat completion on conversation with 22 messages.
  2026-07-25 18:03:46  [INFO]
   [qwen/qwen3.6-35b-a3b] Streaming response...
  2026-07-25 18:03:47 [DEBUG]
   466.45.572.562 W srv    operator(): got exception: {"error":{"code":400,"message":"Unable
  to generate parser for this template. Automatic parser generation failed:
  \n------------\nWhile executing CallExpression at line 110, column 34 in source:\n...rst
  %}↵              {{- raise_exception('System message must be at the↵  beginn...\n
                                  ^\nError: Jinja Exception: System message must be at the\n
   beginn...","type":"invalid_request_error"}}
  2026-07-25 18:03:47 [ERROR]
   [qwen/qwen3.6-35b-a3b] Engine protocol predict request returned 400:
  {"error":{"code":400,"message":"Unable to generate parser for this template. Automatic
  parser generation failed: ...Error: Jinja Exception: System message must be at the\n
  beginning.","type":"invalid_request_error"}}. Error Data: n/a, Additional Data: n/a

[LHMQ878]

Traced this through the code — the report's diagnosis is right, and there's an already-open PR that covers the 400 you're hitting, plus one residual issue it doesn't address.

The 400 is already fixed in #12988 (open since 14 Jul, core/util/messageConversion.ts). That PR rewrites the exact function this path goes through — convertFromUnifiedHistoryWithSystemMessage, called from extensions/cli/src/stream/streamChatResponse.ts:253 — to hoist every system-role history item into a single merged system message at index 0, and its description explicitly names /model switch notices as one of the sources. So it isn't scoped to the cancellation handler the way #12963's title suggests; it fixes the class at the conversion boundary, which includes this trigger. Worth watching that PR rather than duplicating it.

Confirming the mechanism for the record. convertFromUnifiedHistoryWithSystemMessage on main pushes the real system message at index 0 and then splices in convertFromUnifiedHistory(historyItems) verbatim, and convertFromUnifiedMessage passes role: "system" straight through with no filtering — so any system-role history item lands at a non-zero index. That's the 400.

One thing #12988 doesn't solve. You correctly guessed that messageType: "system" was meant as a display-only classification. It's worse than that: messageType has no consumer anywhere in the codebase. It's declared and assigned in useModelSelector.ts (:21, :65, :81) and useConfigSelector.ts (:21, :61-104) and read nowhere — a dead field. So there is currently nothing separating "UI notice" from "instruction to the model."

Under #12988 that means UI noise gets merged into the system prompt instead of being rejected:

<real system prompt>

Switched to model: qwen/qwen3.6-35b-a3b

Error: Connection error.

and it stays there for every subsequent request in the session. No more 400, but the model is now being told, as part of its standing instructions, that a connection error occurred. Failed to switch model: ${error.message} (useModelSelector.ts:79-82) goes the same way.

The narrower fix would be to stop giving these a conversation role at all — they're already rendered from chatHistory for display, so the display path needs a role, but the wire path shouldn't see them. Either give messageType an actual consumer that filters at the conversion boundary, or drop them from the history and render notices from separate UI state.

Also worth noting: the same role: "system" + onMessage shape appears in 8 files under extensions/cli/src (useChat.ts, useChat.helpers.ts, useChat.compaction.ts, useChat.stream.helpers.ts, streamChatResponse.autoCompaction.ts, ChatHistoryService.ts, plus the two selectors), so anything scoped to one call site will leave the rest.

Happy to send a PR for the notice/instruction separation once #12988 lands — doing it before would conflict in the same function. @not-knope, flagging in case you'd rather fold it into #12988.

[not-knope]

Thanks for tracing this through — can confirm the diagnosis. #12988 should close the 400 you’re hitting since it rewrites convertFromUnifiedHistoryWithSystemMessage, the exact function this path calls into.
On the messageType dead-field issue: agree it’s worth a separate PR rather than folding into #12988, since that would mean touching the same function for two different concerns (fixing conversion vs. adding a consumer for classification). Happy to have it filed once #12988 merges — feel free to open it, or I can pick it up if you’d rather not.

[LHMQ878]

Thanks — and agreed on keeping it separate.

One thing worth flagging before I file it: I don't think waiting on #12988 is the right gate, because #12988 looks stuck on infrastructure rather than on review. Its actual test suite is green (27 success / 2 skipped), and the only red required check is the require-all-checks-to-pass aggregator. What's holding it is 12 Continuous AI: * statuses that are all failure — and those contexts appear on #12988 and nowhere else: recently merged PRs (#13004, #13005) and current open ones (#13037, #13042) carry only the two snyk statuses, no Continuous AI: * at all. So they look like a workflow that was live around Jul 14 and has since been retired; they won't re-run on their own, and #12988 has had no review in two weeks.

Since the two changes don't overlap in the diff at all — #12988 touches only convertFromUnifiedHistoryWithSystemMessage in core/util/messageConversion.ts and never mentions messageType — I'll file the messageType PR now rather than block on that. If #12988 lands first, mine rebases cleanly; if mine lands first, nothing in #12988 has to change.

While confirming the field is still dead on main (5522c6f), I found the two things worth putting in the PR description:

1. It isn't just an unused field — it's declared in the spec and unimplemented. extensions/cli/spec/wire-format.md:28 defines messageType as "tool-start" | "tool-result" | "tool-error" | "system", and :100 describes classifying tool messages by it. In the code there are exactly two assignment sites (useModelSelector.ts:65,81 and useConfigSelector.ts:61,67,78,97,104) and zero reads anywhere under extensions/cli/src.

2. The precise place it gets dropped is useTUIChatHooks.ts. Both onMessage callbacks receive the messageType: "system" the hooks set, and then build the history item without it:

   // useTUIChatHooks.ts:149-157 (useModelSelector branch)
   onMessage: (message) => {
     setChatHistory((prev) => [
       ...prev,
       {
         message: { role: "system", content: message.content },  // messageType discarded
         contextItems: [],
       },
     ]);
   },

   That's why the renderer has to fall back to message.role === "system" (MemoizedMessage.tsx:54) to decide how to draw it — which is the same reason a /model notice is indistinguishable from a real system instruction once it's in the history, and hence the 400 in this issue. So the dead field and this bug have a common cause, which is a good argument for the consumer actually being wired up rather than the field being deleted.

I'll take it, no need to pick it up on your side. Will link it here once it's open.

[LHMQ878]

Filed as #13046 — took it as offered, so no need to pick it up on your side.

Scoped strictly to extensions/cli: it keeps the messageType the selector hooks already set (useTUIChatHooks.ts was dropping it) and filters notices out at streamChatResponse.ts:253, just before the conversion. core/util/messageConversion.ts is untouched, so there is no overlap with #12988 in either direction.

The end-to-end test asserts on what actually reaches chatCompletionStream, and the control experiment (reverting only the consumer wiring) gives expected [...] to have a length of 1 but got 2 — the two-system-message shape from this issue, now covered.

[garymarkowitz-source]

Thanks both — and thanks for tracing it to the conversion boundary, that matches what the captured payload showed.

One gap worth flagging before #13046 gets reviewed, since it affects my original repro. The filter keys on messageType, which only the two selector hooks set. On main (5522c6f) the other notice sites still push a bare role: "system" item with no discriminator:

• useChat.ts:342-353 — `Error: ${formatError(error)}` — this is exactly where the {"role":"system","content":"Error: Connection error."} in my attached payload comes from
• useChat.ts:839 — the tool-cancel notice, i.e. Malformed Message After Tool Request Cancellation #12963's own trigger
• useChat.helpers.ts (tool output, diff), useChat.compaction.ts, streamChatResponse.autoCompaction.ts, ChatHistoryService.addSystemMessage()

So as scoped, #13046 drops the "Switched to model" line but leaves the error banner sitting beside it in my payload — my repro is only half fixed, and #12963's trigger isn't covered at all. With #12988 also landed those stop returning a 400, but they end up merged into the standing system prompt instead, which is the outcome flagged above.

I have a live strict-template setup here — LM Studio serving Qwen3.6 35b A3b, whose Jinja template raises System message must be at the beginning on any mid-history system message, which is what surfaced this. Happy to build and run either PR end-to-end against it and report back; that path catches leaks a mock can't, since anything that slips through fails loudly rather than silently.

Could a maintainer take a look at the labels here? Both PRs are from outside contributors and #12988 has had no review since 14 Jul.

[ryan-adtronics-llc]

@garymarkowitz-source

Could a maintainer take a look at the labels here? Both PRs are from outside contributors and #12988 has had no review since 14 Jul.

Continue was acquired by Cursor, so this repository is no longer active. They converted it to read-only. Somebody will need to gain momentum on a fork and take on maintaining this project for it to survive as open source.

https://continue.dev/

[LHMQ878]

@garymarkowitz-source You're right, and the gap is bigger than one site — thanks for catching it before review rather than after.

I went through every role: "system" push under extensions/cli/src on main (5522c6f) and classified them. Excluding tests, mocks, and the two places that construct a genuine system message rather than a notice — serve.ts:145 (the configured system prompt seeding an empty history) and autoCompaction.ts:181 (a throwaway item built only to count tokens) — there are 23 notice sites, and only 7 carry messageType:

File	Notice sites	messageType?
ui/hooks/useModelSelector.ts	2	✅
ui/hooks/useConfigSelector.ts	5	✅
ui/hooks/useChat.ts	2	❌
ui/hooks/useChat.helpers.ts	3	❌
ui/hooks/useChat.compaction.ts	3	❌
ui/hooks/useChat.stream.helpers.ts	2	❌
stream/streamChatResponse.autoCompaction.ts	2	❌
services/ChatHistoryService.ts	1	❌
ui/TUIChat.tsx	3	❌

So #13046 as scoped covers 7 of 23. Since withoutUiNotices keys on messageType and nothing else — deliberately, because a notice and a real system instruction are indistinguishable by role alone — the other 16 pass straight through. Your two are confirmed exactly as you described:

• useChat.ts:349 — the `Error: ${formatError(error)}` in the catch around session save. This is the {"role":"system","content":"Error: Connection error."} in your payload.
• useChat.ts:841 — [Tool canceled - please tell Continue what to do differently], i.e. Malformed Message After Tool Request Cancellation #12963's trigger, which as you say isn't covered at all.

(Small note for anyone following the paths: these are under extensions/cli/src/ui/hooks/, not src/hooks/. Line numbers are as you gave them.)

The rest are the same shape and equally user-facing: Diff:\n… and command output in useChat.helpers.ts, Chat history compacted successfully. / Compaction cancelled. / Compaction failed: … in useChat.compaction.ts, Session exported to … / Failed to export: … in TUIChat.tsx. None of those are instructions to the model, and all of them currently reach the provider.

ChatHistoryService.addSystemMessage() is worth calling out separately, because it's the one that can't be fixed by annotating a call site. useChat.stream.helpers.ts:220's onSystemMessage prefers the service and only falls back to local state, so notices routed through it are created inside createHistoryItem with no way for the caller to attach a discriminator. That one needs either a parameter or a sibling addNotice().

On how to close the gap. I'd rather not widen isUiNotice to guess from role/content — that's how a real system instruction eventually gets dropped, which is a worse failure than the one we're fixing (silent, and it changes model behaviour instead of erroring). Two honest options:

1. Annotate all 23 sites (plus a way through addSystemMessage), keeping the discriminator as the single source of truth. More diff, no guessing, and spec/wire-format.md:28 already defines the field — it just needs to be set everywhere and read once.
2. Keep notices out of chatHistory entirely and render them from separate UI state, which is the structural fix I floated earlier. Bigger blast radius, and it touches the renderer's message.role === "system" fallback at ui/components/MemoizedMessage.tsx:54.

I'll take (1) and push it onto #13046 — it's mechanical, it's verifiable per-site, and it makes your repro pass in full rather than halfway. If a maintainer prefers (2) I'll happily redo it, but (1) is the one that can be reviewed line by line.

And yes please to the end-to-end run. A strict-template model that raises System message must be at the beginning is a much better oracle than my mocks — anything that leaks fails loudly instead of silently, which is exactly the property my test can't have. Ping me when #13046 has the remaining sites and I'll flag it here; if you can run your Qwen3.6 35b A3b setup against that branch and confirm your original repro is clean end to end, that's stronger evidence than anything in CI.

One caveat on expectations, since it affects whether this is worth your time: @ryan-adtronics-llc's note above says the repo is read-only, and that part isn't accurate — the GitHub API still reports archived: false and the repo accepts pushes and PRs. But the activity picture does support "effectively unmaintained": the last commit is #13005 on 21 Jul, there have been no merges in the eight days since, and of the last 15 closed PRs only 2 were merged this month. So the technical conclusion may end up mattering more than the merge. I'd still rather leave it correct and complete here than half-fixed.