[Bug]: Optional model alias blocks OpenAI-compatible onboarding

[omandryk]

Summary

During OpenAI-compatible provider onboarding in OpenClaw Companion, the step labeled Model alias (optional) cannot be submitted with an empty value because the Continue button is disabled.

The field is optional in the Gateway onboarding flow, so users should be able to leave it blank.

Steps to reproduce

1. Start OpenClaw Companion onboarding.
2. Choose the OpenAI-compatible/custom provider path.
3. Complete the endpoint, API key, compatibility, model ID, and endpoint ID steps.
4. Reach Model alias (optional).
5. Leave the field empty.

Actual behavior

Continue remains disabled. Entering an alias is required to proceed despite the field being labeled optional.

Expected behavior

Continue remains available and submits the empty string to the Gateway. The Gateway should remain authoritative for text-field validation so it can accept optional empty values and return its own validation message for required fields.

Current-main evidence

Current Companion main still treats every text wizard step as requiring non-whitespace input in WizardSelection.ShouldDisableContinue, and WizardPage.UpdateContinueState uses that gate for all text steps. The Gateway wizard protocol does not currently expose whether an individual text step is required.

A local patch and regression tests are prepared. The patch also handles the Gateway's successful non-terminal validation response (error plus the same step) so required-field errors remain visible, entered text is preserved, and rejected answers are not appended to the transcript.

Environment

• Surface: OpenClaw Companion onboarding on Windows
• Flow: OpenAI-compatible/custom model provider
• Observed: September 5, 2026
• Current repository main inspected at 305bb4ef5334ded9f8541aca19c66ba2c4b08754

Additional context

The original observation included a screenshot showing the empty Model alias (optional) field with a disabled Continue button. The screenshot is not attached here because it was shared in a separate private conversation and is not being republished without a directly available upload artifact.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 9, 2026, 3:19 PM ET / 19:19 UTC.

Summary
Current main and the latest release still reject blank wizard text. The open linked fix already owns this bug and now includes Windows evidence showing successful blank-alias submission.

Reproducibility: yes. source inspection establishes the failure: an empty text step disables Continue and is rejected before wizard.next. No application execution or tests were performed in this read-only review.

Next step
Review and resolve #1332 through its required validation; keep this issue open until the fix lands rather than dispatching duplicate implementation.

Review details

Best possible solution:

Let Gateway validators accept or reject text answers, while Companion preserves rejected input and displays inline errors without recording rejected answers as completed turns.

Do we have a high-confidence way to reproduce the issue?

Yes, source inspection establishes the failure: an empty text step disables Continue and is rejected before wizard.next. No application execution or tests were performed in this read-only review.

Is this the best way to solve the issue?

Yes, delegating text validation to the Gateway fits the documented server-driven wizard and avoids guessing requiredness from prompt labels; the linked fix also addresses inline validation retries.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 5e9aae95373c.

Label changes

Label justifications:

• P1: A reported provider-onboarding workflow remains broken on main and the latest release, consistent with the human priority escalation.
• impact:ux-friction: Users must invent an alias to proceed past a field explicitly labeled optional; entering one provides an in-product workaround.

Evidence reviewed

What I checked:

• Current-main defect: The checkout matches the supplied current-main SHA. ShouldDisableContinue returns true for every empty or whitespace-only text answer, without distinguishing optional prompts. (src/OpenClaw.SetupEngine/WizardSelection.cs:43, 5e9aae95373c)
• Both UI and submission enforce the gate: TryBuildAnswerValue rejects blank text at line 1059, and UpdateContinueState disables the button through the same policy at line 1086. SendCurrentAnswerAsync returns before wizard.next when answer construction fails. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:1059, 5e9aae95373c)
• Existing tests encode the overly strict behavior: ContinueDisabled_ForEmptyTextInput expects null, empty, and whitespace-only inputs to disable Continue. (tests/OpenClaw.SetupEngine.Tests/WizardSelectionTests.cs, 5e9aae95373c)
• Gateway validation contract: The linked fix explicitly depends on this Gateway contract. At its cited revision, the text prompter passes its validator to awaitAnswer; WizardSession.answer accepts scalar text, invokes the validator, and retains the pending step on rejection. This supports Gateway-owned validation rather than a blanket Companion nonempty requirement. (src/wizard/session.ts, 20d0daa063c0)
• Latest release remains affected: The same blanket text gate exists in v2026.7.1-4. The tag resolves to c7c6fb0, matching the supplied latest release. (src/OpenClaw.SetupEngine/WizardSelection.cs:43, c7c6fb06be03)
• Open implementation candidate: The supplied closing relationship identifies fix(setup): allow optional wizard text input #1332 as the same author's fix. A live REST check confirms it remains open, draft, and unmerged at c6b73ad. (c6b73ad1237e)

Likely related people:

• Ranjesh: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Karen: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[github-actions]

This issue has been automatically marked as stale due to inactivity.
Please add updated OpenClaw Windows details or it will be closed.