Best possible solution:

Fix the concrete lint, docs-map, iOS scheme, stale-helper, and Telegram-doc blockers, then merge only if maintainers accept the pre-auth short-code and silent node-approval boundary.

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

Not applicable as a bug reproduction: this PR implements a requested feature. Source and CI inspection do reproduce merge blockers, including the setup-short-code lint failure and docs-map failure on the PR head.

Is this the best way to solve the issue?

No in the current patch state: the implementation uses plausible existing bootstrap seams, but the iOS short-code scheme, CI blockers, stale helper, docs mismatch, and security boundary need resolution before this is the best mergeable solution.

Full review comments:

• [P2] Use the correct local scheme for short-code redemption — apps/ios/Sources/Onboarding/OnboardingWizardView.swift:750-751
  Fresh onboarding seeds openclaw.local:18789 with TLS enabled in UI state, but the default local Gateway is commonly reached over plain ws:///http://. Building the redemption URL from manualTLS here makes a bare short code try https://openclaw.local:18789/... and fail before it can retrieve the actual setup payload; the Settings helper has the same construction.
  Confidence: 0.9
• [P2] Satisfy oxlint without spreading the code string — src/pairing/setup-short-code.ts:86
  The PR head's check-lint job fails on this expression with typescript(no-misused-spread). Replace the spread with a lint-accepted character iteration or character-class check so the new short-code file can pass the required lint gate.
  Confidence: 0.98
• [P2] Regenerate the docs map for the new docs text — docs/gateway/protocol.md:181
  The PR changes public docs but does not refresh docs/docs_map.md; the check-docs job reports docs:map: docs/docs_map.md is out of date. Regenerate the docs map after the pairing/protocol docs changes so the docs gate passes.
  Confidence: 0.92
• [P2] Remove or reuse the stale setup-code helper — apps/ios/Sources/Design/SettingsProTabActions.swift:251
applySetupCodeAndConnect() now goes through resolveSetupInputForConnect(), leaving applySetupCode() as an unused older parser path that can diverge from short-code behavior and is already called out by the prior review as dead Swift code. Delete it or route the new path through one canonical helper.
  Confidence: 0.86
• [P3] Update the Telegram pairing instructions — docs/channels/pairing.md:116-119
  This new pairing page says setup-code mobile bootstrap silently approves the fresh device and node, but docs/channels/telegram.md still says the setup code is node-only and requires /pair pending approval. Update the Telegram page too so the docs do not contradict each other.
  Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 66e676d29b92.

Label changes:

• add P2: This is a meaningful mobile onboarding feature with security-sensitive but bounded blast radius, not an outage or urgent regression.
• add merge-risk: 🚨 compatibility: The PR changes the default fresh setup-code flow from pending node approval to silent auto-approval and expands CLI QR JSON output.
• add merge-risk: 🚨 security-boundary: The diff adds unauthenticated redemption of token-bearing setup payloads and internal bootstrap-driven node approval.

Label justifications:

• P2: This is a meaningful mobile onboarding feature with security-sensitive but bounded blast radius, not an outage or urgent regression.
• merge-risk: 🚨 compatibility: The PR changes the default fresh setup-code flow from pending node approval to silent auto-approval and expands CLI QR JSON output.
• merge-risk: 🚨 security-boundary: The diff adds unauthenticated redemption of token-bearing setup payloads and internal bootstrap-driven node approval.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (recording): The PR body includes a redacted visual proof animation plus physical iPhone/Tailscale and simulator after-fix observations; that is sufficient real behavior proof, though it does not waive the uncovered default short-code scheme defect.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes a redacted visual proof animation plus physical iPhone/Tailscale and simulator after-fix observations; that is sufficient real behavior proof, though it does not waive the uncovered default short-code scheme defect.
• proof: 🎥 video: Contributor real behavior proof includes video or recording evidence. The PR body includes a redacted visual proof animation plus physical iPhone/Tailscale and simulator after-fix observations; that is sufficient real behavior proof, though it does not waive the uncovered default short-code scheme defect.

PR surface:

Source +463, Tests +274, Docs +48, Other +334. Total +1119 across 22 files.

Security concerns:

• [medium] Review pre-auth setup payload redemption — src/gateway/pairing-setup-short-code-http.ts:35
  The new redeem handler is intentionally unauthenticated and returns a setup payload containing bootstrap-token material, so the TTL, one-time-use, client-IP rate limit, and same-Gateway exposure boundary need maintainer acceptance before merge.
  Confidence: 0.9
• [medium] Review synthetic node approval scope — src/gateway/server/ws-connection/message-handler.ts:1799
  The auto-approval path approves a fresh pending node using internal pairing/write scopes after setup-code mobile device bootstrap, changing the previous explicit node-approval boundary even though the handed-off operator token remains bounded.
  Confidence: 0.86

Acceptance criteria:

• [P1] node scripts/run-vitest.mjs src/pairing/setup-short-code.test.ts src/gateway/server-http.probe.test.ts src/cli/qr-cli.test.ts.
• [P1] node scripts/run-vitest.mjs src/gateway/server.auth.control-ui.test.ts --testNamePattern "qr setup code".
• [P1] swift test --filter GatewaySetupShortCodeRedeemerTests from apps/shared/OpenClawKit.
• [P1] node scripts/format-docs.mjs --check docs/cli/qr.md docs/channels/pairing.md docs/gateway/protocol.md docs/channels/telegram.md.
• [P1] pnpm check-docs or the repository docs-map check after regenerating docs/docs_map.md.

What I checked:

• Repository policy read: Read the full root AGENTS.md and scoped docs/gateway guidance; the review applied the protected-label rule plus compatibility/security-boundary guidance for setup/auth changes. (AGENTS.md:1, 66e676d29b92)
• Live PR state: Live GitHub data shows the PR is open, non-draft, labeled maintainer, closes [Feature]: One-step mobile QR/setup-code pairing #98242, and is mergeable but unstable. (5db425956413)
• Current setup-code profile: Current main already defines QR/setup-code bootstrap as node plus bounded operator handoff, with no admin/pairing scopes in the bootstrap handoff profile. (src/shared/device-bootstrap-profile.ts:27, 66e676d29b92)
• Current main still leaves new nodes pending: Current main creates a pending node pairing with empty effective caps/commands when no paired node exists, so the central node auto-approval behavior is not already implemented on main. (src/gateway/node-connect-reconcile.ts:137, 66e676d29b92)
• PR node auto-approval path: The PR auto-approves a pending node after setup-code mobile device bootstrap approval by calling approveNodePairing with pairing/write scopes and replacing the pending reconciliation with declared surfaces. (src/gateway/server/ws-connection/message-handler.ts:1799, 5db425956413)
• PR pre-auth endpoint: The PR adds an unauthenticated setup short-code redeem handler that rate-limits by client IP and returns the redeemed setup payload, including bootstrap-token material. (src/gateway/pairing-setup-short-code-http.ts:35, 5db425956413)

Likely related people:

• ngutman: Merged prior QR bootstrap operator handoff and talk-secret bootstrap handoff work adjacent to this setup-code/mobile onboarding boundary. (role: bootstrap handoff feature-history contributor; confidence: high; commits: 94d8391c0323, c791e4242bc8; files: src/gateway/server/ws-connection/message-handler.ts, src/shared/device-bootstrap-profile.ts, docs/gateway/protocol.md)
• pgondhi987: Authored the merged setup-code device-pairing approval work that changed the same bootstrap approval model. (role: device pairing approval contributor; confidence: medium; commits: b17e77a22bf4; files: src/gateway/server/ws-connection/message-handler.ts, src/infra/device-pairing.ts)
• Solvely-Colin: Authored this PR and also has prior merged mobile setup-code/node approval work, so they are relevant beyond just opening this branch. (role: candidate fix author and prior mobile setup contributor; confidence: medium; commits: 8e77d5e1444f, 5db425956413; files: apps/ios/Sources/Onboarding/OnboardingWizardView.swift, apps/ios/Sources/Design/SettingsProTabActions.swift, src/gateway/server/ws-connection/message-handler.ts)
• steipete: Git log -S ties the centralized bootstrap profile handling to this author before the current shallow blame collapsed later lines to a grafted merge. (role: bootstrap profile refactor contributor; confidence: medium; commits: 6686f1cb2ce3; files: src/shared/device-bootstrap-profile.ts, src/pairing/setup-code.ts)
• RomneyDa: Current shallow blame points central setup-code and node-pairing lines to the recent merged PR 97937, though the grafted checkout makes this a weak ownership signal. (role: recent area contributor; confidence: low; commits: fd3f354f4626; files: src/shared/device-bootstrap-profile.ts, src/gateway/node-connect-reconcile.ts, apps/ios/Sources/Onboarding/OnboardingWizardView.swift)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• 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.