Copilot Chat auto-steers In Progress on new message instead of queueing to To Do

[arviphd]

Summary

When I click Send in Copilot Chat, a second user message automatically changes what is In Progress instead of being added to To Do queue only. I need queue-first behavior where In Progress changes only on explicit user instruction.

Environment

• OS: Windows
• Editor: VS Code
• Copilot Chat extension: github.copilot-chat-0.45.1
• Agent mode: Auto

Steps to reproduce

1. Start a chat with an active In Progress item.
2. Send a new message that should be queued as a new To Do.
3. Observe task state after send.

Expected behavior

• New message is added to To Do queue.
• Current In Progress item remains unchanged.
• In Progress changes only when explicitly requested by the user.

Actual behavior

• New message auto-steers and changes In Progress.

What I already tried

• Added user-level instruction file for queue behavior.
• Verified instruction-loading settings are enabled:
  • github.copilot.chat.codeGeneration.useInstructionFiles = true
  • github.copilot.chat.promptFileContextProvider.enabled = true
  • github.copilot.chat.customInstructionsInSystemMessage = true
  • github.copilot.chat.organizationInstructions.enabled = true
• Behavior still auto-steers.

Impact

• Interrupts ongoing work.
• Causes context switching and accidental focus changes.
• Reduces trust in queued task workflows.

Feature request

Please add a first-class setting to control this behavior, for example:

• Queue new messages without changing In Progress
• Change In Progress only on explicit user command

Suggested settings

• github.copilot.chat.taskQueue.autoSteerOnNewMessage: false
• github.copilot.chat.taskQueue.requireExplicitInProgressSwitch: true

[arviphd]

Additional context:

Repro is consistent on Windows with VS Code + Copilot Chat extension 0.45.1.
Behavior here: sending a second chat message auto-switches In Progress instead of queueing as To Do.
Expected behavior: new messages should enter To Do queue only; In Progress should change only on explicit user request.
I tested with user instruction files and confirmed instruction-related settings are enabled, but behavior still auto-steers.
For comparison, queue-preserving behavior (new message added to queue without auto-switching current in-progress work) is the default behavior in Codex/Cursor workflows.
Feature ask:

Please add a first-class setting to control this explicitly, e.g.:
queue new messages without changing In Progress
require explicit user command to switch In Progress