* mcp: prevent duplicate collection registrations on extension host restart
Fixes duplicate tool registration when MCP server definition providers
have a 'when' clause in their package.json. The issue occurred because
ExtensionMcpDiscovery and MainThreadMcp both independently managed
collection registration with 'when' clauses, and on extension host
restart the registry would end up with duplicate non-lazy collections.
- Modified registerCollection() to return early (Disposable.None) if a
non-lazy collection with the same ID is already registered, preventing
duplicates
- Preserve lazy-to-non-lazy replacement behavior for proper collection
lifecycle management
- Prevents scenarios where servers accumulate in the registry across
EULA restarts
Fixes https://github.com/microsoft/vscode/issues/284024
(Commit message generated by Copilot)
* add tests
Fixes the incorrect use of 'if' instead of 'else if' in the tool invocation
state transition logic. This ensures that the confirmation check is only
performed when autoConfirmed is falsy, preventing logic errors during tool
invocation processing.
Fixes https://github.com/microsoft/vscode/issues/291453
Fixes https://github.com/microsoft/vscode/issues/290250
(Commit message generated by Copilot)
* thinking header fix: styling and better generic text
* only increment in constructor if there is thinking text
* reset the timer, accidentally set to 1 for testing
Adds display of a localized 'Approve tool result?' message when a chat
response is waiting for post-approval confirmation on a tool invocation.
- Updates ChatResponseModel to detect WaitingForPostApproval state
- Displays appropriate confirmation message to user during tool approval
- Improves UX by providing clear feedback on what action is needed
(Commit message generated by Copilot)
* feat: implement auto-resize for freeform textarea in chat question carousel
* fix: use auto exapnding textarea for all freeform input
* review comments
* fix: tests
## Problem
The `_tryRebase` method could produce edits that violate the sorted/disjoint
invariant required by `StringEdit`, causing a `BugIndicatingError` to be
thrown with the message:
`Edits must be disjoint and sorted. Found [X, X) -> "..." after Y`
## Root Cause
When a base edit deletes significantly more characters than it inserts
(creating a negative offset), subsequent "our" edits can get transformed
to positions that conflict with previously-added edits.
Example scenario:
1. `ourEdit1`: [100, 110) → "A" — added to result, ends at position 110
2. `baseEdit`: [110, 125) → "" — deletes 15 chars, offset becomes -15
3. `ourEdit2`: [120, 120) → "B" — transforms to [105, 105) after offset
Problem: Position 105 is BEFORE 110 (the end of `ourEdit1`), violating
the invariant that edits must be sorted and disjoint.
The original code only checked for direct intersections with base edits,
but missed this case where the cumulative offset transformation causes
an "our" edit to land before the end of a previously-added "our" edit.
## Fix
Track the exclusive end position of the last added edit (`lastEndEx`) and
before adding each transformed edit, verify that its start position is not
before `lastEndEx`. If it is:
- When `noOverlap=true` (tryRebase): return `undefined`
- When `noOverlap=false` (rebaseSkipConflicting): skip the conflicting edit
## Behavior Changes
- `tryRebase()`: Now returns `undefined` for cases that previously crashed
- `rebaseSkipConflicting()`: Skips conflicting edits instead of crashing
- `trySwap()`: Uses `tryRebase` internally, handles edge cases gracefully
These are safe changes since the previous behavior was to throw an error.
Callers of `tryRebase()` already handle `undefined` returns, and
`rebaseSkipConflicting()` is expected to drop conflicting edits.
Rob Lourens
Daniel Imms
Justin Chen
Matt Bierner
Henning Dieterichs
Copilot
Dmitriy Vasyura
Connor Peet
Paul
Sandeep Somavarapu
Raymond Zhao
dileepyavan
dependabot[bot]
Benjamin Pasero
João Moreno
Eleanor Boyd
Karthik Nadig
Megan Rogge
ulugbekna
Lee Murray