Summary

When OAuth setup runs through an RPC wizard client, the gateway can ask for a redirect URL while only printing the authorization URL to gateway stdout. That leaves clients like the Windows companion without the link the user needs to open.

This PR makes redirect-paste OAuth prompts self-contained by including the generated authorization URL directly in the wizard text prompt. Terminal logging is preserved.

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 #
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

Behavior addressed: RPC wizard OAuth setup now shows the generated authorization URL in the same text prompt that asks for the redirect URL.
Real environment tested: Windows companion app driving an OpenClaw gateway wizard OAuth setup flow, plus the local Windows OpenClaw worktree.
Exact steps or command run after this patch: Opened the Windows companion, started the gateway/provider OAuth wizard flow, verified the wizard prompt displayed the authorization URL before the redirect URL input, opened the URL in a browser, and completed the redirect paste step. Also ran node scripts/run-vitest.mjs run src\plugins\provider-oauth-flow.test.ts extensions\openai\openai-chatgpt-oauth.runtime.test.ts extensions\google\oauth.test.ts extensions\openrouter\oauth.test.ts src\commands\auth-choice.apply.plugin-provider.test.ts src\wizard\session.test.ts; pnpm tsgo:core && pnpm tsgo:core:test && pnpm tsgo:extensions && pnpm tsgo:extensions:test; pnpm exec oxlint <touched files>; git diff --check.
Evidence after fix: Human verification confirmed the Windows companion wizard showed the OAuth authorization URL inline with the redirect paste prompt. Focused tests also assert authorization URLs are included in prompt messages for the shared OAuth helper, Gemini, OpenAI ChatGPT/Codex, and OpenRouter paths.
Observed result after fix: The Windows companion flow exposed the authorization URL in the wizard prompt and the redirect paste step could be completed. Focused Vitest passed 5 shards / 64 tests; TypeScript core/test and extensions/test checks passed; direct oxlint on touched files passed; git diff --check passed.
What was not tested: Full repository pnpm check, full repository pnpm test, and every provider's live OAuth service.
Before evidence (optional but encouraged): Before this patch, the gateway printed the authorization URL to runtime.log / stdout while the wizard step only asked for a redirect URL.

Root Cause (if applicable)

• Root cause: OAuth redirect flows treated runtime logs as the user-facing place to show authorization URLs, but RPC wizard clients receive wizard steps rather than gateway stdout.
• Missing detection / guardrail: Existing tests covered local CLI/provider OAuth behavior but not whether RPC-visible prompt messages contained the URL needed to complete manual redirect flows.
• Contributing context (if known): RPC wizard clients need the auth challenge rendered in-band even when the gateway process itself can write the URL to logs.

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: src/plugins/provider-oauth-flow.test.ts, extensions/openai/openai-chatgpt-oauth.runtime.test.ts, extensions/google/oauth.test.ts, extensions/openrouter/oauth.test.ts, src/commands/auth-choice.apply.plugin-provider.test.ts, src/wizard/session.test.ts.
• Scenario the test should lock in: Manual OAuth redirect prompts include the generated authorization URL in the prompt message; auth-presenting RPC prompters use the manual path; CLI/non-auth-presenting paths keep their existing note/log behavior.
• Why this is the smallest reliable guardrail: It covers the shared helper, representative provider integrations, and wizard/auth-choice seam without requiring live OAuth credentials.
• Existing test that already covers this (if any): N/A; focused coverage was added/updated.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

RPC wizard clients now receive OAuth authorization URLs directly in the text prompt message for redirect-paste flows. Terminal CLI users still see URL logging and the same prompt flow.

Diagram (if applicable)

Before:
OAuth provider -> gateway runtime.log(url) -> RPC client only sees "paste redirect URL"

After:
OAuth provider -> wizard text message includes url -> RPC client shows url + paste box -> user completes login

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A. The authorization URL was already intentionally logged for user action; this change carries the same non-secret authorization URL in the wizard prompt message. Redirect URLs containing authorization codes remain user input.

Repro + Verification

Environment

• OS: Windows
• Runtime/container: Node/pnpm OpenClaw worktree
• Model/provider: Windows companion OAuth wizard flow, plus OpenAI ChatGPT/Codex OAuth, Chutes/shared OAuth helper, Google Gemini CLI OAuth, and OpenRouter OAuth seams via focused tests
• Integration/channel (if any): Gateway wizard / provider auth prompts
• Relevant config (redacted): OAuth credentials and generated authorization URLs redacted

Steps

1. Open the Windows companion against the patched gateway.
2. Start a provider OAuth wizard flow that uses redirect-URL paste.
3. Confirm the wizard text prompt includes the generated authorization URL and the redirect paste instruction.
4. Open the authorization URL in the browser and complete the redirect paste step.

Expected

• The protocol-visible text step message contains the authorization URL needed to complete OAuth.

Actual

• The Windows companion showed the authorization URL in the wizard prompt and the redirect paste step completed.

Evidence

Attach at least one:

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

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Windows companion OAuth wizard prompt showed the generated authorization URL inline with the redirect paste prompt; shared OAuth helper remote and local fallback prompts include the authorization URL; Gemini manual OAuth prompt includes the URL; OpenAI auth-presenting flow collapses copy into the redirect paste prompt; OpenRouter remote OAuth prompt includes the URL.
• Edge cases checked: Existing terminal logging remains; local fallback prompt stays unchanged before an auth URL exists.
• What you did not verify: Full repository test suite and every provider's live OAuth service.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Risks and Mitigations

• Risk: Authorization URLs become visible in a wizard prompt message instead of only gateway logs.
  • Mitigation: These URLs were already intentionally shown/logged for users and do not contain the returned authorization code; the secret-bearing redirect remains user input.
• Risk: Prompt messages become longer for OAuth redirect flows.
  • Mitigation: The longer prompt is self-contained and preserves compatibility for clients that render only message text.

AI-assisted: Yes. Implemented with Copilot-assisted sessions and reviewed by separate adversarial compatibility passes before simplifying to the message-only approach.