PR #67660: fix(msteams): use explorer.exe for delegated OAuth on win32

• Repository: openclaw/openclaw
• Author: shaun0927
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67660

Description (problem / solution / changelog)

Summary

• Problem: openDelegatedOAuthUrl() in extensions/msteams/src/setup-surface.ts used open on macOS and xdg-open everywhere else, so native win32 delegated OAuth setup tried the Linux launcher instead of the repository's normal Windows browser-open command.
• Why it matters: OpenClaw documents Windows support, and MS Teams delegated OAuth is part of setup/onboarding. Using xdg-open on win32 breaks that path and diverges from the shared Windows browser-open behavior.
• What changed: add an explicit win32 -> explorer.exe branch for delegated OAuth launch, treat explorer.exe as a fire-and-forget Windows launcher when it exits without a signal, update the existing shell-safety test to reflect platform-specific commands, add Windows-specific regression coverage, and record the fix in the changelog.
• What did NOT change (scope boundary): no changes to OAuth scopes, token handling, prompt/setup flow logic, or the shared browser-open helper.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #67659
• Related #67659
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the MS Teams setup surface hardcoded a two-way launcher split (darwin -> open, everything else -> xdg-open) instead of handling win32 separately, and its generic non-zero exit rejection was not compatible with explorer.exe's fire-and-forget exit behavior.
• Missing detection / guardrail: the existing test only asserted shell: false and mirrored the same incomplete platform split, so it never locked in a Windows command expectation or a Windows-specific exit-path expectation.
• Contributing context (if known): the repo already has a platform-aware browser-open helper that uses explorer.exe on Windows, but extension code cannot import core src/** helpers directly under the extensions boundary contract.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/msteams/src/setup-surface.test.ts
• Scenario the test should lock in: delegated OAuth launch uses explorer.exe when process.platform === "win32", preserves shell: false, and resolves on the observed Windows no-signal exit path.
• Why this is the smallest reliable guardrail: the bug is a platform selection + exit handling error in a small wrapper around spawn, so a focused unit test catches it without needing a live OAuth round trip.
• Existing test that already covers this (if any): the existing shell-safety test covers the no-shell invariant; this PR extends it and adds the missing win32 assertions.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Native Windows MS Teams delegated OAuth setup now launches with explorer.exe instead of xdg-open.
• The Windows launcher path no longer rejects on the observed clean explorer.exe exit path.

Diagram (if applicable)

Before:
[Windows delegated OAuth setup] -> [xdg-open URL] -> [launcher mismatch / broken setup path]
OR
[explorer.exe URL] -> [exit code rejected] -> [setup reports retry later]

After:
[Windows delegated OAuth setup] -> [explorer.exe URL] -> [native Windows browser launch]

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS host for local tests; win32 behavior validated by stubbing process.platform
• Runtime/container: local pnpm workspace checkout
• Model/provider: N/A
• Integration/channel (if any): MS Teams setup surface
• Relevant config (redacted): N/A

Steps

1. Stub process.platform to "win32" in extensions/msteams/src/setup-surface.test.ts.
2. Call openDelegatedOAuthUrl("https://login.microsoftonline.com/auth").
3. Observe the spawned command and the resolved promise behavior.

Expected

• spawn("explorer.exe", [url], { stdio: "ignore", shell: false })
• Promise resolves on the observed no-signal Windows exit path.

Actual

• Before this fix, the code selected xdg-open for all non-darwin platforms and rejected any non-zero exit.
• After this fix, the win32 path selects explorer.exe, and the regression tests pass for both command selection and the Windows exit-path behavior.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • ran node scripts/test-projects.mjs extensions/msteams/src/setup-surface.test.ts
  • confirmed the updated shell-safety test still passes on the current platform
  • confirmed the win32 regression test passes with process.platform stubbed to win32
  • confirmed the win32 exit-path regression test passes when explorer.exe exits with code 1 and no signal
• Edge cases checked:
  • macOS path still uses open
  • non-macOS / non-win32 path still uses xdg-open
  • launcher still uses shell: false
• What you did not verify:
  • a live delegated OAuth flow on a native Windows machine

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: the Windows launcher now accepts the clean no-signal explorer.exe exit path instead of treating it as fatal.
  • Mitigation: scope is limited to the win32 delegated OAuth path, and the test suite locks in the command selection plus the Windows-specific exit behavior.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/msteams/src/setup-surface.test.ts (modified, +64/-4)
• extensions/msteams/src/setup-surface.ts (modified, +4/-2)

PR #67738: fix: MS Teams OAuth on Windows and browser.cdpUrl security redaction

• Repository: openclaw/openclaw
• Author: nightq
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67738

Description (problem / solution / changelog)

Summary

Fixes two issues:

1. #67659 - MS Teams delegated OAuth launcher uses xdg-open on Windows instead of explorer.exe
2. #67656 - Config API redaction does not cover browser.cdpUrl paths

Root Cause

1. For #67659: The function only checked for Darwin (macOS) and defaulted to for all other platforms, including Windows.
2. For #67656: The function did not include paths, allowing credentials in browser CDP URLs to leak in config responses.

Fix

1. Added explicit platform check for Windows () to use instead of
2. Added suffix check to to ensure browser CDP URLs are treated as sensitive

Test Plan

• Unit tests pass for redact-sensitive-url
• Schema hint tests pass
• Code follows existing patterns

Closes openclaw#67659 Closes openclaw#67656

Changed files

• extensions/msteams/src/setup-surface.test.ts (modified, +7/-1)
• extensions/msteams/src/setup-surface.ts (modified, +7/-2)
• src/shared/net/redact-sensitive-url.test.ts (modified, +2/-0)
• src/shared/net/redact-sensitive-url.ts (modified, +3/-0)