* fix(agents): handle LiveSessionModelSwitchError in subagent execution
Add retry loop for cross-provider model switches in the subagent
command path, mirroring the existing logic in agent-runner-execution.ts.
- Wrap runWithModelFallback in a while(true) loop inside agentCommandInternal
- Catch LiveSessionModelSwitchError and update provider, model,
fallbackProvider, fallbackModel, providerForAuthProfileValidation,
sessionEntry.authProfileOverride, and storedModelOverride before retrying
- Guard storedModelOverride update: only set when the model genuinely
changed (compared before mutation) or a session override already existed
- Reset lifecycleEnded flag so the retried iteration can emit lifecycle events
- Add comprehensive tests covering retry success, error propagation,
lifecycle reset, auth-profile forwarding, and fallback override state
Fixes#57998
* fix(agents): include provider change in storedModelOverride guard
* fix(agents): validate allowlist and clear stale compaction count on live model switch
* fix(agents): remove broken allowlist guard on live model switch
* fix(agents): address security review — bound retry loop, validate allowlist, redact error in lifecycle events
* fix(agents): restore error observability in lifecycle events using err.message
* fix(agents): sanitize log inputs and shallow-copy sessionEntry on live model switch
* fix(agents): enforce allowlist on empty set and sanitize error message
* fix: handle subagent live model switches (#58178) (thanks @openperf)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
* fix(agents): classify generic provider errors for failover
Anthropic returns bare 'An unknown error occurred' during API instability
and OpenRouter wraps upstream failures as 'Provider returned error'. Neither
message was recognized by the failover classifier, so the error surfaced
directly to users instead of triggering the configured fallback chain.
Add both patterns to the serverError classifier so they are classified as
transient server errors (timeout) and trigger model failover.
Closes#49706Closes#45834
* fix(agents): scope unknown-error failover by provider
* docs(changelog): note provider-scoped unknown-error failover
---------
Co-authored-by: Aaron Zhu <aaron@Aarons-MacBook-Air.local>
Co-authored-by: Altay <altay@uinaf.dev>
* fix(cli): route skills list output to stdout when --json is active
runSkillsAction used defaultRuntime.log() which goes through console.log.
The --json preAction hook calls routeLogsToStderr(), redirecting console.log
to stderr. Switch to defaultRuntime.writeStdout() which writes directly to
process.stdout, consistent with how other --json commands (e.g. skills search)
already emit their output.
Fixes#57599
* test(cli): add skills JSON stdout regression coverage
* test(cli): refine skills CLI stream coverage
* fix(cli): add changelog entry for skills JSON stdout fix
---------
Co-authored-by: Aftabbs <aftabbs.wwe@gmail.com>
* fix(google-gemini-cli-auth): fix Gemini CLI OAuth failures on Windows
Two issues prevented Gemini CLI OAuth from working on Windows:
1. resolveGeminiCliDirs: the first candidate `dirname(dirname(resolvedPath))`
can resolve to an unrelated ancestor directory (e.g. the nvm root
`C:\Users\<user>\AppData\Local\nvm`) when gemini is installed via nvm.
The subsequent `findFile` recursive search (depth 10) then picks up an
`oauth2.js` from a completely different package (e.g.
`discord-api-types/payloads/v10/oauth2.js`), which naturally does not
contain Google OAuth credentials, causing silent extraction failure.
Fix: validate candidate directories before including them — only keep
candidates that contain a `package.json` or a `node_modules/@google/
gemini-cli-core` subdirectory.
2. resolvePlatform: returns "WINDOWS" on win32, but Google's loadCodeAssist
API rejects it as an invalid Platform enum value (400 INVALID_ARGUMENT),
just like it rejects "LINUX".
Fix: use "PLATFORM_UNSPECIFIED" for all non-macOS platforms.
* test(google-gemini-cli-auth): keep oauth regressions portable
* chore(changelog): add google gemini cli auth fix note
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
