feat(ios): redeem gateway setup short codes#98265
Conversation
|
Codex review: found issues before merge. Reviewed June 30, 2026, 4:30 PM ET / 20:30 UTC. Summary PR surface: Other +334. Total +334 across 7 files. Reproducibility: not applicable. as a bug reproduction; this is a feature PR. Source inspection shows current main lacks short-code redemption, and the TLS-pin issue is source-reproducible from the new Review metrics: 2 noteworthy metrics.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Route redemption through the existing gateway trust/pinning model, then review and land it with the paired Gateway PR after maintainer security acceptance. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug reproduction; this is a feature PR. Source inspection shows current main lacks short-code redemption, and the TLS-pin issue is source-reproducible from the new Is this the best way to solve the issue? No. The client-side owner boundary is plausible, but the current implementation is not the best merge shape until redemption shares the gateway TLS trust path and lands with the paired server endpoint. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 640258d7b31d. Label changesLabel justifications:
Evidence reviewedPR surface: Other +334. Total +334 across 7 files. View PR surface stats
Security concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
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. How this review workflow works
|
There was a problem hiding this comment.
Pull request overview
Adds iOS support for redeeming Gateway-issued setup short codes by introducing an OpenClawKit redeemer and wiring iOS onboarding/settings entry points to try short-code redemption before falling back to existing setup-code parsing.
Changes:
- Add
GatewaySetupShortCodeRedeemer(OpenClawKit) to POST short codes to the Gateway and return a setup-code-equivalentGatewayConnectDeepLink. - Update iOS onboarding + settings flows to accept “setup or short code” input and redeem short codes when appropriate.
- Add unit tests for short-code normalization, redemption URL formation, and basic redemption/error mapping.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| apps/shared/OpenClawKit/Tests/OpenClawKitTests/GatewaySetupShortCodeRedeemerTests.swift | Adds unit coverage for short-code normalization and redemption behavior. |
| apps/shared/OpenClawKit/Sources/OpenClawKit/GatewaySetupShortCodeRedeemer.swift | Implements short-code normalization + redemption HTTP call and response parsing. |
| apps/shared/OpenClawKit/Sources/OpenClawKit/DeepLinks.swift | Adds a public fromGatewayURL(...) convenience wrapper for building GatewayConnectDeepLink. |
| apps/ios/SwiftSources.input.xcfilelist | Ensures the new OpenClawKit source is compiled into the iOS app target. |
| apps/ios/Sources/Onboarding/OnboardingWizardView.swift | Accepts short codes in onboarding and redeems them via the selected/manual Gateway. |
| apps/ios/Sources/Design/SettingsProTabSections.swift | Updates settings UI copy to reflect “setup or short code” input. |
| apps/ios/Sources/Design/SettingsProTabActions.swift | Adds short-code redemption path for settings-based setup input and connection. |
| guard (200..<300).contains(http.statusCode) else { | ||
| throw RedeemError.rejected(statusCode: http.statusCode) | ||
| } | ||
| let decoded = try JSONDecoder().decode(RedeemResponse.self, from: data) |
| func applySetupCodeAndConnect() async { | ||
| self.setupStatusText = nil | ||
| guard self.applySetupCode() else { return } | ||
| guard let link = await self.resolveSetupInputForConnect() else { return } | ||
| self.stagedGatewaySetupLink = nil | ||
| self.setupCode = "" | ||
| self.applyGatewayLink(link) |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a0646a67b3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| public let client: GatewaySetupShortCodeHTTPClient | ||
|
|
||
| public init(client: GatewaySetupShortCodeHTTPClient = URLSession.shared) { |
There was a problem hiding this comment.
Use gateway TLS pinning for redemption
When a short code is redeemed through a TLS gateway that relies on the app's existing TOFU/pinned-certificate flow rather than a publicly trusted certificate, this default URLSession.shared client performs normal system trust and the HTTPS POST fails before the user can use the already-supported trust prompt/pin path. The normal gateway connection path explicitly probes/stores a fingerprint and then uses GatewayTLSPinningSession from GatewayTLSStore, so short-code redemption should use the same pinned/trust-aware client for the selected gateway instead of bypassing it.
Useful? React with 👍 / 👎.
|
Closing this implementation after maintainer review. The short-code product direction remains valid in #98242, but this client split is not a safe landing shape:
The supported replacement is a current-main client/server change that routes redemption through the canonical Gateway trust owner, lands atomically with the server contract, and proves stored-pin success, pin-mismatch rejection, self-signed Gateway behavior, code TTL/single-use, and bootstrap-token scope. A replacement with that evidence would change this decision. Thanks @Solvely-Colin for the implementation and proof work. For future PRs, enabling Allow edits by maintainers lets us repair a strong contributor branch directly. |
Related: #98242
Pairs with gateway PR #98263.
Supersedes the iOS half of #98243.
What Problem This Solves
The iOS app could consume long setup codes/QR payloads, but it had no path for the shorter Gateway-issued setup code flow. That left the mobile side unable to complete the one-step onboarding shape where a user enters a short code and lands connected.
Why This Change Was Made
This adds a small OpenClawKit short-code redeemer, wires onboarding/settings entry points to try short-code redemption before falling back to existing setup-code parsing, and reuses the existing gateway link application/persistence paths once the gateway returns a setup-code-equivalent payload.
User Impact
On iOS, users can enter a Gateway setup short code from onboarding or settings, have the app redeem it into the Gateway URL/bootstrap auth payload, persist the connection settings, and connect through the same setup-code path used by QR.
Evidence
swift test --filter GatewaySetupShortCodeRedeemerTestspassed fromapps/shared/OpenClawKit: 4 tests passed.GatewaySettingsStore.swift,NodeAppModel.swift,TalkModeManager.swift,ChatViewModel.swift, andRealtimeTalkRelaySession.swift.git diff --checkpassed..agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main --prompt "Review the iOS split for one-step QR/setup-code mobile pairing..."clean: no accepted/actionable findings.