mirror of
https://github.com/cline/cline.git
synced 2026-09-19 02:05:44 +08:00
* Rationalize shell identification and prompting, especially on Windows.
* Probe all pwsh install locations for the Windows default shell.
The default-shell fallback only checked the Program Files pwsh path,
so Microsoft Store installs of PowerShell 7 fell back to Windows
PowerShell while VS Code's own terminal launched pwsh. Share one
candidate list between the sync default-shell check and the async
PowerShell prober. Also drop an 'as string' cast that hid the
setting's type from the checker.
* Address shell resolution review feedback
* Resolve array-valued terminal profile paths on macOS and Linux too
VS Code permits terminal profile 'path' to be string | string[] on every
platform, not just Windows. The resolver (env expansion, first-existing
selection, PATH lookup) is now platform-generic: it uses the host path
module's separators and delimiter, probes PATHEXT only on Windows, and
treats env var names case-insensitively only on Windows. The macOS and
Linux getters route through it instead of returning the raw config value,
which crashed getShellKind() for array values.
* Apply terminal profile changes at the model-request boundary
A terminal profile change previously triggered a deferred session rebuild
to refresh the run_commands tool description. While a task was running the
rebuild waited, so the description could name one shell while commands
executed in another for the rest of the turn.
Instead of rebuilding, createShellTool now accepts a shell provider
function and re-derives the description each time the runtime reads it,
which happens exactly when a model request is built. The VS Code tool
snapshots {profileId, shell} in that provider; both execution paths (the
background spawn and the foreground terminal, via a new profile parameter
on getOrCreateTerminal) consume the snapshot. Commands produced by an
in-flight inference therefore run with the shell the model was told about,
and a mid-turn profile change takes effect when the tool results are sent
back: the next request names and uses the new shell.
The profile-change session rebuild path (handleTerminalProfileChanged) is
removed along with its deferred-rebuild window.
* Use the real createShellTool in the vitest @cline/core stub
The stub's hand-rolled createShellTool duplicated the 'shell must be a
string' invariant instead of exercising the code that enforces it
(getShellKind via description building), so the array-valued-profile
regression test proved only that the stub threw, not that the real tool
survives. Re-export the real implementation from SDK source — the same
pattern the stub already uses for the apply-patch and editor executors —
and assert on the actual generated descriptions, including that a profile
change is reflected at the next description read.
* Harden shell profile path resolution edge cases
- Warn and skip profile paths containing variable references beyond
\ (e.g. \) instead of silently probing a
literal path that can never exist; later candidates and the platform
default still apply.
- Document that an overriding bash executor in createBuiltinTools bypasses
the resolved canonical shell and must honor it to keep the run_commands
description truthful.
The file is empty.