Repository navigation
feat(tools): add visual studio terminal tools #103
Description
Part of #95.
Add tools for running commands in the Visual Studio integrated terminal.
Proposed tools
| Tool | Behavior |
|---|---|
terminal_create |
Create a terminal (optional name, profile, working directory) |
terminal_list |
List open terminal instances |
terminal_send |
Send a command to a terminal |
terminal_show |
Bring a terminal into view |
terminal_close |
Close a terminal |
Implementation notes
ITerminalService is a brokered service — moniker Microsoft.VisualStudio.Terminal.TerminalService, obtained via TerminalServiceDescriptors.TerminalServiceDescriptor:
Task<Guid> CreateTerminalAsync(CancellationToken ct, string name, ProfileConfig profile, string workingDirectory);
Task AttachTerminalStreamAsync(Guid terminalGuid, Stream stream, CancellationToken ct);
Task<IEnumerable<Guid>> GetTerminalGuidsAsync(CancellationToken ct);
Task<...> GetProfilesAsync(CancellationToken ct);
Task ShowAsync(Guid terminalGuid, ...);
Task CloseAsync(Guid terminalGuid, ...);
Task CloseAllInstancesAsync(CancellationToken ct);
Task ResizeAsync(Guid terminalGuid, ...);AttachTerminalStreamAsync gives a bidirectional stream — write commands in, read output back.
Public surface is identical between VS 2022 17.14 and VS 2026 18.0. Microsoft.VisualStudio.Terminal has both a binding redirect and a codeBase entry in devenv.exe.config in both versions, so referencing it from the VS install directory resolves cleanly.
Important limitation
This is a raw PTY stream: ANSI escape sequences, no command boundaries, no exit codes. It is good for "run this and let the user watch it happen in VS" and bad for "run this and tell me whether it succeeded."
Recommendation: treat this as a visibility feature, and add a separate process-execution tool (plain System.Diagnostics.Process) for cases where the agent needs a real exit code and clean stdout/stderr. The original ask in #95 was to run things like OpenCover and read the result — that use case wants the process tool, not this one.
Worth deciding up front whether both ship, or only the process tool. Splitting that out if we go that route.
Activity
CalvinAllen commentedon Sep 3, 2026
Correction to my own note above, found while implementing #101/#102 (merged in #105).
I wrote that
Microsoft.VisualStudio.Terminal"has both a binding redirect and acodeBaseentry indevenv.exe.configin both versions, so referencing it from the VS install directory resolves cleanly." Those facts are right but they govern runtime assembly resolution — they say nothing about whether the project can compile against the assembly, which is the actual blocker:$(DevEnvDir)is only defined when building from a Visual Studio / developer command prompt context. This repo builds withdotnet buildlocally and in CI (vsix-build.ymlstep 3), so a HintPath off$(DevEnvDir)breaks the build outright.Microsoft.VisualStudio.Terminalis also not on NuGet and not in theMicrosoft.VisualStudio.SDKmetapackage.Use the pattern established in #105: resolve
ITerminalServiceby MEF/brokered-service contract name and access it reflectively, perServices/TestExplorerInterop.cs. The alternative considered and rejected was an MSBuild target shelling out tovswhere, which would make a Visual Studio installation a hard build prerequisite — it currently isn't one.ITerminalServiceis a brokered service rather than a MEF export, so it comes throughIBrokeredServiceContainer/ServiceRpcDescriptorrather thanDefaultExportProvider. The reflection approach is the same shape, but it is not a copy-paste of the stats service — worth budgeting for.Everything else in the issue stands: the method signatures, the identical surface across VS 2022 and VS 2026, and the raw-PTY limitation (no exit codes, no command boundaries) that argues for a separate process-execution tool.