Add Azure / Foundry launch support to VS Code extension#1365
Conversation
…penAI support. Added configuration options for Azure API key, endpoint, and deployment settings. Updated README and documentation for new features, including a setup wizard for Azure integration. Improved terminal launch environment handling for Azure compatibility.
Resolve conflicts by taking upstream extension, then restore openclaude.azure.* settings, Secret Storage key commands, wizard, Control Center quick link, and launch env merge for Microsoft Foundry / Azure OpenAI. Made-with: Cursor
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
I found issues that need to be addressed before this is ready.
Findings
-
[P1] Rebase because the PR no longer merges cleanly
docs/quick-start-windows.md:145
The current PR branch conflicts with the target branch indocs/quick-start-windows.mdwhen merged against the fetched base (git merge-tree FETCH_HEAD HEADreports a content conflict in this file). The base branch has added extra guidance under the same "Need Advanced Setup?" section that this PR edits, so this branch cannot be merged as-is. Please rebase or merge the latest base branch and preserve both the existing advanced setup description and the new Windows aliases link. -
[P2] Make the Windows aliases setup usable from the linked quick start
docs/windows-aliases-and-launchers.md:12
The Windows quick-start flow installs@gitlawb/openclaudeglobally, then links to this page, but the setup snippet points at a hard-coded local source checkout (C:\Users\Window\Documents\CFGit\openclaude) and dot-sourcesscripts\windows\openclaude-aliases.ps1. The published package only includesbin/,dist/cli.mjs, andREADME.md, so a user following the new quick-start link afternpm install -gwill hitAlias script not foundunless they already cloned the repository to that exact example path. Please either document the source-checkout prerequisite and require users to set their own repo path, or package/install the alias script in a location the global-install workflow can actually use.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughThis PR adds Microsoft Foundry / Azure OpenAI terminal injection and VS Code controls (secret storage, wizard, Control Center wiring), expands OpenAI shim Azure detection/forcing, introduces Windows PowerShell alias/launcher scripts and docs, and updates package.json to publish the new artifacts. ChangesAzure OpenAI Integration and Windows Tooling
Sequence DiagramsequenceDiagram
participant User
participant VSCode_Extension
participant SecretStorage
participant Terminal_Shell
participant OpenAI_Shim
participant Azure_OpenAI
User->>VSCode_Extension: run configureAzureChat / set key
VSCode_Extension->>SecretStorage: store API key
User->>VSCode_Extension: launch OpenClaude (Control Center)
VSCode_Extension->>Terminal_Shell: create terminal with injected OPENAI_*/AZURE_OPENAI_API_VERSION env
Terminal_Shell->>OpenAI_Shim: make request using env
OpenAI_Shim->>Azure_OpenAI: construct /openai/deployments/{deployment}/chat/completions with api-key header
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Thanks for the review. I addressed both requested items.
Validation performed:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@package.json`:
- Around line 23-24: The published Windows helper references TypeScript
entrypoints that aren’t packaged; update either package contents or the helper:
either add the runtime scripts (scripts/provider-bootstrap.ts,
scripts/provider-launch.ts, scripts/build.ts, scripts/provider-recommend.ts) and
any required deps to the package.json "files" whitelist so profile:init,
dev:profile/dev:*, build and profile:recommend work, or modify
scripts/windows/openclaude-aliases.ps1 to call the compiled/installed CLI
artifacts (the built JS binaries or npm/bin commands) instead of using "bun run"
for the .ts files; pick one approach and ensure the referenced symbols
(profile:init, dev:*, build, profile:recommend and scripts/*.ts) are consistent
with the published package.
In `@scripts/windows/openclaude-aliases.ps1`:
- Around line 51-66: Replace use of the automatic $args variable with a
dedicated local variable (e.g., $bunArgs) used to build the argument array for
the bun call: initialize the new variable with
@("run","profile:init","--","--provider",$Provider), append model/goal/api-key
entries based on $Model, $Provider, $Goal, and $ApiKey exactly where the
existing code does, then invoke bun with the new variable instead of $args and
keep the existing $LASTEXITCODE check and error message for "profile:init
failed".
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 52dc9409-2be7-4910-8c0f-b046b0e06165
📒 Files selected for processing (11)
README.mddocs/advanced-setup.mddocs/quick-start-windows.mddocs/windows-aliases-and-launchers.mdpackage.jsonscripts/windows/openclaude-aliases.ps1src/services/api/openaiShim.tsvscode-extension/openclaude-vscode/.vscode/launch.jsonvscode-extension/openclaude-vscode/README.mdvscode-extension/openclaude-vscode/package.jsonvscode-extension/openclaude-vscode/src/extension.js
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
Thanks for the update. I rechecked the previously discussed paths and found one issue that still needs to be addressed.
Findings
- [P2] Complete CodeRabbit's package-runtime request for the Windows helpers
package.json:23
CodeRabbit's package-runtime item is only partially addressed here. The package now includesscripts/windows/openclaude-aliases.ps1and the top-level provider/build TypeScript entrypoints, but those entrypoints still import files that are not included in the published package, such as../src/services/api/providerConfig.js,../src/utils/providerProfile.ts, and./provider-discovery.ts. In an extracted package built from this PR,bun run profile:init -- --provider ollama --model llama3.1:8bfails immediately withCannot find module '../src/services/api/providerConfig.js', so the documented global-install alias flow still cannot runoc-init,oc-provider, or thebun run dev:*launch paths from the installed package. Please complete that review request by either packaging the full transitive runtime those scripts need, or by changing the helper to call packaged/bundled CLI artifacts instead of source-only Bun scripts.
|
Thanks for catching this. You were right the previous patch only addressed the top-level package whitelist and I should have followed the transitive runtime path further. Adding the TypeScript entrypoints was not enough because those scripts still depended on source files that are not part of the published package. I reworked the Windows helper to avoid that source-checkout dependency entirely. The published helper no longer calls Validation performed:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/windows/openclaude-aliases.ps1`:
- Around line 69-98: oc-local and oc-fast set process-scoped env vars
(CLAUDE_CODE_USE_OPENAI, OPENAI_BASE_URL, OPENAI_MODEL, and
OPENCLAUDE_FAST_MODE) and never restore them, causing later oc invocations to
inherit them; update both functions (oc-local and oc-fast) to save the previous
values of those env vars before setting them, wrap the Invoke-OpenClaude call in
a try/finally, and in the finally restore each env var to its prior value (or
remove it if it was undefined) so the environment is not sticky for subsequent
calls, or alternately document that these aliases are intentionally sticky if
you prefer that behavior (reference functions: oc-local, oc-fast; call:
Invoke-OpenClaude; affected env vars: CLAUDE_CODE_USE_OPENAI, OPENAI_BASE_URL,
OPENAI_MODEL, OPENCLAUDE_FAST_MODE; related logic:
src/utils/providerProfiles.ts).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 740f6d80-175d-403f-9110-db33c7511ea9
📒 Files selected for processing (1)
scripts/windows/openclaude-aliases.ps1
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
Thanks for the update. I rechecked the previously discussed paths and found one issue that still needs to be addressed.
Findings
- [P2] Align the Windows helper docs with the shipped aliases
docs/windows-aliases-and-launchers.md:47
The new Windows aliases page still describes the old profile-initialization flow:oc-initis documented as saving and launching with a provider profile, and the daily commands advertiseoc-provider -Provider ollama -Goal coding,-Model, and-ApiKeyexamples. The shipped helper no longer implements those surfaces:oc-initonly pulls/checks Ollama and callsoc-local, whileoc-providerhas no parameters and just runsopenclaude "/provider"; running the documentedoc-provider -Provider ollama -Goal codingcommand fails withA parameter cannot be found that matches parameter name 'Provider'. Please update the docs to match the installed-CLI/env-invocation behavior, or restore the documented provider-profile command parameters.
|
Thanks for the follow-up. I addressed the remaining docs/package alignment issue you called out. The Windows aliases documentation now matches the shipped helper behavior:
Validation performed:
|
jatmn
left a comment
jatmn
left a comment
There was a problem hiding this comment.
Thanks for the update. I rechecked the previously discussed paths and do not see any remaining actionable issues from my side.
@kevincodex1 lgtm
* Enhance OpenClaude VS Code extension with Microsoft Foundry / Azure OpenAI support. Added configuration options for Azure API key, endpoint, and deployment settings. Updated README and documentation for new features, including a setup wizard for Azure integration. Improved terminal launch environment handling for Azure compatibility. * Fix packaged Windows helper runtime references * Use installed CLI from Windows helper aliases * Scope Windows helper env overrides to invocation * Align Windows alias docs with shipped helper
3 participants
Summary
openclaude.azure.*settings, Secret Storage support for the API key, command-palette actions, a setup wizard, and a Control Center shortcut for Azure / Foundry configuration.AZURE_OPENAI_API_VERSION, andOPENAI_AZURE_STYLEfor Foundry/non-standard Azure hosts.This keeps Azure / Foundry setup out of committed config where possible, while making the VS Code terminal launch path work with enterprise Azure OpenAI deployments.
Impact
user-facing impact:
oc,oc-init,oc-local,oc-provider, andoc-check.developer/maintainer impact:
openclaude.useOpenAIShimbehavior, but avoids overriding the fuller Azure env when configured.Testing
bun run buildbun run smokenode --check vscode-extension/openclaude-vscode/src/extension.jsscripts/windows/openclaude-aliases.ps1bunwas not available in my current Windows shell, so I could not honestly mark the full build/smoke checks as completed.Notes
CLAUDE_CODE_USE_OPENAI=1,OPENAI_BASE_URL,OPENAI_MODEL,OPENAI_API_KEY,AZURE_OPENAI_API_VERSION, and optionalOPENAI_AZURE_STYLE=1.bun run buildandbun run smokechecks in their normal dev environment.Summary by CodeRabbit
New Features
Documentation
New Tools
Chores