* fix(microsoft-foundry): bound az login device-code subprocess
Add a 5-minute timeout to the az login spawn so a stalled Azure CLI
does not block the caller indefinitely. The timeout kills the child
process and rejects the promise with a descriptive message.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(microsoft-foundry): reject login timeout immediately
* refactor(microsoft-foundry): use shared process timeout
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* feat(models): add Claude Opus 5 support
* test(models): align Opus 5 setup fixtures
* test(models): update ambient Opus 5 detection
* fix(models): reconcile Opus 5 support with main
* fix(microsoft-foundry): decode spawn pipes statefully with setEncoding('utf8')
Co-Authored-By: SunnyShu0925 <sunny.shu0925@gmail.com>
child_process spawn stdout/stderr .on('data') handlers in
azLoginDeviceCodeWithOptions received raw Buffer chunks. When a
multi-byte UTF-8 code point straddled a chunk boundary, String(chunk)
produced U+FFFD (replacement characters) for the split partial
sequences.
Fix the same way as PR #108518 (provider-local-service) and #109220
(voice-call ngrok): call setEncoding('utf8') on the pipe streams before
attaching data listeners so Node's stream decoder reassembles full code
points across chunk boundaries.
Test: PassThrough stream that receives a 4-byte smiley (U+1F60A) split
mid-sequence across two Buffer writes. With setEncoding, the reassembled
output is the clean code point, not U+FFFD.
* test(microsoft-foundry): replace PassThrough test with azLoginDeviceCodeWithOptions regression
* test(microsoft-foundry): add real-spawn integration test for split-byte setEncoding proof
* fix: add :unknown to catch callback variable for oxlint
* chore: add proof script for setEncoding utf8 split-byte fix
* remove standalone proof script (proof lives in PR body + test coverage)
* test(microsoft-foundry): tighten UTF-8 stream regression
Co-authored-by: SunnyShu0925 <shu.zongyu@xydigit.com>
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Allow persisted provider model entries to carry strict thinkingLevelMap values so Microsoft Foundry Entra onboarding can save generated reasoning model config. Closes#91011.
When onboarding Microsoft Foundry-hosted DeepSeek-V4 models (Pro/Flash),
the onboarding wizard assigned api: 'openai-completions' because
usesFoundryResponsesByDefault() only matched GPT/o-series models.
These V4 models require the Responses API (openai-responses) to work
correctly against the Foundry endpoint. Without this fix, all calls fail
with 'provider rejected the request schema or tool payload'.
Fix: Add 'deepseek-v4' prefix to usesFoundryResponsesByDefault() so only
the verified V4 family defaults to openai-responses. Older DeepSeek
families (e.g., V3) remain on openai-completions until proven compatible.
Closes: DeepSeek V4 models deployed via Microsoft Foundry onboarding
failing immediately due to wrong API adapter.
Co-authored-by: Roslin <rmj010203@gmail.com>
* fix config provider timeout overlays
Allow bundled model provider config entries to act as overlays so fields like timeoutSeconds can be configured without redeclaring baseUrl and models. Keep unknown custom provider declarations strict, and guard configured-provider fallback against overlay entries without models.
* fix(config): include provider aliases in model overlays
* fix(config): guard Foundry timeout overlays
* fix(config): normalize bundled provider overlays
* fix(models): reject overlay-only fallback models
subs.find() can return undefined if the selected subscription ID does not match any enabled subscription. Replace the unsafe non-null assertion with an explicit guard and descriptive error.
Co-authored-by: oliviareid-svg <oliviareid@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>