* fix(llms): Use Google auth for Vertex Gemini
- Pass `providerConfig.gcp.projectId` through to Vertex Gemini as `googleAuthOptions.projectId`
- Disable Vertex API-key express mode when GCP project config is present so `google-auth-library` handles auth
- Add coverage for `AgentConfig.providerConfig.gcp` forwarding and Vertex Gemini provider creation
- Fix vertex model list only contains Claude models issue
* feat(core): includes tool names in tool results across messages
Updated `tool_result` content blocks to consistently include the `name` of the tool being executed. This change propagates through provider helpers and applies the new schema across all associated unit and live tests, ensuring proper tracking and logging of tool interactions within messages.
- Pass `providerConfig.gcp.projectId` through to Vertex Gemini as `googleAuthOptions.projectId`
- Disable Vertex API-key express mode when GCP project config is present so `google-auth-library` handles auth
- Add coverage for `AgentConfig.providerConfig.gcp` forwarding and Vertex Gemini provider creation
- Fix vertex model list only contains Claude models issue
* feat(runtime): track idle and pending session states
Propagate idle and pending as non-terminal session statuses across the CLI, hub records, and active-session checks. Update runtime handling so interactive sessions remain active while idle or awaiting approval instead of being treated as ended.
Removed `status` from showing up in `cline history` for now.
* hydrate: false no longer reads message files for every session.
* fix(cron): publish failed schedule execution events
Add cron runner execution event publishing for completed and failed runs.
Update connector adapters to react to failed schedule executions so clients are notified when scheduled work does not complete successfully.
* add unit tests
The new Bedrock path is not failing because credential_process is unsupported. Both old and new code use AWS SDK v3’s fromNodeProviderChain, which can load credential_process.
The practical difference is that the migrated config does not include the AWS profile name:
```
"aws": {
"region": "us-east-1",
"authentication": "profile"
}
```
There is no `"profile": "bedrock"` So the new llms provider never targets [profile bedrock]. It calls fromNodeProviderChain({ ignoreCache: true, clientConfig: { region } }), which means AWS SDK will use AWS_PROFILE if present, otherwise default.
## Cause
The migration code only migrates awsProfile when legacy awsUseProfile is true. But the old extension treats profile auth as active when awsAuthentication === "profile" too:
```
profile:
legacyGlobalState.awsAuthentication === "profile" || legacyGlobalState.awsUseProfile
? trimNonEmpty(legacyGlobalState.awsProfile)
: undefined
```
## Fixes
The migration now preserves awsProfile when awsAuthentication === "profile", even if the old awsUseProfile flag is missing. It also treats profile-based Bedrock settings as enough to migrate Bedrock without static AWS keys.
* refactor: cache global settings reads by file metadata
Avoid repeated global settings file reads by caching parsed settings and
validating the cache with path, mtime, and size. Invalidate the cache after
writes so updates remain visible, and clarify the legacy skills config name.
* refactor for performance
mtime-keyed cache of the parsed GlobalSettings — repeated reads do statSync + 4 comparisons instead of readFile + JSON.parse + zod (~30-100× speedup on hot path).
statSync(filePath, { throwIfNoEntry: false }) — avoids exception construction on missing-file path.
Cache invalidated on write — doesn't rely on filesystem mtime resolution.
loadSettingsFromDisk helper — pulls the read/parse/validate flow into one place, eliminates the previous three duplicated settingsCache = {...} assignments.
toggleDisabledTool cleaned up — single set construction + single write call, no branched copy of writeGlobalSettings.
* add unit tests for caching logic
* object freeze
All files automatically changed and formatted by `cd sdk && bun run build:models`
Generated model catalog version updated to 1779251127504
This includes the new X AI build
* fix: Speed up CLI plugin loading and config toggles
Load sandboxed plugins concurrently during initialization while preserving
existing duplicate override ordering. Update plugin tool discovery to use a
single sandbox per listing and cache descriptor results by plugin path stats,
provider, and model.
Make CLI plugin/tool config toggles persistence-only from the data loader and
update the TUI optimistically, avoiding full config reloads and repeated plugin
imports when users disable tools or plugins.
* patches
* fix: refresh plugin tools when config update lacks data
Reload config data with plugin tools included when a plugin action does not return updated data. This keeps the config view in sync and clears stale plugin tool errors after refresh.
* fix(cli): preserve config item state on missing toggle data
Only update the dialog item when toggle responses include a matching item. This avoids applying fallback enabled-state changes that can desync the UI when returned config data is missing or incomplete.
---------
Co-authored-by: Tomás Barreiro <52393857+BarreiroT@users.noreply.github.com>
* fix(cli): keep failed plugins visible in config UI ENG-2073
Preserve plugins that fail during load or setup and attach their
diagnostic phase and error message. Surface those errors in config detail
rows so users can identify and fix broken plugin definitions.
* fix(cli): preserve multiple plugin initialization failures
Aggregate all setup/load failures per plugin path instead of overwriting earlier errors. Summarize multiple errors in the config UI so rows remain readable while retaining the full failure details.
AgentRuntime.execute() reset iteration, pendingToolCalls, and lastError
between run/continue calls but not usage. This caused result.usage to
accumulate across calls, and local-runtime-host then added the
already-cumulative result onto the session baseline, double-counting
every prior turn's tokens on each new turn.
Destructure `loadConfigData` from `props` alongside the other props already
destructured at the top of `ConfigPanelContent`, and use the local binding in
the plugin-tools `useEffect` (both inside the body and in the dependency
array). This clears two Biome `lint/correctness/useExhaustiveDependencies`
errors introduced by #10819:
sdk/apps/cli/src/tui/views/config-view.tsx:265:2
× This hook specifies a dependency more specific than its captures:
props.loadConfigData
× This hook does not specify its dependency on props.
The previous shape mixed `props.loadConfigData` in the dep array with `props`
captures inside the effect body, which Biome flags because it cannot prove
that re-reading `props.loadConfigData` between renders is equivalent to
re-reading `props`. Destructuring once at the top resolves both diagnostics
without broadening the dep set to all of `props` (the rule's suggested
"unsafe fix") — the effect still only refires when `loadConfigData` itself
changes, matching the original intent.
No behavior change. The destructure pattern matches how `resolve`, `dismiss`,
`dialogId`, and `config` are already pulled off `props` on the same line.
The failure was first surfaced by the JetBrains-plugin integration workflow
on PR #10819, where `cline/intellij-plugin`'s `:buildClineCoreZip` task runs
`npm run lint` against the merged tree. Verified locally with:
npx @biomejs/biome lint --diagnostic-level=error \
sdk/apps/cli/src/tui/views/config-view.tsx
— clean, exit 0. Full repo `biome lint`: 2537 files, no errors.
Bee