* 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>
Vincent Koc
Peter Steinberger
Ayaan Zaidi
tarouca
Cathryn Lavery
Neerav Makwana
Altay
coolramukaka-sys
@zimeg
Gustavo Madeira Santana
Onur
hugh.li