* Refactor hook execution
* Fix compilation: add IExtHostHooks import, remove unused IHookResult, inline ChatRequestHooks type
* Move hooks property to chatHooks proposal, sync DTS
* cleanup
* Remove dead hook execution code: proxy, RPC, output channel, progress events
All hook execution now happens in the extension via NodeHookExecutor.
HooksExecutionService is now a pure registry (registerHooks/getHooksForSession).
Removed:
- executeHook, setProxy, onDidHookProgress from service
- IHooksExecutionProxy, IHookProgressEvent, HookAbortError, formatHookErrorMessage
- hooksCommandTypes.ts, hooksTypes.ts (dead type files)
- mainThreadHooks proxy setup
- extHostHooksNode., extHostHooksWorker.
- ExtHostHooksShape. protocol
- IExtHostHooks DI registrations
- ChatHooksProgressContribution
- All associated test files
* Remove HooksExecutionService entirely
The service was only a registry for session hooks, but hooks are already
passed directly on the chat request DTO. The registerHooks/getHooksForSession
pattern was redundant.
* Restore modelName support in chatSubagentContentPart that was accidentally removed during merge
* Revert unrelated tabIndex change on chatSubagentContentPart
* Remove empty hooks ext host infrastructure
Delete IExtHostHooks, NodeExtHostHooks, WorkerExtHostHooks,
MainThreadHooks, ExtHostHooksShape, MainThreadHooksShape -
all were empty stubs after hook execution moved to extension.
* Remove mainThreadHooks import from extensionHost.contribution
* Fix DTS comments: env and timeoutSec are values, not implementation promises
* hooks streaming first pass
* Update src/vs/workbench/contrib/chat/browser/widget/chatContentParts/chatHookContentPart.ts
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* update styling
* modify api shape
* address some comments + do not render for now
* new icons + no more continue
* make sure we render right, some comments addressed
* uncomment that stuffs
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Includes public API, user setting, status bar icon and a new service to support metered network connections.
Updates code in various areas performing automated actions using network to delay/pause network operations while network connection is being metered.
Disabled protocol handlers and registry updates on Windows in portable mode.
Added API proposal to detect if VS Code is running in portable mode from extensions.
Skipped protocol redirect in GitHub authentication in portable mode.
* chat: support representing file deletions in edit sessions
Add support for file deletion operations in chat editing sessions through
new ChatResponseWorkspaceEditPart. This allows agents to represent file-level
operations (deletions, creations, renames) alongside text and notebook edits.
- Adds ChatEditingDeletedFileEntry class to represent deleted files with
proper diff display and restoration functionality
- Introduces ChatResponseWorkspaceEditPart and IChatWorkspaceEdit interfaces
for file-level operations at the workspace level
- Implements workspace edit streaming through chat editing sessions with
proper undo/redo support
- Adds ChatWorkspaceEditContentPart for UI rendering of file operations
- Extends chat session storage to serialize deleted file entries
- Supports both acceptance and rejection of file deletions with proper state
management and snapshotting
Ref https://github.com/microsoft/vscode/issues/275705
(Commit message generated by Copilot)
* fix test
This reverts commit 17523c000e
Skips the api version bump this time since it's not needed
Breaking API change since `created` is now required but won't actually break at runtime
* Revert "Merge pull request #287668 from mjbvz/dev/mjbvz/eventual-sparrow"
This reverts commit 81f7af4b9f, reversing
changes made to 85a14f966c.
* Revert "Merge pull request #286642 from microsoft/dev/mjbvz/chat-session-item-controller"
This reverts commit b39ecc3960, reversing
changes made to 45aced5935.
This is a rethinking of the initial API proposed in `languageModelToolSupportsModel.d.ts`.
1. This switches to `models?: LanguageModelChatSelector[];` to control enablement.
definitely open to switching this out, but I think a synchronously-analyzable
expression is important to retain the data flows in core without too many races.
2. The extension is able to define a tool at runtime via registerToolDefinition. This
should let us have entirely service-driven tools from model providers without
requiring a static definition for each one. We can also have model-specific
variants of tools without a ton of package.json work for each variant of the tool
(as initially proposed using `when` clauses)
This then propagates that down into the tools service. Currently I have this as just
compiling to a `when` expression once it reaches the main thread. Then, for the tools
service, it takes an IContextKeyService in cases where tools should be enumerated,
and the chat input sets the model keys in its scoped context key service. This allows
the tools to be filtered correctly in the tool picker.
I initially thought about allowing multiple definitions be registered for the same tool
name/id for model-specific variants of tools but I realized that gets really gnarly and
we already have a `toolReferenceName` that multiple tools can register into.
Todo for tomorrow morning:
- Tools don't make it to the ChatRequest yet, or something, still need to investigate
- Need to make sure tools in prompts/models all work. For a first pass I think we can
let prompts/modes reference all tools by toolReferenceName.
- Validate that multiple tools actually can safely share a reference name (and do
some priority ordering?)
- General further validation
- Some unit tests
