Skip to content

[Feature]: One-step mobile QR/setup-code pairing #98242

Description

@Solvely-Colin

Summary

Make mobile QR/setup-code onboarding one-step for fresh OpenClaw Gateway pairing.

Problem to solve

Fresh iOS/Android users should not have to scan or paste setup material, then manually approve separate mobile device, node, and operator handoff requests. The current product goal is that a setup QR or setup code fully configures the app and lets the Gateway approve the fresh baseline mobile node/device/operator handoff automatically, while keeping later upgrades explicit.

Proposed solution

Use the existing setup-code bootstrap profile as the trusted fresh-mobile baseline: QR/setup code carries gateway URL plus bootstrap token, the app saves that connection profile, and the Gateway silently approves the fresh device and node pairing when the bootstrap metadata proves native mobile onboarding. Add a short-code redemption seam for same-Gateway setup-code payloads where the app already knows the Gateway URL.

Alternatives considered

  • Hosted rendezvous service: useful later for bare short codes with no known Gateway URL, but it is separate infrastructure and not required for QR/setup-code onboarding.
  • Copying raw gateway token/password into mobile by default: rejected because the bounded bootstrap token/device-token handoff satisfies the onboarding goal with a smaller credential surface.
  • Granting admin/pairing scopes during setup: rejected; the baseline should stay bounded and require explicit approval for later upgrades.

Impact

Affected: new mobile users pairing iOS/Android with an OpenClaw Gateway.
Severity: Medium to high onboarding friction today.
Frequency: Every fresh mobile pairing.
Consequence: Users currently face extra setup and approval steps instead of one QR/setup-code action.

Evidence/examples

Additional information

Security requirements: short codes are TTL-bound and single-use, setup-code bootstrap remains bounded to node/operator baseline roles, no admin/pairing scopes are granted by default, and public cleartext Gateway URLs remain rejected outside loopback/private LAN allowances.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:needs-security-reviewClawSweeper marked this issue as needing security-sensitive review.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.enhancementNew feature or requestimpact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.impact:securitySecurity boundary, credential, authz, sandbox, or sensitive-data risk.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.maintainerMaintainer-authored PRmaturity:stableIssue affects a taxonomy feature currently scored M4/M5.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions