feat: add Microsoft Foundry (Azure AI) support for API Profiles

[riccardo-algorime]

Base Branch

• This PR targets the develop branch (required for all feature/fix PRs)
• This PR targets main (hotfix only - maintainers)

Description

Add support for Azure AI Foundry as an alternative to Anthropic API in the API Profiles system. Users can now configure Azure-hosted Claude models through the Settings UI, with support for both API key and Entra ID authentication.

Related Issue

Closes #823

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 📚 Documentation
• ♻️ Refactor
• 🧪 Test

Area

• Frontend
• Backend
• Fullstack

Changes

Frontend

• Add profile type selector (Anthropic API vs Microsoft Foundry)
• Add Foundry-specific fields: Azure Resource Name, Endpoint URL, optional API Key
• Add dedicated test connection for Foundry endpoints
• Add i18n translations (en/fr)
• Update OAuth mode clearing to include Foundry variables

Backend

• Update get_auth_token() to recognize Foundry credentials
• Add Foundry environment variables to SDK_ENV_VARS
• Document Foundry configuration in .env.example

Environment Variables

• CLAUDE_CODE_USE_FOUNDRY=1 - Enable Foundry mode
• ANTHROPIC_FOUNDRY_RESOURCE - Azure resource name
• ANTHROPIC_FOUNDRY_BASE_URL - Full Azure endpoint URL (alternative)
• ANTHROPIC_FOUNDRY_API_KEY - API key (optional with Entra ID)
• Model mappings: ANTHROPIC_DEFAULT_HAIKU_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL

Checklist

• I've synced with develop branch
• I've tested my changes locally
• I've followed the code principles (SOLID, DRY, KISS)
• My PR is small and focused (< 400 lines ideally)

CI/Testing Requirements

• All CI checks pass
• All existing tests pass
• New features include test coverage
• Bug fixes include regression tests

Feature Toggle

• Behind localStorage flag
• Behind settings toggle
• Behind environment variable/config
• N/A - Feature is complete and ready for all users

Breaking Changes

Breaking: No

Backward compatible - existing profiles without type field default to anthropic.

Summary by CodeRabbit

• New Features
  • Added Microsoft Foundry (Azure AI Foundry) as an alternative API provider with a new profile type and Foundry-specific fields (resource, base URL, optional API key) and connection testing.
• UI / Localization
  • Updated settings UI and added English/French localization strings for Foundry options and validation.
• Tests
  • Expanded unit tests to cover Foundry-related env handling and connection test parameters.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
4 out of 5 committers have signed the CLA.

✅ AndyMik90
✅ MaximStone
✅ riccardo-algorime
✅ StillKnotKnown
❌ aslaker
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds Microsoft Foundry (Azure AI Foundry) as an alternative API profile type alongside Anthropic, expanding backend env config and auth resolution, frontend profile types, services, IPC handlers, UI, types, presets, tests, and i18n strings to support Foundry resource, endpoint, and optional API key workflows.

Changes

Cohort / File(s)	Summary
Backend config & auth apps/backend/.env.example, apps/backend/core/auth.py	Added Foundry env vars to example; expanded SDK passthrough list and updated get_auth_token() to prefer Foundry API key or return a Foundry Entra placeholder when enabled.
Frontend profile types & IPC apps/frontend/src/shared/types/profile.ts, apps/frontend/src/shared/types/ipc.ts, apps/frontend/src/preload/api/profile-api.ts	Introduced APIProfileType (`'anthropic'
Profile services & manager apps/frontend/src/main/services/profile/profile-service.ts, apps/frontend/src/main/services/profile/profile-manager.ts, apps/frontend/src/main/services/profile/index.ts	Added testFoundryConnection(), branching validation/update logic for type (anthropic vs foundry), and mapped Foundry-specific env vars during profile activation. Exported new test helper.
IPC handlers & main apps/frontend/src/main/ipc-handlers/profile-handlers.ts	PROFILES_TEST_CONNECTION handler updated to accept profileType and foundryResource and route to testFoundryConnection or existing testConnection accordingly.
Renderer UI & store apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx, apps/frontend/src/renderer/stores/settings-store.ts	Added profile type selector and Foundry-specific inputs (resource, base URL, optional API key), updated validation/test flows per type; store forwards new params to IPC.
Env utils & tests apps/frontend/src/main/agent/env-utils.ts, apps/frontend/src/main/agent/env-utils.test.ts	OAuth-mode clearing now considers Foundry vars (CLAUDE_CODE_USE_FOUNDRY, ANTHROPIC_FOUNDRY_*); tests updated to expect those keys.
Presets & i18n apps/frontend/src/shared/constants/api-profiles.ts, apps/frontend/src/shared/i18n/locales/en/settings.json, apps/frontend/src/shared/i18n/locales/fr/settings.json	Added type to provider presets, introduced azureFoundry preset, and added Foundry fields/labels/placeholders/hints/validation entries.
Tests & other small updates apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx, apps/frontend/src/shared/types/ipc.ts	Tests updated to include new optional args; IPC types adjusted for new testConnection signature.

Sequence Diagram

sequenceDiagram
    participant User
    participant UI as ProfileEditDialog
    participant Store as SettingsStore
    participant IPC as IPC Handler
    participant Service as ProfileService
    participant Backend as Backend Auth

    User->>UI: Select profile type & enter config
    UI->>Store: testConnection(baseUrl, apiKey, signal, profileType, foundryResource)
    Store->>IPC: PROFILES_TEST_CONNECTION(baseUrl, apiKey, requestId, profileType, foundryResource)
    alt profileType == "foundry"
        IPC->>Service: testFoundryConnection(baseUrl, apiKey, foundryResource)
        Service->>Service: Resolve endpoint (resource → baseUrl) and validate
        Service-->>IPC: TestConnectionResult
    else
        IPC->>Service: testConnection(baseUrl, apiKey)
        Service->>Service: Validate baseUrl & apiKey
        Service-->>IPC: TestConnectionResult
    end
    IPC-->>Store: IPC Result
    Store-->>UI: Test Result
    UI-->>User: Display status

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Possibly related PRs

• feat: Add multi-auth token support and ANTHROPIC_BASE_URL passthrough (CLI only) #7: Modifies centralized auth token resolution and SDK env passthrough that this change extends for Foundry.
• feat: custom Anthropic compatible API profile management #181: Adds API profile management foundations that this PR builds upon to support a second profile type.
• fix: improve GLM presets, ideation auth, and Insights env #648: Alters frontend profile surface and env handling related to the OAuth/profile flows updated here.

Suggested labels

feature, area/fullstack, priority/medium, size/L

Suggested reviewers

• AlexMadera
• AndyMik90
• MikeeBuilds

Poem

🐰 I hopped the code and found a key,
A Foundry resource whispered to me,
Two profile paths, a rabbit's cheer,
Configs and tests now both appear,
Hoppity-hop, the endpoints are near!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: adding Microsoft Foundry (Azure AI) support for API Profiles, which is the primary objective across all modified files.
Docstring Coverage	✅ Passed	Docstring coverage is 90.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

🎉 Thanks for your first PR!

A maintainer will review it soon. Please make sure:

• Your branch is synced with develop
• CI checks pass
• You've followed our contribution guide

Welcome to the Auto Claude community!

[gemini-code-assist]

Summary of Changes

Hello @riccardo-algorime, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly expands the API profile system by integrating Microsoft Foundry (Azure AI) as a new provider for Claude models. It introduces a new profile type, allowing users to configure and manage their Azure-hosted Claude instances directly within the application, complete with flexible authentication options and a dedicated connection testing mechanism. This enhancement provides greater choice and adaptability for users leveraging cloud-based AI services.

Highlights

• Microsoft Foundry (Azure AI) Support: Introduced comprehensive support for Microsoft Foundry (Azure AI) as an alternative API provider for Claude models, allowing users to configure Azure-hosted Claude models through the Settings UI.
• Authentication Flexibility: Enabled support for both API key and Microsoft Entra ID authentication methods for Azure AI Foundry profiles, providing users with flexible and secure access options.
• Frontend UI Enhancements: Added a new profile type selector in the Settings UI, allowing users to choose between Anthropic API and Microsoft Foundry. This includes dedicated input fields for Azure Resource Name, Endpoint URL, and an optional API Key, along with a specific connection test for Foundry endpoints.
• Backend Integration: Updated the backend's authentication mechanism (get_auth_token()) to recognize and prioritize Foundry credentials. New environment variables for Foundry configuration have been added to SDK_ENV_VARS and documented in .env.example.
• Internationalization (i18n): Included new translation keys for English and French to support the new Foundry-specific fields, types, placeholders, hints, and validation messages in the user interface.
• OAuth Mode Compatibility: Ensured proper clearing of Foundry-related environment variables when switching to OAuth mode, preventing potential authentication conflicts.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces support for Microsoft Foundry (Azure AI Foundry) API profiles, alongside the existing Anthropic API profiles. Key changes include adding new environment variables for Foundry configuration in .env.example and core/auth.py, and updating get_auth_token to prioritize Foundry authentication. The frontend now includes a 'Profile Type' selector in the settings dialog, allowing users to configure Foundry-specific details like Azure Resource Name and Endpoint URL, with corresponding validation logic in profile-service.ts and ProfileEditDialog.tsx. The testConnection IPC handler and related services (profile-service.ts, profile-api.ts, settings-store.ts) have been extended to route connection tests based on profile type, including a new testFoundryConnection function for basic reachability checks. Environment variable mapping in getAPIProfileEnv was updated to correctly set Foundry-specific variables. Review comments highlighted the need to refactor duplicated validation logic in createProfile and updateProfile into a shared helper function, remove debugging console.log statements, and simplify conditional logic for setting foundryResource in profile creation and update functions.

[gemini-code-assist]

The validation logic for profile inputs is duplicated between createProfile (lines 127-151) and updateProfile (lines 201-225). This violates the DRY (Don't Repeat Yourself) principle and makes maintenance harder, as any change to the validation rules must be applied in two places.

To improve this, you can extract the validation logic into a dedicated helper function. This function can then be called from both createProfile and updateProfile.

Here's an example of how you could refactor this:

function validateProfileInput(input: CreateProfileInput | UpdateProfileInput): void {
  const profileType = input.type || 'anthropic';

  // Validate base URL (required for anthropic, optional for foundry if foundryResource is set)
  if (profileType === 'anthropic') {
    if (!validateBaseUrl(input.baseUrl)) {
      throw new Error('Invalid base URL');
    }
  } else if (profileType === 'foundry') {
    // Foundry: needs either foundryResource OR baseUrl
    const hasResource = input.foundryResource && input.foundryResource.trim() !== '';
    const hasBaseUrl = input.baseUrl && input.baseUrl.trim() !== '' && validateBaseUrl(input.baseUrl);
    if (!hasResource && !hasBaseUrl) {
      throw new Error('Either Azure Resource Name or Endpoint URL is required');
    }
  }

  // Validate API key (required for anthropic, optional for foundry - Entra ID auth)
  if (profileType === 'anthropic') {
    if (!validateApiKey(input.apiKey)) {
      throw new Error('Invalid API key');
    }
  }
}

export async function createProfile(input: CreateProfileInput): Promise<APIProfile> {
  validateProfileInput(input);
  // ... rest of the function
}

export async function updateProfile(input: UpdateProfileInput): Promise<APIProfile> {
  validateProfileInput(input);
  // ... rest of the function
}

[gemini-code-assist]

This console.log statement, along with others in this function (lines 311, 318, and 363), appear to be for debugging. While useful during development, they should be removed before merging to keep production logs clean and avoid leaking potentially sensitive information.

[gemini-code-assist]

The logic for setting foundryResource during an update can be simplified for better readability. The current conditional spread is a bit complex.

A more direct approach is to use a single ternary operator. This makes the intent clearer: foundryResource should only be set for 'foundry' profiles, and it should be undefined otherwise or if empty. This also correctly cleans up the foundryResource field if you switch the profile type away from 'foundry'.

A similar simplification can be applied to the creation logic on lines 362-365.

Suggested change

	// Foundry resource (only for foundry profiles)
	...(profileType === 'foundry' && foundryResource.trim()
	? { foundryResource: foundryResource.trim() }
	: { foundryResource: undefined }),
	foundryResource: profileType === 'foundry' ? (foundryResource.trim() || undefined) : undefined,

[gemini-code-assist]

The logic for conditionally adding foundryResource during profile creation can be made more concise. Instead of a ternary operator that returns an empty object, you can use a logical AND (&&) short-circuit for better readability.

Suggested change

	// Foundry resource (only for foundry profiles)
	...(profileType === 'foundry' && foundryResource.trim()
	? { foundryResource: foundryResource.trim() }
	: {})
	...(profileType === 'foundry' && foundryResource.trim() && { foundryResource: foundryResource.trim() }),

[coderabbitai]

Actionable comments posted: 4

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

apps/backend/core/auth.py (2)

175-192: Update get_auth_token_source() to handle Foundry authentication.

The function get_auth_token_source() doesn't check for Foundry environment variables, so it will return None when Foundry authentication is active. This could cause confusion in logging or debugging scenarios where the auth source needs to be identified.

🔧 Proposed fix to add Foundry source detection

 def get_auth_token_source() -> str | None:
     """Get the name of the source that provided the auth token."""
+    # Check for Microsoft Foundry first
+    if os.environ.get("CLAUDE_CODE_USE_FOUNDRY") == "1":
+        if os.environ.get("ANTHROPIC_FOUNDRY_API_KEY"):
+            return "ANTHROPIC_FOUNDRY_API_KEY"
+        return "Microsoft Entra ID (Azure)"
+    
     # Check environment variables first
     for var in AUTH_TOKEN_ENV_VARS:
         if os.environ.get(var):
             return var

---

195-233: Update error message in require_auth_token() to mention Foundry authentication.

The error message in require_auth_token() doesn't mention the Microsoft Foundry authentication option, which could confuse users who are trying to configure Azure AI Foundry support.

📝 Proposed fix to include Foundry in error guidance

     token = get_auth_token()
     if not token:
         error_msg = (
             "No OAuth token found.\n\n"
             "Auto Claude requires Claude Code OAuth authentication.\n"
             "Direct API keys (ANTHROPIC_API_KEY) are not supported.\n\n"
+            "For Microsoft Foundry (Azure AI), set:\n"
+            "  CLAUDE_CODE_USE_FOUNDRY=1\n"
+            "  ANTHROPIC_FOUNDRY_RESOURCE=your-resource-name\n"
+            "  ANTHROPIC_FOUNDRY_API_KEY=your-key (or use Entra ID)\n\n"
         )
         # Provide platform-specific guidance

🤖 Fix all issues with AI agents

In @apps/backend/.env.example:
- Line 47: The comment instructing users to run "claude config set --global
provider azure" is incorrect; remove that CLI instruction and replace it with
guidance to configure Anthropic Foundry via environment variables instead, e.g.,
set ANTHROPIC_FOUNDRY_API_KEY (the Foundry API key) and the Foundry endpoint
variable (e.g., ANTHROPIC_FOUNDRY_API_BASE or ANTHROPIC_FOUNDRY_API_BASE_URL)
with the appropriate URL, and mention any other required env vars for Foundry
integration.

In @apps/frontend/src/main/services/profile/profile-service.ts:
- Around line 649-659: The catch path can leak the internal timeout when
controller is created: ensure that when using the internally created
AbortController (variable controller) you always clear the timeoutId in the
error path after a thrown fetch; update the function surrounding the fetch call
(referencing endpointUrl, fetch, signal, controller, timeoutId) to call
clearTimeout(timeoutId) in the catch/finally path (or use a single finally
block) so timeoutId is cleared whether fetch resolves or throws.
- Around line 663-676: The condition checking response.status >= 200 &&
response.status < 600 treats any HTTP status (2xx–5xx) as "success", making the
success returns unreachable/incorrect; update the logic in the
profile-service.ts check that inspects response.status so that "success" uses a
true success range (e.g., response.status >= 200 && response.status < 300) and,
if you need to assert endpoint reachability irrespective of success, add a
separate branch for response.status < 600 to return a reachable-but-failed
status; adjust the returns that reference apiKey and the Entra ID message
accordingly so they only occur in the true-success branch while keeping a
distinct message/return for reachable non-success responses.

In @apps/frontend/src/shared/types/profile.ts:
- Around line 30-33: The profile type currently declares apiKey: string but
Foundry profiles can use Entra ID with no apiKey; change the field to optional
(apiKey?: string) in the profile type declaration (near APIProfileType and the
profile interface in profile.ts) and update any downstream consumers to handle
undefined/'' cases (add null/undefined guards where code assumes a non-empty
apiKey). If you prefer to keep it required, instead update the apiKey comment to
explicitly state "May be empty string for Foundry with Entra ID auth" and add
type guards in places that rely on presence; prefer making it optional to match
runtime behavior.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 63e142a and ee0c09e.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json, !**/package-lock.json

📒 Files selected for processing (15)

• apps/backend/.env.example
• apps/backend/core/auth.py
• apps/frontend/src/main/agent/env-utils.ts
• apps/frontend/src/main/ipc-handlers/profile-handlers.ts
• apps/frontend/src/main/services/profile/index.ts
• apps/frontend/src/main/services/profile/profile-manager.ts
• apps/frontend/src/main/services/profile/profile-service.ts
• apps/frontend/src/preload/api/profile-api.ts
• apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx
• apps/frontend/src/renderer/stores/settings-store.ts
• apps/frontend/src/shared/constants/api-profiles.ts
• apps/frontend/src/shared/i18n/locales/en/settings.json
• apps/frontend/src/shared/i18n/locales/fr/settings.json
• apps/frontend/src/shared/types/ipc.ts
• apps/frontend/src/shared/types/profile.ts

🧰 Additional context used

📓 Path-based instructions (7)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/renderer/stores/settings-store.ts
• apps/frontend/src/main/services/profile/profile-manager.ts
• apps/frontend/src/shared/constants/api-profiles.ts
• apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx
• apps/frontend/src/main/ipc-handlers/profile-handlers.ts
• apps/frontend/src/shared/types/ipc.ts
• apps/frontend/src/main/agent/env-utils.ts
• apps/frontend/src/preload/api/profile-api.ts
• apps/frontend/src/shared/types/profile.ts
• apps/frontend/src/main/services/profile/profile-service.ts
• apps/frontend/src/main/services/profile/index.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/renderer/stores/settings-store.ts
• apps/frontend/src/main/services/profile/profile-manager.ts
• apps/frontend/src/shared/constants/api-profiles.ts
• apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx
• apps/frontend/src/main/ipc-handlers/profile-handlers.ts
• apps/frontend/src/shared/types/ipc.ts
• apps/frontend/src/main/agent/env-utils.ts
• apps/frontend/src/preload/api/profile-api.ts
• apps/frontend/src/shared/types/profile.ts
• apps/frontend/src/main/services/profile/profile-service.ts
• apps/frontend/src/main/services/profile/index.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/renderer/stores/settings-store.ts
• apps/frontend/src/main/services/profile/profile-manager.ts
• apps/frontend/src/shared/constants/api-profiles.ts
• apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx
• apps/frontend/src/main/ipc-handlers/profile-handlers.ts
• apps/frontend/src/shared/types/ipc.ts
• apps/frontend/src/main/agent/env-utils.ts
• apps/frontend/src/preload/api/profile-api.ts
• apps/frontend/src/shared/types/profile.ts
• apps/frontend/src/main/services/profile/profile-service.ts
• apps/frontend/src/main/services/profile/index.ts

apps/frontend/src/shared/i18n/locales/**/*.json

📄 CodeRabbit inference engine (CLAUDE.md)

apps/frontend/src/shared/i18n/locales/**/*.json: Store translation strings in namespace-organized JSON files at apps/frontend/src/shared/i18n/locales/{lang}/*.json for each supported language
When implementing new frontend features, add translation keys to all language files (minimum: en/.json and fr/.json)

Files:

• apps/frontend/src/shared/i18n/locales/fr/settings.json
• apps/frontend/src/shared/i18n/locales/en/settings.json

apps/backend/.env*

📄 CodeRabbit inference engine (CLAUDE.md)

apps/backend/.env*: Enable Electron MCP for E2E testing by setting ELECTRON_MCP_ENABLED=true in .env and starting the Electron app with npm run dev
Configure memory system credentials in apps/backend/.env and validate with graphiti_config.py

Files:

• apps/backend/.env.example

apps/backend/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

apps/backend/**/*.py: Always use the Claude Agent SDK (claude-agent-sdk package) for all AI interactions, never use the Anthropic API directly
Use the create_client() function from apps/backend/core/client.py to instantiate Claude SDK clients, not direct ClaudeSDKClient initialization

Files:

• apps/backend/core/auth.py

---

⚙️ CodeRabbit configuration file

apps/backend/**/*.py: Focus on Python best practices, type hints, and async patterns.
Check for proper error handling and security considerations.
Verify compatibility with Python 3.12+.

Files:

• apps/backend/core/auth.py

apps/backend/core/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

Implement dynamic command allowlisting based on detected project stack using core/security.py for bash command validation

Files:

• apps/backend/core/auth.py

🧠 Learnings (5)

📚 Learning: 2026-01-04T12:37:52.222Z

Learnt from: StillKnotKnown
Repo: AndyMik90/Auto-Claude PR: 648
File: apps/frontend/src/renderer/components/settings/ModelSearchableSelect.tsx:262-265
Timestamp: 2026-01-04T12:37:52.222Z
Learning: Dropdown components in apps/frontend/src/renderer/components/settings use a fixed max-height (e.g., max-h-60) with internal overflow-y-auto scrolling. This pattern is intentional and prevents dropdowns from extending beyond the viewport; do not add dynamic viewport positioning or clipping-prevention logic for these components. If you add new dropdowns in this area, follow the same fixed-height + internal-scroll approach for consistency.

Applied to files:

• apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx

📚 Learning: 2026-01-04T23:59:45.209Z

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:45.209Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings) can be deferred for future i18n cleanup passes. Do not fix such issues in PRs that do not introduce new i18n violations, especially in frontend TSX components (e.g., apps/frontend/**/*.tsx). If a PR adds new i18n violations, address them in that PR.

Applied to files:

• apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx

📚 Learning: 2025-12-30T16:38:36.314Z

Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/shared/i18n/locales/**/*.json : When implementing new frontend features, add translation keys to all language files (minimum: en/*.json and fr/*.json)

Applied to files:

• apps/frontend/src/shared/i18n/locales/fr/settings.json
• apps/frontend/src/shared/i18n/locales/en/settings.json

📚 Learning: 2025-12-30T16:38:36.314Z

Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Use git worktrees for isolated agent builds with branches following the naming pattern `auto-claude/{spec-name}`

Applied to files:

• apps/backend/.env.example

📚 Learning: 2025-12-30T16:38:36.314Z

Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/backend/**/*.py : Always use the Claude Agent SDK (`claude-agent-sdk` package) for all AI interactions, never use the Anthropic API directly

Applied to files:

• apps/backend/core/auth.py

🧬 Code graph analysis (9)

apps/frontend/src/renderer/stores/settings-store.ts (1)

apps/frontend/src/shared/types/profile.ts (2)

• APIProfileType (21-21)
• TestConnectionResult (80-84)

apps/frontend/src/main/services/profile/profile-manager.ts (2)

apps/frontend/src/main/services/profile/index.ts (1)

• APIProfile (37-37)

apps/frontend/src/shared/types/profile.ts (1)

• APIProfile (27-43)

apps/frontend/src/shared/constants/api-profiles.ts (1)

apps/frontend/src/shared/types/profile.ts (1)

• APIProfileType (21-21)

apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx (2)

apps/frontend/src/shared/types/profile.ts (1)

• APIProfileType (21-21)

apps/frontend/src/main/services/profile/profile-service.ts (1)

• testConnection (379-570)

apps/frontend/src/main/ipc-handlers/profile-handlers.ts (3)

apps/frontend/src/shared/types/profile.ts (2)

• APIProfileType (21-21)
• TestConnectionResult (80-84)

apps/frontend/src/main/services/profile/index.ts (2)

• TestConnectionResult (40-40)
• testFoundryConnection (29-29)

apps/frontend/src/main/services/profile/profile-service.ts (1)

• testFoundryConnection (586-710)

apps/frontend/src/shared/types/ipc.ts (1)

apps/frontend/src/shared/types/profile.ts (2)

• APIProfileType (21-21)
• TestConnectionResult (80-84)

apps/frontend/src/preload/api/profile-api.ts (2)

apps/frontend/src/shared/types/profile.ts (1)

• APIProfileType (21-21)

apps/frontend/src/__mocks__/electron.ts (1)

• ipcRenderer (53-61)

apps/frontend/src/shared/types/profile.ts (1)

apps/frontend/src/main/services/profile/index.ts (1)

• APIProfile (37-37)

apps/frontend/src/main/services/profile/profile-service.ts (3)

apps/frontend/src/main/services/profile/index.ts (5)

• validateBaseUrl (21-21)
• validateApiKey (22-22)
• APIProfile (37-37)
• testFoundryConnection (29-29)
• TestConnectionResult (40-40)

apps/frontend/src/main/services/profile-service.ts (2)

• validateBaseUrl (15-27)
• validateApiKey (33-52)

apps/frontend/src/shared/types/profile.ts (2)

• APIProfile (27-43)
• TestConnectionResult (80-84)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)

• GitHub Check: CodeQL analysis (javascript-typescript)
• GitHub Check: CodeQL analysis (python)
• GitHub Check: Agent
• GitHub Check: CodeQL (javascript-typescript)
• GitHub Check: CodeQL (python)

🔇 Additional comments (29)

apps/frontend/src/main/agent/env-utils.ts (3)

6-23: LGTM! Clear and comprehensive documentation.

The JSDoc updates accurately describe the dual-mode behavior (Anthropic + Foundry) and provide excellent rationale for the empty string approach. The explanation of why empty strings are used instead of undefined is particularly helpful for maintainability.

---

25-30: The logic is correct. getAPIProfileEnv() properly includes CLAUDE_CODE_USE_FOUNDRY: '1' when a Foundry profile is active, so the condition on line 26-27 will correctly detect Foundry profiles.

---

32-53: No verification needed—the Foundry variable implementation is consistent and correct.

The code properly clears all Foundry variables (CLAUDE_CODE_USE_FOUNDRY, ANTHROPIC_FOUNDRY_API_KEY, ANTHROPIC_FOUNDRY_BASE_URL, ANTHROPIC_FOUNDRY_RESOURCE) in OAuth mode, and getAPIProfileEnv() correctly sets these same variables when a Foundry profile is active. The backend .env.example provides complete documentation for all Foundry variables.

Note: There is no SDK_ENV_VARS list to maintain—environment variables are passed directly to the Python subprocess.

Likely an incorrect or invalid review comment.

apps/backend/core/auth.py (2)

29-39: LGTM: Foundry environment variables added correctly.

The new Foundry-related environment variables are properly documented with inline comments and examples. The additions integrate well with the existing SDK_ENV_VARS structure.

---

157-163: Verify SDK support for "foundry-entra-id" placeholder with Entra ID authentication.

The code returns "foundry-entra-id" when Foundry mode is enabled without an API key, with a comment indicating the SDK should handle Entra ID auth. However:

1. No token format validation exists in the codebase — The original concern about SDK validating sk-* prefix format is unsupported by code evidence. All usages of get_auth_token() only check truthiness.

2. SDK documentation lacks explicit confirmation — While the Claude SDK supports Microsoft Entra ID authentication via bearer tokens and token providers, the documentation does not explicitly confirm that it recognizes the "foundry-entra-id" placeholder string or includes special handling for it.

3. Risk remains unresolved — If the SDK expects a valid bearer token or API key format rather than a placeholder, this will cause silent auth failures or confusing error messages. The code design assumes the SDK handles this, but explicit verification of this behavior is needed.

Consider:

• Document whether the Claude Agent SDK recognizes this exact placeholder string
• Add comments confirming the SDK auth flow when this placeholder is returned
• Consider using environment-variable-based Entra ID detection instead of a placeholder, if the SDK supports it

apps/backend/.env.example (1)

42-42: The documentation link https://code.claude.com/docs/en/microsoft-foundry is valid and accessible. It contains comprehensive Microsoft Foundry setup instructions.

apps/frontend/src/shared/types/ipc.ts (1)

304-304: LGTM - IPC signature properly extended.

The addition of optional profileType and foundryResource parameters to testConnection maintains backward compatibility and follows the existing pattern for optional parameters.

apps/frontend/src/main/services/profile/profile-manager.ts (1)

28-62: LGTM - Validation logic is well-structured.

The updated validation properly checks required fields and the new optional type and foundryResource fields. The use of early returns improves readability.

Note: This validation requires apiKey to be a string (line 39), which is consistent with the type definition but may conflict with the comment in profile.ts stating that apiKey is "optional" for Foundry profiles. See the related comment on profile.ts.

apps/frontend/src/shared/constants/api-profiles.ts (2)

23-46: LGTM - Non-Foundry presets properly configured.

The remaining presets (OpenRouter, Groq, GLM) are correctly assigned the 'anthropic' type with valid base URLs.

---

17-22: The empty baseUrl for the azure-foundry preset is properly handled by validation.

The UI already prevents saving or testing a Foundry profile without either a baseUrl or foundryResource. The form explicitly validates that at least one is provided (ProfileEditDialog.tsx lines 185, 259, 296), and the backend service enforces the same requirement (profile-service.ts lines 136-140). Additionally, the baseUrl input is disabled when a foundryResource is provided, and users are guided through a dedicated foundryResource field with i18n-supported hints and placeholders.

apps/frontend/src/main/services/profile/index.ts (1)

29-29: No action required. The testFoundryConnection function is properly exported from profile-service.ts (line 586) and the barrel export in index.ts correctly re-exports it, following the established pattern for other service functions.

apps/frontend/src/renderer/stores/settings-store.ts (2)

42-42: LGTM! Extended testConnection signature for Foundry support.

The function signature properly includes optional profileType and foundryResource parameters, maintaining backward compatibility with existing callers.

---

204-207: Correctly forwarding new parameters to IPC layer.

The implementation properly propagates profileType and foundryResource to the window.electronAPI.testConnection call, maintaining consistency with the updated interface.

apps/frontend/src/preload/api/profile-api.ts (2)

34-40: Interface correctly extended for Foundry support.

The testConnection interface signature properly adds profileType and foundryResource as optional parameters, maintaining backward compatibility.

---

106-113: IPC invocation correctly forwards new parameters.

The implementation properly passes profileType and foundryResource to the IPC channel after the requestId, aligning with the handler signature in profile-handlers.ts.

apps/frontend/src/main/services/profile/profile-service.ts (2)

128-151: Profile creation validation properly handles both profile types.

The validation logic correctly:

• Requires baseUrl for Anthropic profiles
• Allows either foundryResource OR baseUrl for Foundry profiles
• Makes API key optional for Foundry (Entra ID auth supported)

---

327-351: Environment variable mapping for Foundry profiles is well-structured.

The Foundry configuration correctly sets:

• CLAUDE_CODE_USE_FOUNDRY=1 to enable Foundry mode
• ANTHROPIC_FOUNDRY_RESOURCE when resource name is provided
• ANTHROPIC_FOUNDRY_BASE_URL when using custom endpoint
• Optional ANTHROPIC_FOUNDRY_API_KEY for API key auth

The logic to prefer foundryResource over baseUrl is appropriate.

apps/frontend/src/shared/i18n/locales/fr/settings.json (2)

65-68: French translations for Foundry profile types are complete.

All required translation keys for the new Foundry feature are present and properly structured in the French locale file. Based on learnings, this follows the requirement to add translation keys to all language files.

---

75-77: Comprehensive Foundry field translations added.

Fields, placeholders, hints, and validation messages for Foundry configuration are all present and appropriately translated to French.

Also applies to: 84-86, 91-93, 100-101

apps/frontend/src/main/ipc-handlers/profile-handlers.ts (2)

189-196: IPC handler signature correctly extended for Foundry support.

The handler now accepts profileType and foundryResource as optional parameters, enabling routing to the appropriate test function based on profile type.

---

210-239: Foundry test connection routing logic is well-implemented.

The handler correctly:

1. Defaults to 'anthropic' when profileType is not specified (backward compatibility)
2. Validates that Foundry profiles have either foundryResource OR baseUrl
3. Calls testFoundryConnection with appropriate parameters
4. Properly cleans up timeout and request tracking on all code paths

apps/frontend/src/shared/i18n/locales/en/settings.json (2)

65-68: English translations for profile types properly added.

The types section clearly distinguishes between "Anthropic API" and "Microsoft Foundry (Azure AI)" for user selection.

---

91-93: Helpful hints for Foundry configuration.

The hints provide clear guidance:

• Resource name format and resulting endpoint URL
• When to use custom endpoint vs resource name
• Entra ID authentication option explanation

apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx (6)

68-71: State management properly extended for Foundry support.

New state variables profileType, foundryResource, and foundryEndpointError are correctly initialized with appropriate default values.

Also applies to: 85-85

---

154-154: Verify useEffect dependency: profile prop not in dependency array.

The comment at line 115 explains this is intentional to prevent race conditions when rapidly clicking edit on different profiles. However, this means if profile prop changes while the dialog is already open, the form won't re-populate with the new profile data.

This is likely the intended behavior based on the comment, but verify this matches the expected UX - if a user somehow triggers a profile prop change while the dialog is open, they would see stale data.

---

183-239: Validation logic correctly implements per-type requirements.

The validation properly handles:

• Foundry: Either foundryResource OR baseUrl required; API key optional but validated if provided
• Anthropic: Both baseUrl and apiKey required

Error states are appropriately cleared/set for each path.

---

504-505: Good UX: Base URL input disabled when resource name is provided.

The disabled={!!foundryResource.trim()} correctly prevents editing the base URL when a resource name is entered, enforcing the "either/or" requirement and guiding users to the correct input.

---

323-343: Save payloads correctly include Foundry-specific fields.

Both update and create paths properly:

1. Include type: profileType in the payload
2. Conditionally include foundryResource only for Foundry profiles
3. Clear foundryResource to undefined for non-Foundry profiles during updates

Also applies to: 357-365

---

517-519: The translation key common:optional exists in both en/common.json and fr/common.json files. No runtime error risk from this key reference.

Likely an incorrect or invalid review comment.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

# First, let's examine the .env.example file to understand the context around line 47
cd apps/backend && cat -n .env.example | sed -n '40,55p'

Repository: AndyMik90/Auto-Claude

Length of output: 871

---

🌐 Web query:

Claude CLI config set global provider azure command documentation

💡 Result:

Short answer: Claude CLI uses claude config set -g <key> <value> for global settings, but Anthropic’s official docs list supported providers as Anthropic API, Amazon Bedrock, and Google Vertex AI — there is no documented global provider value of azure (Azure / Foundry is not shown as a supported provider in the Claude Code docs). (docs.anthropic.com)

Example global command (from docs):

• claude config set -g (e.g., claude config set -g autoUpdaterStatus disabled). (docs.anthropic.com)

If you need to integrate Claude with Azure (Foundry), that typically requires using Azure-specific endpoints/SDKs rather than a simple provider=azure in Claude CLI — see the deployment/provider overview for guidance. (docs.anthropic.com)

Citations:

• 1: https://docs.anthropic.com/en/docs/claude-code/settings?utm_source=openai
• 2: https://docs.anthropic.com/en/docs/claude-code/settings?utm_source=openai
• 3: https://docs.anthropic.com/it/docs/claude-code/third-party-integrations?utm_source=openai

---

The Claude CLI command claude config set --global provider azure is not documented as a valid configuration option.

According to Anthropic's official Claude Code documentation, the supported providers are Anthropic API, Amazon Bedrock, and Google Vertex AI—Azure is not listed as a configurable provider via the CLI. Azure/Foundry integration requires environment-based configuration (e.g., ANTHROPIC_FOUNDRY_API_KEY and endpoint settings) rather than a CLI provider command. Remove this instruction or replace it with the correct environment variable setup for Foundry integration.

🤖 Prompt for AI Agents

In @apps/backend/.env.example at line 47, The comment instructing users to run
"claude config set --global provider azure" is incorrect; remove that CLI
instruction and replace it with guidance to configure Anthropic Foundry via
environment variables instead, e.g., set ANTHROPIC_FOUNDRY_API_KEY (the Foundry
API key) and the Foundry endpoint variable (e.g., ANTHROPIC_FOUNDRY_API_BASE or
ANTHROPIC_FOUNDRY_API_BASE_URL) with the appropriate URL, and mention any other
required env vars for Foundry integration.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Potential resource leak: AbortController timeout not cleared on external signal abort.

When an external signal is provided, a new AbortController is not created (controller is undefined), so timeoutId is also undefined. However, if signal is not provided, the internal controller with timeout is used. If the fetch completes before timeout, clearTimeout(timeoutId) is called correctly.

But there's a subtle issue: if signal is provided and fetch throws an error, the code path doesn't need cleanup since no internal timeout was set. This is actually correct behavior.

However, if signal is NOT provided and the fetch succeeds with any HTTP status (200-599), the timeout is cleared at line 659. But if fetch throws before line 659 (e.g., network error), the catch block doesn't clear the timeout for the internal controller case.

🐛 Proposed fix: Ensure timeout is cleared in catch block

   } catch (error) {
+    // Clear timeout if we created an internal controller
+    if (timeoutId) clearTimeout(timeoutId);
+
     // Handle fetch errors
     if (error instanceof Error) {
       if (error.name === 'AbortError') {

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In @apps/frontend/src/main/services/profile/profile-service.ts around lines 649
- 659, The catch path can leak the internal timeout when controller is created:
ensure that when using the internally created AbortController (variable
controller) you always clear the timeoutId in the error path after a thrown
fetch; update the function surrounding the fetch call (referencing endpointUrl,
fetch, signal, controller, timeoutId) to call clearTimeout(timeoutId) in the
catch/finally path (or use a single finally block) so timeoutId is cleared
whether fetch resolves or throws.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Unreachable success return after status check.

The condition response.status >= 200 && response.status < 600 covers all HTTP responses (2xx, 3xx, 4xx, 5xx), so the success return at lines 678-681 is unreachable. This is a minor code clarity issue.

♻️ Suggested simplification

     // Any HTTP response means the endpoint is reachable
-    // The actual API authentication will be handled by the Claude SDK
-    if (response.status >= 200 && response.status < 600) {
-      // Endpoint is reachable
-      if (apiKey && apiKey.trim() !== '') {
-        return {
-          success: true,
-          message: 'Azure endpoint is reachable. API key configured.'
-        };
-      } else {
-        return {
-          success: true,
-          message: 'Azure endpoint is reachable. Using Entra ID authentication (az login).'
-        };
-      }
+    // Endpoint is reachable - actual API authentication will be handled by the Claude SDK
+    if (apiKey && apiKey.trim() !== '') {
+      return {
+        success: true,
+        message: 'Azure endpoint is reachable. API key configured.'
+      };
+    } else {
+      return {
+        success: true,
+        message: 'Azure endpoint is reachable. Using Entra ID authentication (az login).'
+      };
     }
-
-    return {
-      success: true,
-      message: 'Azure endpoint is reachable.'
-    };

🤖 Prompt for AI Agents

In @apps/frontend/src/main/services/profile/profile-service.ts around lines 663
- 676, The condition checking response.status >= 200 && response.status < 600
treats any HTTP status (2xx–5xx) as "success", making the success returns
unreachable/incorrect; update the logic in the profile-service.ts check that
inspects response.status so that "success" uses a true success range (e.g.,
response.status >= 200 && response.status < 300) and, if you need to assert
endpoint reachability irrespective of success, add a separate branch for
response.status < 600 to return a reachable-but-failed status; adjust the
returns that reference apiKey and the Entra ID message accordingly so they only
occur in the true-success branch while keeping a distinct message/return for
reachable non-success responses.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

# First, let's understand the file structure
fd -t f -name "*profile*" apps/frontend/src --type f | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 295

---

🏁 Script executed:

# Search for apiKey validation and Foundry-related code
rg -n "apiKey" apps/frontend/src --type ts --type tsx -B 2 -A 2 | grep -E "(foundry|Foundry|apiKey)" | head -40

Repository: AndyMik90/Auto-Claude

Length of output: 92

---

🏁 Script executed:

# Look for test-connection logic
rg -n "testConnection|test.*connection" apps/frontend/src --type ts --type tsx -A 5 | head -50

Repository: AndyMik90/Auto-Claude

Length of output: 92

---

🏁 Script executed:

# Check how Foundry profiles validate or handle empty apiKey
rg -n "foundry|Foundry" apps/frontend/src/shared/types/ --type ts -B 2 -A 2

Repository: AndyMik90/Auto-Claude

Length of output: 3066

---

🏁 Script executed:

# Look for Entra ID auth related code
rg -n "entra|Entra|ENTRA" apps/frontend/src --type ts --type tsx -i -B 2 -A 2

Repository: AndyMik90/Auto-Claude

Length of output: 92

---

🏁 Script executed:

# Check the profile.ts file itself to see the full context
cat -n apps/frontend/src/shared/types/profile.ts

Repository: AndyMik90/Auto-Claude

Length of output: 4310

---

🏁 Script executed:

# Look for validation logic in profile-related services
find apps/frontend/src -name "*.ts" -type f | xargs grep -l "apiKey" | head -10

Repository: AndyMik90/Auto-Claude

Length of output: 607

---

🏁 Script executed:

# Search for testConnection implementation and how it handles foundry
find apps/frontend/src -name "*.ts" -type f | xargs grep -l "testConnection" | head -10

Repository: AndyMik90/Auto-Claude

Length of output: 579

---

🏁 Script executed:

# Check the profile service in libs to see actual implementation
find libs -name "*.ts" -type f 2>/dev/null | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 47

---

🏁 Script executed:

# Look for validation of apiKey specifically
rg "apiKey.*=|validate.*apiKey|apiKey.*empty|apiKey.*null" apps/frontend/src -B 3 -A 3

Repository: AndyMik90/Auto-Claude

Length of output: 50379

---

🏁 Script executed:

# Search for Entra ID auth handling
rg -i "entra|azure.*auth|aad" apps/frontend/src -B 2 -A 2

Repository: AndyMik90/Auto-Claude

Length of output: 24220

---

🏁 Script executed:

# Look for where testConnection is actually called and how it handles foundry
rg "testConnection" apps/frontend/src -B 5 -A 5

Repository: AndyMik90/Auto-Claude

Length of output: 50377

---

Update the type definition to clarify apiKey optionality for Foundry profiles.

The type currently requires apiKey: string unconditionally, but the implementation and UI correctly allow empty apiKey for Foundry profiles using Entra ID authentication. Either:

1. Change the type to apiKey: string but update the comment to clarify: "May be empty string for Foundry with Entra ID auth"
2. Or change to apiKey?: string to properly reflect it's optional, but this may require stricter null checks downstream

The runtime behavior is correct—empty apiKey is properly handled for Foundry profiles—but the type signature should reflect this to prevent developer confusion.

🤖 Prompt for AI Agents

In @apps/frontend/src/shared/types/profile.ts around lines 30 - 33, The profile
type currently declares apiKey: string but Foundry profiles can use Entra ID
with no apiKey; change the field to optional (apiKey?: string) in the profile
type declaration (near APIProfileType and the profile interface in profile.ts)
and update any downstream consumers to handle undefined/'' cases (add
null/undefined guards where code assumes a non-empty apiKey). If you prefer to
keep it required, instead update the apiKey comment to explicitly state "May be
empty string for Foundry with Entra ID auth" and add type guards in places that
rely on presence; prefer making it optional to match runtime behavior.

[Copilot]

Pull request overview

This PR adds Microsoft Foundry (Azure AI) support as an alternative authentication method for API Profiles, enabling users to configure Azure-hosted Claude models through the Settings UI with support for both API key and Entra ID authentication.

Key Changes:

• Added 'foundry' profile type alongside existing 'anthropic' type with dedicated validation and test connection logic
• Implemented UI for Foundry-specific fields (Azure Resource Name, Endpoint URL, optional API Key)
• Extended backend to handle Foundry environment variables and authentication placeholder for Entra ID

Reviewed changes

Copilot reviewed 15 out of 16 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
package-lock.json	Extensive peer dependency flag changes (appears unrelated to feature)
apps/frontend/src/shared/types/profile.ts	Added APIProfileType and foundryResource field to profile types
apps/frontend/src/shared/types/ipc.ts	Extended testConnection IPC signature with profileType and foundryResource
apps/frontend/src/shared/i18n/locales/en/settings.json	Added English translations for Foundry profile fields and validation
apps/frontend/src/shared/i18n/locales/fr/settings.json	Added French translations for Foundry profile fields and validation
apps/frontend/src/shared/constants/api-profiles.ts	Added Azure Foundry preset with type='foundry'
apps/frontend/src/renderer/stores/settings-store.ts	Updated testConnection call signature to include new parameters
apps/frontend/src/renderer/components/settings/ProfileEditDialog.tsx	Added conditional UI for Foundry vs Anthropic profiles with type selector
apps/frontend/src/preload/api/profile-api.ts	Extended testConnection API with profileType and foundryResource params
apps/frontend/src/main/services/profile/profile-service.ts	Added testFoundryConnection function and conditional validation logic
apps/frontend/src/main/services/profile/profile-manager.ts	Updated validation to support optional type and foundryResource fields
apps/frontend/src/main/services/profile/index.ts	Exported testFoundryConnection function
apps/frontend/src/main/ipc-handlers/profile-handlers.ts	Added routing logic to call appropriate test function based on profile type
apps/frontend/src/main/agent/env-utils.ts	Extended OAuth clear vars to include Foundry environment variables
apps/backend/core/auth.py	Added Foundry mode detection with placeholder token for Entra ID auth
apps/backend/.env.example	Documented Microsoft Foundry configuration with setup instructions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The condition "response.status >= 200 && response.status < 600" on line 663 will always be true for any HTTP response, making the code on lines 678-681 unreachable. HTTP status codes are always in the range 100-599, so any response will match the first condition. Consider either:

1. Removing the unreachable code block (lines 678-681)
2. Adjusting the condition on line 663 to be more specific (e.g., checking for specific success status codes)
3. Using the unreachable block as the default case and making the condition more restrictive

Suggested change

	if (response.status >= 200 && response.status < 600) {
	// Endpoint is reachable
	if (apiKey && apiKey.trim() !== '') {
	return {
	success: true,
	message: 'Azure endpoint is reachable. API key configured.'
	};
	} else {
	return {
	success: true,
	message: 'Azure endpoint is reachable. Using Entra ID authentication (az login).'
	};
	}
	}
	return {
	success: true,
	message: 'Azure endpoint is reachable.'
	};
	// Endpoint is reachable
	if (apiKey && apiKey.trim() !== '') {
	return {
	success: true,
	message: 'Azure endpoint is reachable. API key configured.'
	};
	} else {
	return {
	success: true,
	message: 'Azure endpoint is reachable. Using Entra ID authentication (az login).'
	};
	}

[Copilot]

When a user enters a foundry resource name, the baseUrl input field is disabled. This prevents users from switching back to using a custom endpoint URL without first clearing the resource name field. This could be confusing UX. Consider either:

1. Allowing both fields to be editable simultaneously and validating that at least one is filled
2. Adding a clear visual indicator or button to help users understand they need to clear the resource name to use a custom URL
3. Adding a radio button or toggle to explicitly choose between "Resource Name" and "Custom URL" modes

[Copilot]

The foundryResource validation doesn't check for invalid characters or format. Resource names in Azure typically have restrictions (e.g., alphanumeric and hyphens only, specific length limits). Currently, any non-empty string is accepted, which could lead to constructing invalid URLs like "https://my resource name!.services.ai.azure.com". Consider adding validation to ensure the resource name contains only valid characters (e.g., lowercase letters, numbers, and hyphens) and meets Azure naming conventions.

[Copilot]

When both foundryResource and baseUrl are provided, the code prioritizes foundryResource and sets ANTHROPIC_FOUNDRY_BASE_URL to an empty string. However, there's no validation or warning in the UI or backend to inform users about this behavior. Users might be confused if they provide both values and the baseUrl is silently ignored. Consider adding a validation warning or documenting this behavior more clearly in the UI hints.

Suggested change

	envVars = {
	CLAUDE_CODE_USE_FOUNDRY: '1',
	// Use foundryResource if provided, otherwise use baseUrl for ANTHROPIC_FOUNDRY_BASE_URL
	ANTHROPIC_FOUNDRY_RESOURCE: profile.foundryResource || '',
	ANTHROPIC_FOUNDRY_BASE_URL: profile.foundryResource ? '' : (profile.baseUrl || ''),
	const hasFoundryResource = !!profile.foundryResource?.trim();
	const hasBaseUrl = !!profile.baseUrl?.trim();
	if (hasFoundryResource && hasBaseUrl) {
	console.warn(
	'[getAPIProfileEnv] Foundry profile has both foundryResource and baseUrl configured; ' +
	'foundryResource will take precedence and ANTHROPIC_FOUNDRY_BASE_URL will be unset.'
	);
	}
	envVars = {
	CLAUDE_CODE_USE_FOUNDRY: '1',
	// Use foundryResource if provided, otherwise use baseUrl for ANTHROPIC_FOUNDRY_BASE_URL
	ANTHROPIC_FOUNDRY_RESOURCE: hasFoundryResource ? profile.foundryResource! : '',
	ANTHROPIC_FOUNDRY_BASE_URL: hasFoundryResource ? '' : (profile.baseUrl || ''),

[Copilot]

For Foundry profiles, the validation checks if apiKey format is valid when provided, but doesn't validate if the apiKey is empty for profiles that might actually need it. While Entra ID auth is supported, users might intend to use API key auth but accidentally leave it empty. Consider adding a user-friendly warning or better documentation in the UI to help users understand when the API key is truly optional vs when it's likely a mistake.

Suggested change

	}
	// For foundry, API key is optional (Entra ID auth supported)
	} else if (profileType === 'foundry') {
	// For foundry, API key is optional (Entra ID auth supported), but if provided it must be non-empty and valid
	const hasApiKeyField = typeof input.apiKey === 'string';
	const trimmedApiKey = hasApiKeyField ? input.apiKey.trim() : '';
	if (hasApiKeyField && trimmedApiKey === '') {
	// Helps users understand that an empty API key is likely a mistake:
	// either provide a real API key, or omit the field entirely to use Entra ID authentication.
	throw new Error('API key is empty. Either provide a valid API key or leave the field blank to use Entra ID authentication.');
	}
	if (trimmedApiKey !== '' && !validateApiKey(trimmedApiKey)) {
	throw new Error('Invalid API key');
	}
	}

[Copilot]

The placeholder token "foundry-entra-id" returned for Foundry mode without an API key may cause issues with authentication validation. This placeholder will be treated as a valid token by require_auth_token() and other authentication checks, but it's not a real authentication credential. Consider either:

1. Returning None when no API key is provided and letting the Claude SDK handle Entra ID authentication
2. Using a more distinctive marker that can be explicitly checked elsewhere in the code (e.g., a constant like FOUNDRY_ENTRA_ID_MARKER)
3. Documenting clearly that this is a placeholder for Entra ID auth and any code that validates tokens should handle this case

The current implementation could lead to unexpected behavior if other parts of the system assume all non-None tokens are valid authentication strings.

[Copilot]

The new Foundry profile type and testFoundryConnection function lack test coverage. The existing test suite in profile-service.test.ts doesn't include tests for:

1. Creating profiles with type='foundry'
2. Validating Foundry-specific fields (foundryResource)
3. Testing the testFoundryConnection function
4. Validating the behavior when both foundryResource and baseUrl are provided
5. Testing getAPIProfileEnv() with Foundry profiles

Consider adding comprehensive test coverage for the new Foundry functionality to match the coverage level of the existing Anthropic profile tests.

[Copilot]

The documentation states "Configure Claude Code CLI first: claude config set --global provider azure" as a prerequisite, but this step may not be necessary for the API Profiles feature since the environment variables are managed by the profile system. This could confuse users who are using the UI-based API Profiles feature. Consider clarifying whether this CLI configuration is required when using API Profiles, or if it's only needed for direct Claude Code CLI usage.

Suggested change

	# 3. Configure Claude Code CLI first: claude config set --global provider azure
	# 3. (CLI only) If you are using the Claude Code CLI directly, run:
	# claude config set --global provider azure
	# This step is NOT required when using UI-based API Profiles, which manage
	# environment variables for you.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx:
- Around line 699-702: Add unit tests for the new Foundry profile behavior in
ProfileEditDialog to cover the missing test cases: create a describe block for
"ProfileEditDialog - Foundry Profile Type" and implement tests that (1) render
ProfileEditDialog, set profileType to 'foundry', and assert foundryResource and
foundryBaseUrl fields are visible, (2) mock testConnection and verify it is
called with profileType='foundry' and the entered foundryResource value, (3)
validate that attempting to run testConnection without a foundryResource shows
validation errors and prevents the call, (4) toggle profileType between
'anthropic' and 'foundry' and assert the correct field sets are shown/hidden,
and (5) verify defaults/clearing behavior when switching types (e.g., anthorpic
fields preserved/cleared as expected); reference ProfileEditDialog component,
testConnection mock, foundryResource, foundryBaseUrl, and profileType when
locating where to add these tests.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ee0c09e and d05e8e7.

📒 Files selected for processing (2)

• apps/frontend/src/main/agent/env-utils.test.ts
• apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx

🧰 Additional context used

📓 Path-based instructions (3)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx
• apps/frontend/src/main/agent/env-utils.test.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx
• apps/frontend/src/main/agent/env-utils.test.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx
• apps/frontend/src/main/agent/env-utils.test.ts

🧠 Learnings (2)

📚 Learning: 2026-01-04T12:37:52.222Z

Learnt from: StillKnotKnown
Repo: AndyMik90/Auto-Claude PR: 648
File: apps/frontend/src/renderer/components/settings/ModelSearchableSelect.tsx:262-265
Timestamp: 2026-01-04T12:37:52.222Z
Learning: Dropdown components in apps/frontend/src/renderer/components/settings use a fixed max-height (e.g., max-h-60) with internal overflow-y-auto scrolling. This pattern is intentional and prevents dropdowns from extending beyond the viewport; do not add dynamic viewport positioning or clipping-prevention logic for these components. If you add new dropdowns in this area, follow the same fixed-height + internal-scroll approach for consistency.

Applied to files:

• apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx

📚 Learning: 2026-01-04T23:59:45.209Z

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:45.209Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings) can be deferred for future i18n cleanup passes. Do not fix such issues in PRs that do not introduce new i18n violations, especially in frontend TSX components (e.g., apps/frontend/**/*.tsx). If a PR adds new i18n violations, address them in that PR.

Applied to files:

• apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (javascript-typescript)
• GitHub Check: CodeQL (python)

🔇 Additional comments (4)

apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx (1)

517-520: LGTM! Test expectations correctly updated for anthropic profiles.

The additional parameters (AbortSignal, profileType='anthropic', foundryResource='') properly reflect the expanded testConnection signature introduced to support dual profile types.

apps/frontend/src/main/agent/env-utils.test.ts (3)

31-47: Assertions properly extended to verify Foundry variable clearing.

The test description and individual assertions correctly validate that all Foundry environment variables are cleared in OAuth mode, maintaining consistency with the existing Anthropic variable assertions.

---

123-138: Consistent object shape verification correctly updated.

The expected keys array now includes all 11 environment variables (increased from 7), with explicit listing that makes the test self-documenting. The use of .sort() ensures order-independent comparison.

---

14-28: Test expectations correctly updated for Foundry support.

The test expects 11 environment variables to be cleared in OAuth mode (7 standard Anthropic + 4 Foundry variables). The implementation in env-utils.ts confirms all Foundry variables (CLAUDE_CODE_USE_FOUNDRY, ANTHROPIC_FOUNDRY_API_KEY, ANTHROPIC_FOUNDRY_BASE_URL, ANTHROPIC_FOUNDRY_RESOURCE) are properly included in the clearing logic and match the test expectations exactly. The added comments improve readability by distinguishing between variable groups.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Test expectations updated correctly, but Foundry test coverage is missing.

The parameter additions properly align with the expanded testConnection signature. However, the PR introduces significant Foundry-specific functionality (profile type selector, Foundry resource field, Foundry endpoint URL, Foundry-specific test connection) with no test coverage.

Consider adding test coverage for the new Foundry profile type:

📋 Suggested Foundry test scenarios

describe('ProfileEditDialog - Foundry Profile Type', () => {
  it('should show Foundry-specific fields when profile type is foundry', () => {
    // Test that foundryResource and foundryBaseUrl fields appear
  });

  it('should pass foundryResource to testConnection for foundry profiles', () => {
    // Verify testConnection receives profileType='foundry' and the resource value
  });

  it('should validate required Foundry fields before testing connection', () => {
    // Ensure foundryResource is required for foundry type
  });

  it('should switch between Anthropic and Foundry field sets when type changes', () => {
    // Test profile type selector behavior
  });

  it('should apply correct defaults when switching profile types', () => {
    // Verify field clearing/defaulting on type change
  });
});

Do you want me to generate complete test implementations for the Foundry functionality?

🤖 Prompt for AI Agents

In @apps/frontend/src/renderer/components/settings/ProfileEditDialog.test.tsx
around lines 699 - 702, Add unit tests for the new Foundry profile behavior in
ProfileEditDialog to cover the missing test cases: create a describe block for
"ProfileEditDialog - Foundry Profile Type" and implement tests that (1) render
ProfileEditDialog, set profileType to 'foundry', and assert foundryResource and
foundryBaseUrl fields are visible, (2) mock testConnection and verify it is
called with profileType='foundry' and the entered foundryResource value, (3)
validate that attempting to run testConnection without a foundryResource shows
validation errors and prevents the call, (4) toggle profileType between
'anthropic' and 'foundry' and assert the correct field sets are shown/hidden,
and (5) verify defaults/clearing behavior when switching types (e.g., anthorpic
fields preserved/cleared as expected); reference ProfileEditDialog component,
testConnection mock, foundryResource, foundryBaseUrl, and profileType when
locating where to add these tests.

[don4of4]

@riccardo-algorime Are you planning on addressing the PR feedback and/or do you need any help? Would love to get this merged.

[riccardo-algorime]

I can try to help, is it needed? im not an expert in this type of dev