[Bug] "System" Prompt is sent as "User"

[vovler]

When the extension reconstructs the messages in convert.ts, specifically in the role handling in func mapRole, system is never an option and default is set to "user", VSCode's internal LanguageModelChatMessageRole only returns role ids for user and assistant too. The "tool" role seems to be set in some other manner (I didn't dive deeper), as it's being set correctly.

This results in the role system being set as role user (image below) which may lead to the model treating the system instructions as just another conversational turn rather than binding rules, making it more likely to ignore them, make it more susceptible to context window pollution and degraded tool performance. That said, the impact is probably model dependent. How strictly DeepSeek enforces the system role vs. treating a user message as authoritative, and how DeepSeek treats the system role when it comes to it's attention techniques (CSA, HCA, Sliding Window, Attention Sink). Without benchmarks, this is only a plausible concern, not a proven effect.

VSCode internal LanguageModelChatMessageRole

	/**
	 * Represents the role of a chat message. This is either the user or the assistant.
	 */
	export enum LanguageModelChatMessageRole {
		/**
		 * The user role, e.g the human interacting with a language model.
		 */
		User = 1,

		/**
		 * The assistant role, e.g. the language model generating responses.
		 */
		Assistant = 2
	}

deepseek-v4-for-copilot/src/provider/convert.ts

Line 113 in 30dae47

function mapRole(role: vscode.LanguageModelChatMessageRole): 'user' | 'assistant' {

function mapRole(role: vscode.LanguageModelChatMessageRole): 'user' | 'assistant' {
	switch (role) {
		case vscode.LanguageModelChatMessageRole.User:
			return 'user';
		case vscode.LanguageModelChatMessageRole.Assistant:
			return 'assistant';
		default:
			return 'user';
	}
}

Resulting in

A potential fix could be forcefully set the first message of any chat as a system prompt.

[Vizards]

Good catch, and thanks for the detailed write-up.

I’ve gone back and forth on this setting a few times too. The tricky part is that VS Code’s public/stable LanguageModelChatMessageRole typing only exposes User and Assistant, even though there is a internal System = 3 role. I also haven’t found a clear public discussion that fully documents how Copilot Chat expects third-party language model providers to handle that value.

On the DeepSeek side, the Chat Completions API does accept role: "system", but I haven’t found documentation that clearly states how much differently DeepSeek treats a system message at the model layer compared with an initial user message, especially around instruction priority, attention/caching behavior, or tool-use reliability. In practice, I also haven’t observed an obvious regression from sending that first prompt as user, but I agree that this is more of an empirical observation than proof.

So yes, this is a valid thing to flag. I’ll look into mapping VS Code’s internal/proposed System = 3 role to DeepSeek’s system role directly, which seems cleaner than blindly forcing the first message to system.

[vovler]

Models usually undergo post training to avoid prompt injections, specially since the agentic rise, and other types of requests where they have to act adversarial to user requests, so the system role adherence is probably better than user.

Had no clue they had a id of 3 for system, if they do then yes thats a cleaner alternative 👍