* fix(bedrock): stop injecting fake apiKey marker for aws-sdk auth when no env vars exist
When the Bedrock provider uses auth: "aws-sdk" and no AWS environment
variables are set (EC2 instance roles, ECS task roles, etc.),
resolveAwsSdkApiKeyVarName() fell back to "AWS_PROFILE" unconditionally.
This string was injected as apiKey in the provider config during
normalisation, which poisoned the downstream auth resolver — it treated
the marker as a literal key and failed with "No API key found".
The fix:
- resolveAwsSdkApiKeyVarName() now returns undefined (not "AWS_PROFILE")
when no AWS env vars are present
- resolveBedrockConfigApiKey() (extension) gets the same fix
- resolveMissingProviderApiKey() guards both the providerApiKeyResolver
and direct aws-sdk branches: if the resolver returns nothing, the
provider config is returned unchanged (no apiKey injected)
- The aws-sdk credential chain then resolves credentials at request time
via IMDS/ECS task role/etc. as intended
When AWS env vars ARE present (AWS_ACCESS_KEY_ID, AWS_PROFILE,
AWS_BEARER_TOKEN_BEDROCK), the marker is still injected correctly.
Closes#49891Closes#50699Fixes#54274
* test(bedrock): update resolveBedrockConfigApiKey test for undefined return on empty env
The test previously expected "AWS_PROFILE" when no env vars are set.
Now expects undefined (matching the fix), and adds a separate assertion
that AWS_PROFILE is returned when the env var is actually present.
* fix(bedrock): lock aws-sdk env marker behavior
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
* fix(google): restore proxy-safe image generation (#59873)
* fix(ssrf): preserve transport policy without pinned dns
* fix(ssrf): use undici fetch for dispatcher requests
* fix(ssrf): type dispatcher fetch path
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
* fix(telegram): enable voice-note transcription in DMs
The preflight transcription condition only triggered for group chats
(isGroup && requireMention), so voice notes sent in direct messages
were never transcribed -- they arrived as raw <media:audio> placeholders.
This regression was introduced when the Telegram channel was moved from
src/telegram/ to extensions/telegram/, losing the fix from c15385fc94.
Widen the condition to fire whenever there is audio and no accompanying
text, regardless of chat type. Group-specific guards (requireMention,
disableAudioPreflight, senderAllowedForAudioPreflight) still apply
only in group contexts.
* fix: restore Telegram DM voice-note transcription (#61008) (thanks @manueltarouca)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
* fix: ensure bypassPermissions on custom CLI backend args
When users override cliBackends.claude-cli.args (e.g. to add --verbose
or change --output-format), the override array replaces the default
entirely. The normalization step only re-added --permission-mode
bypassPermissions when the legacy --dangerously-skip-permissions flag
was present — if neither flag existed, it did nothing.
This causes cron and heartbeat runs to silently fail with "exec denied:
Cron runs cannot wait for interactive exec approval" because the CLI
subprocess launches in interactive permission mode.
Fix: always inject --permission-mode bypassPermissions when no explicit
permission-mode flag is found in the resolved args, regardless of
whether the legacy flag was present.
* test(anthropic): add claude-cli permission normalization coverage
* fix(test-utils): include video generation providers
* fix: preserve claude-cli bypassPermissions on custom args (#61114) (thanks @cathrynlavery)
---------
Co-authored-by: Shadow <hi@shadowing.dev>
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
* fix(telegram): trim menu descriptions before dropping commands
* fix: note Telegram command menu trimming (#61129) (thanks @neeravmakwana)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
* 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>
