When cron tasks or subagents use browser automation, the browser
processes were not cleaned up after the task completed. This caused
orphaned Chrome processes (PPID=1) to accumulate over time.
Root cause: closeTrackedBrowserTabsForSessions was only called during
session-reset/session-delete (via ensureSessionRuntimeCleanup), but
isolated cron runs and subagent completions never triggered these paths.
Fix: Add browser tab cleanup in two places:
1. server-cron.ts: wrap runCronIsolatedAgentTurn in try/finally to
ensure browser tabs are cleaned up after every cron run.
2. subagent-registry-lifecycle.ts: call closeTrackedBrowserTabsForSessions
when a subagent run completes, before the announce cleanup flow.
Both cleanup calls are best-effort (caught errors) so they never mask
the actual task result or break the completion flow.
Fixes#60104
Add native MiniMax Search integration via their Coding Plan search API
(POST /v1/coding_plan/search). This brings MiniMax in line with Brave,
Kimi, Grok, Gemini, and other providers that already have bundled web
search support.
- Implement WebSearchProviderPlugin with caching, credential resolution,
and trusted endpoint wrapping
- Support both global (api.minimax.io) and CN (api.minimaxi.com)
endpoints, inferred from explicit region config, model provider base
URL, or minimax-portal OAuth base URL
- Prefer MINIMAX_CODE_PLAN_KEY over MINIMAX_API_KEY in credential
fallback, matching existing repo precedence
- Accept SecretRef objects for webSearch.apiKey (type: [string, object])
- Register in bundled registry, provider-id compat map, and fast-path
plugin id list with full alignment test coverage
- Add unit tests for endpoint/region resolution and edge cases
Closes#47927
Related #11399
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When the liveModelSwitchPending flag is set but the current model already
matches the persisted selection (e.g. the switch was applied as an override
and the current attempt is already using the new model), the flag is now
consumed eagerly via a fire-and-forget clearLiveModelSwitchPending() call.
Without this, the stale flag could persist across fallback iterations and
later cause a spurious LiveSessionModelSwitchError when the model rotates
to a fallback candidate that differs from the persisted selection.
Also expands JSDoc on shouldSwitchToLiveModel to document the stale-flag
clearing and deferral semantics.
Replace the ambiguous comparison-based approach (hasDifferentLiveSessionModelSelection
+ in-memory map EMBEDDED_RUN_MODEL_SWITCH_REQUESTS) with a persisted
`liveModelSwitchPending` flag on SessionEntry.
The root cause: the in-memory map was never populated in production because
requestLiveSessionModelSwitch() was removed in commit 622b91d04e and replaced
with refreshQueuedFollowupSession(). This left the comparison-based detection
as the only path, which could not distinguish user-initiated model switches
(via /model command) from system-initiated fallback rotations.
The fix:
- Add `liveModelSwitchPending?: boolean` to SessionEntry (persisted)
- Set the flag to true ONLY when /model command applies a model override
- New `shouldSwitchToLiveModel()` checks the flag + model mismatch together
- New `clearLiveModelSwitchPending()` resets the flag after consumption
- Replace throw-site logic in run.ts to use the new flag-based functions
- Remove orphaned resolveCurrentLiveSelection helper
Only the /model command sets this flag, so system-initiated fallback rotations
are never mistaken for user-initiated model switches. This restores the
live-switch-during-active-run feature that was accidentally broken.
Fixes#57857, #57760, #58137
When auth choice explicitly sets a preferred provider (e.g., volcengine-api-key or byteplus-api-key), the model picker should always filter by that provider. Previously, it relied on providerIds.includes(preferredProvider), which could be false if the catalog hadn't loaded that provider's models yet due to a race condition between auth choice setup and catalog loading.
This ensures that selecting a provider via auth choice consistently filters the model list to only that provider's models, rather than showing all providers.
MiniMax's usage_percent / usagePercent fields report the *remaining* quota
as a percentage, not the consumed quota. When count fields (prompt_limit /
prompt_remain) are also present, fromCounts already computed the correct
usedPercent and the inverted value was silently ignored. But when only
usage_percent is returned (no count fields), the code treated it as a
used-percent and passed it through unchanged, causing the menu bar to show
"2% left" instead of "98% left".
Move usage_percent and usagePercent from PERCENT_KEYS to a new
REMAINING_PERCENT_KEYS array. deriveUsedPercent now inverts remaining-percent
values to obtain usedPercent, matching the behaviour already validated by the
existing "prefers count-based usage when percent looks inverted" test. Count-
based fromCounts still takes priority over both key groups.
Fixes#60193
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When using custom providers like LM Studio, Ollama, or DashScope,
token counts in /status show as 0 because the agent meta store
does not always have usage data populated for these providers.
Fix: set includeTranscriptUsage: true in both /status command and
the session_status tool. This enables the existing fallback path
that reads usage from the session transcript JSONL file when the
meta store has zero/missing token counts.
The merge logic already guards against overwriting valid data:
- totalTokens: only updated when zero or transcript value is larger
- inputTokens/outputTokens: only filled when zero/missing
- model/contextTokens: only filled when missing
Fixes#54995
Peter Steinberger
BrianWang1990
Jithendra
kiranvk2011
Vincent Koc
复试资料
Mingxuan
Agustin Rivera
0912078
Brad Groux
ximi
jjjojoj
潘晓波0668000512
陈大虾🦞
xydt-610