* Fix local CLI install to rebuild cleanly
* fix(install): copy package.json for standalone startup
Ensure the extension package.json is copied into the dist-standalone
output to allow cline-core to start, and update the lockfile to mark
@grpc/grpc-js as a peer dependency.
* feat(terminal): add shared terminal types and interfaces
Add shared terminal module with types and interfaces that enable
terminal management across VSCode, CLI, and JetBrains environments.
- Define ITerminal, ITerminalManager, and TerminalInfo interfaces
- Add TerminalProcessResultPromise for async command execution
- Include StandaloneTerminalOptions for non-VSCode environments
- Prepare module structure for standalone implementations
* feat(terminal): export standalone terminal implementations
Enable exports for standalone terminal classes that were previously
commented out as placeholders:
- StandaloneTerminal
- StandaloneTerminalManager
- StandaloneTerminalProcess
- StandaloneTerminalRegistry
These implementations are now ready for use outside the terminal module.
* fix: resolve TerminalInfo type incompatibility in settings update
- Remove unused TerminalInfo import from both updateSettings files
- Use `as any` cast to handle type mismatch between VSCode and standalone TerminalInfo
- Replace busyTerminals array with busyTerminalsCount to avoid type issues
- Add null-safe access when getting busy terminals length
* feat: import StandaloneTerminalManager from bundled cline-core
Replace standalone enhanced-terminal.js with import from the bundled
TypeScript version in cline-core.js. This consolidates terminal
management code and removes the need to separately include the
runtime file in the VS Code extension package.
- Re-export StandaloneTerminalManager from cline-core.ts
- Update vscode-impls.js to import from cline-core.js
- Remove .vscodeignore exception for enhanced-terminal.js
* feat: simplify standalone terminal manager initialization
Replace global injection pattern with environment variable detection
for determining terminal execution mode. The Task class now directly
instantiates StandaloneTerminalManager when IS_STANDALONE=true instead
of relying on a globally injected instance.
- Remove StandaloneTerminalManager re-export from cline-core.ts
- Simplify vscode-impls.js createTerminal to return stub object
- Use IS_STANDALONE env var for terminal manager selection in Task
- Remove global.standaloneTerminalManager injection pattern
* Fix Standalone build
* Fix Standalone build
* fix: use subagentTerminalOutputLineLimit in StandaloneTerminalManager.processOutput
Match the VSCode TerminalManager logic to properly use subagentTerminalOutputLineLimit (2000) for subagent commands instead of always falling back to terminalOutputLineLimit (500).
* feat: add TerminalManager to HostProvider for dependency injection
- Add TerminalManagerCreator type and createTerminalManager to HostProvider
- Extract ITerminalManager interface to shared/terminal/types for abstraction
- Refactor TerminalManager to implement ITerminalManager interface
- Create StandaloneTerminalManager for non-VSCode environments
- Update TerminalRegistry to use ITerminalManager via HostProvider
- Enable terminal management to work across different host environments
* feat: refactor terminal manager to use ITerminalManager interface
- Replace concrete TerminalManager/StandaloneTerminalManager types with ITerminalManager interface
- Use HostProvider.createTerminalManager() for host-agnostic terminal creation
- Simplify terminal execution mode logic in Task constructor
- Add dynamic imports for StandaloneTerminalManager when backgroundExec mode is used
- Improve logging for terminal manager selection
* fix(terminal): Add shell option for cmd.exe to prevent double quote escaping
Added shell: true option specifically for cmd.exe to prevent double quotes
from being over escaped during command execution. This resolves Windows-specific
issues with terminal command handling while maintaining compatibility with
other shells.
* chore: Add changeset for terminal command execution fix
Remove /s flag and extra quoting from cmd.exe shell arguments.
The previous approach with /s /c and quoted command was causing
issues with proper command execution in Windows cmd.exe.
* refactor(task): improve background command cancellation with better error handling
Enhance the cancelBackgroundCommand method with:
- Consolidated early return conditions for cleaner code
- Proper async/await for process termination
- Comprehensive error handling with try-catch blocks for each operation
- Improved logging for termination success/failure scenarios
- Updated cancellation notification message
- Use finally block to ensure notification is always sent
Improve StandaloneTerminalProcess.terminate() with:
- Better guard clauses and early returns
- Enhanced error handling for SIGTERM and SIGKILL operations
- More detailed logging for graceful vs forced termination
- Fallback to SIGKILL if SIGTERM fails immediately
Fix critical issue where terminate() method was not accessible on the merged promise object returned by executeCommand, preventing Task.cancelBackgroundCommand() from properly killing background processes.
* Fix: add cancel ui
* Fix: add cancel ui
* Fix: add cancel ui
* Fix: add cancel ui
Fixes#7470
When Terminal Execution Mode is set to "Background Exec", commands with
double quotes were being incorrectly escaped on Windows cmd.exe, causing
commands like `echo "\""` or `type "test.txt"` to fail.
The issue was that cmd.exe requires the /s flag and outer quotes when
passing commands with special characters via spawn(). Changed from
`["/c", command]` to `["/s", "/c", `"${command}"`]` for cmd.exe only.
This is a minimal Windows-specific fix that:
- Only affects Windows cmd.exe (PowerShell and Unix shells unchanged)
- Uses standard Windows cmd.exe syntax for proper quote handling
- No changes to process execution flow or behavior
* Fix check for debug build in package-standalone script
* Support node modules that include binaries
Add support to the scripts/package-standalone.js for node modules that use platform-specific binary modules.
By default the script bundles the module for all platforms, this can be disabled with -s for single platform builds.
The module for each platform will be bundled into standalone.zip in platform specific directories:
```
binaries/linux-arm64/node_modules
binaries/darwin-x64/node_modules
binaries/win32-x64/node_modules
binaries/darwin-arm64/node_modules
binaries/linux-x64/node_modules
```
When running cline-core add the correct directory to the NODE_PATH, e.g.
```
$ export NODE_PATH=./node_modules/:./binaries/darwin-arm64/node_modules/
cline:/tmp/1$ node cline-core.js
Loading stubs...
Finished loading stubs
Loading stub impls...
Finished loading stub impls...
Cline environment: production
XS variant configuration warnings: [
'Component overrides for unused components: TOOL_USE_SECTION, TOOLS_SECTION, MCP_SECTION, TODO_SECTION, FEEDBACK_SECTION',
'Missing recommended components: TOOL_USE_SECTION'
]
[2025-09-05T19:53:00.853] #bot.cline.server.ts Running standalone cline 0.0.1
[2025-09-05T19:53:00.854] #bot.cline.server.ts Using settings dir: /Users/sjf/.cline/data
Finished loading vscode context...
[2025-09-05T19:53:00.858] #bot.cline.server.ts
Starting cline-core service...
sjfsjf created DBBBBBBBBB: Database {
name: '/tmp/db.sql',
open: true,
inTransaction: false,
readonly: false,
memory: false
}
```
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Support node modules that include binaries
Add support to the scripts/package-standalone.js for node modules that use platform-specific binary modules.
By default the script bundles the module for all platforms, this can be disabled with -s for single platform builds.
The module for each platform will be bundled into standalone.zip in platform specific directories:
```
binaries/linux-arm64/node_modules
binaries/darwin-x64/node_modules
binaries/win32-x64/node_modules
binaries/darwin-arm64/node_modules
binaries/linux-x64/node_modules
```
When running cline-core add the correct directory to the NODE_PATH, e.g.
```
$ export NODE_PATH=./node_modules/:./binaries/darwin-arm64/node_modules/
cline:/tmp/1$ node cline-core.js
Loading stubs...
Finished loading stubs
Loading stub impls...
Finished loading stub impls...
Cline environment: production
XS variant configuration warnings: [
'Component overrides for unused components: TOOL_USE_SECTION, TOOLS_SECTION, MCP_SECTION, TODO_SECTION, FEEDBACK_SECTION',
'Missing recommended components: TOOL_USE_SECTION'
]
[2025-09-05T19:53:00.853] #bot.cline.server.ts Running standalone cline 0.0.1
[2025-09-05T19:53:00.854] #bot.cline.server.ts Using settings dir: /Users/sjf/.cline/data
Finished loading vscode context...
[2025-09-05T19:53:00.858] #bot.cline.server.ts
Starting cline-core service...
sjfsjf created DBBBBBBBBB: Database {
name: '/tmp/db.sql',
open: true,
inTransaction: false,
readonly: false,
memory: false
}
```
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Remove test code
* Use the correct target directory for the binaries
The directory structure that the JB host expects is does
not exactly match ${arch}-${os}
* Update package-standalone script
Warn if there is module that needs binaries, but it is not being used.
Reset the binaries dir before packaging.
---------
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Enable biome rules: noUnusedVariables, noUnusedFunctionParameters, noUnusedImports
* Apply new rules with format
* remove unused currentReplaceContent
* update nextTerminalId
* fix all format issues
* update biome config
* add back applyContextOptimizations and killAllChromeBrowsers
`cline-core` cannot depend on its environment being set up properly
by its parent process. Run the terminal commands in a login shell so
that the PATH etc. will be setup correctly.
* Move the OutputChannel to the HostProvider
Replace `OutputChannel.appendLine` with `HostProvider.logToChannel`.
Remove places where the cline OutputChannel was being passed around. Now it is stored in the HostProvider, so we don't need to do this.
# Conflicts:
# src/hosts/vscode/VscodeWebviewProvider.ts
* Dont log the timestamp in logger.ts, the cline-core logger already outputs the timestamp
* Fix imports
* Use npm `open` to open URLs in the external browser
# Conflicts:
# src/utils/env.ts
# Conflicts:
# src/utils/env.ts
* Change log statement
* Use the simple-open-url module to open URLs in the system browser.
Log failures of ProtoBus RPCs
* Remove vscode hostbridge handler for openExternal
* Rm unused imports
* Switch back to `open` module.
Update esbuild.js to ES6 and move to esbuild.mjs
* Update src/utils/env.ts
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* remove IS_DEV from e2e setup build
---------
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Co-authored-by: abeatrix <beatrix@cline.bot>
* Replace vscode.workspace.getWorkspaceFolder() with the host bridge
Use the hostbridge getWorkspacePaths() and use the result to
check for the workspaceFolder of the current file open in the IDE.
* Organize imports
* Update isLocatedInWorkspace() to check all the workspace directories, not just the first.
Add utility function to check if a path is inside a directory instead of duplicating the logic.
* Remove stubs for workspaceFolders that are not needed anymore.
* Add ui.getWebviewHtml to the protobus
This will return the HTML content for external clients.
* Add getUri to ExternalWebviewProvider
Change getUri to return URIs for files in an appropriate format for the external web view.
Use URI from npm module in ExternalWebviewProvider.
Use a default value for the cline dir, ~/.cline
Turn off gRPC debugging
* Include node modules used as assets in the standalone package.
* Throw an error if trying to recreate webview panel in standalone app.
* Get root of the cline storage directory from an env var.
Set the cline directory env var when running the standalone app from the vscode launcher.
Add missing vscode SDK stub.
* Stop spamming the logs.
The extension doesn't like it when the workspace/workspace config is undefined.
Fix the warning about the name in package.json.
Change some logging in the gRPC server.
* Add globalState to the standalone vscode extension context replacement.
Add a generic key-value store that can be used by different storages, and move this into vscode-context-utils file.
Move the stubs/mocks into a separate stubs file, (they have type checking turned off).
Keep the implementations in vscode-context and turn on typechecking for this file.
* Add type parameter for the values in the JsonKeyValueStore
* Optimize imports
* Add implementations for the vscode ExtensionContext in the standalone app (#4000)
* Formatting
* add package-lock.json
* Add standalone cline server.
Add directory standalone/ with the scripts to generate
a cline instance that runs a gRPC service for the proto bus.
* Rm unused dependencies
* Build standalone extension
Build stubs for the whole vscode SDK.
Import extension.js instead of putting everything in one file.
Move all the files the extension needs at runtime in files/
Use local packages for vscode and stub-utils instead of module alias.
Move vscode-impls into the vscode module.
Create separate package.json for the standalone extension in files/.
* Handlers for gRPC requests
Add code to the bottom of extension.js to export the gRPC handlers.
Add a wrapper to the handlers to catch and log extensions, otherwise the whole server process fails.
Fix use of open module.
* Standalone gRPC server
Export handers from the extension.
Add reflection and healthcheck to the server.
Add vscode launch file for standalone server.
* Fix formatting
* Better error handling in the server template.
Exit if the server could not bind to the port.
Use internal error code if exception is thrown.
* Formatting
* Stop using google-protobuf npm module to generate JS for protos
The code generated by google-protobuf cannot serialize protos from plain objects. It needs the protos to be class instances created with ProtoExample.create().
But, the protos created in the extension are just POJOs.
Use protoLoader instead which is fine with plain objects.
Protoloader is also the method used in the grpc JS documentation: https://grpc.io/docs/languages/node/basics/#loading-service-descriptors-from-proto-files
* Rm proto that was removed in cline/cline
* Rm old protos when building standalone extension.
* Log gRPC requests
* feat(standalone): implement TypeScript gRPC-based standalone extension
The major improvement is that the gRPC implementation is now written in TypeScript instead of JavaScript, and the standalone extension is compiled together with the original extension rather than using the compiled JS output. This provides full type safety throughout the codebase and prevents issues with the TypeScript compiler renaming handlers during compilation, making the system more robust and maintainable.
- Add new standalone implementation files in src/standalone/ directory using TypeScript
- Implement gRPC server setup in extension-standalone.ts with full type safety
- Generate server setup code with service registrations
- Update build script to support the new standalone architecture
- Reorganize runtime files from standalone/files/ to standalone/runtime-files/
- Replace template-based server generation with gRPC service registration
* Fix issues when doing clean build
Use correct build dir in esbuild.js
Remove undefined type.
* Add handler for gRPC methods with streaming response.
Add a handler-wrapper for rpc's with streaming responses.
Fix issue where grpc-js won't deserialize protos in camelcase. It is the default
for generated code for protos to use camelcase (keepCase: false), but I cannot find
where is being set for the proto serializations to keep the case. For now, just convert the
properties of the proto messages to snake case. This is not a good
solution, but trying to fix this is time sink.
* Formatting
* Add streaming response support to the script that generates setup-server.ts
Add types for the handlers.
* Formatting
* Fix case conversion for gRPC requset protos as well.
Convert snake case to camelcase for incoming request protos.
* formatting
* Improve build process / building for standalone extension
Add separate configs for the extension and the standalone in the esbuild config.
Modules that use __dirname to load files at runtime are marked as external in the build config.
Rename vscode-impls to vscode-context.
Remove unecessary files from the standalone runtime.
* Rename extension-standalone.js to standalone.js
* Move generate-server-setup script to protos dir.
Add the script the npm target `protos`, so it is run when the protos are regenerated.
* formatting
* Add a post build step for the npm run target `protos` to format the generated files.
* Move generate-server-setup to scripts directory
* Add a JS script to package the standalone build, replacing the shell script.
Add a post build step for the standalone target that:
* copies the vscode module files into the output directory.
* checks that native modules are not included in the output
* creates a zip of the build.
* Rm files that were included from merge by mistake
* Move scripts from standalone in scripts directory
Remove unused package.json files from standalone/
* Update scripts and launch.json to use correct paths
* During build install external modules in the dist directory.
Add package.json for the distribution.
Set the node path for the vscode launch config.
Make the prettier silent during `npm run protos`
* Fix ellipsis suggestions
Robin Newhouse