Best possible solution:

Land a rebased, maintainer-reviewed Android policy patch with security-doc alignment and live mobile pairing proof, then close the superseded draft PR if this one replaces it.

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

Yes. Source inspection on current main shows Android still rejects private-LAN cleartext setup/manual endpoints and persists bootstrap handoff tokens only for loopback or TLS; I did not run a live device repro in this read-only review.

Is this the best way to solve the issue?

Mostly yes, but not merge-ready. The code direction matches the remaining Android gap while preserving public and tailnet cleartext rejection, but the security-guide conflict and live mobile proof gap should be resolved before merge.

Full review comments:

• [P2] Update the security guide for this policy change — apps/android/app/src/main/java/ai/openclaw/app/ui/GatewayConfigResolver.kt:59-61
  This changes Android runtime and UI policy to allow private-LAN ws://, but docs/gateway/security/index.md still says mobile private-LAN, link-local, and .local cleartext routes must use TLS unless a break-glass env var is set. If this merges as-is, the public security guide will contradict the app behavior.
  Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.82

Security concerns:

• [low] Security guide contradicts private-LAN cleartext policy — docs/gateway/security/index.md:942
  The patch allows Android private-LAN and .local cleartext pairing/auth, while the gateway security guide still tells users those mobile routes must use TLS or an explicit trusted-private-network opt-in. That documentation drift is security-sensitive because it changes how users evaluate plaintext pairing risk.
  Confidence: 0.84

Acceptance criteria:

• pnpm check:changed
• swift test --package-path apps/shared/OpenClawKit --filter 'DeepLinksSecurityTests|GatewayNodeSessionTests'
• cd apps/android && ./gradlew :app:testPlayDebugUnitTest --tests ai.openclaw.app.gateway.GatewaySessionInvokeTest.bootstrapHandoffPersistenceTrustsPrivateLanCleartextEndpoints --tests ai.openclaw.app.ui.GatewayConfigResolverTest --tests ai.openclaw.app.node.ConnectionManagerTest
• Live Android and iOS private-LAN setup-code/manual pairing proof with private details redacted

What I checked:

• Protected PR state: Provided GitHub context shows this PR is draft, authored by a MEMBER, and has the protected maintainer label, so the cleanup workflow should not close it. (d2145d9b66d4)
• Current Android setup parser is loopback-only: Current main rejects non-TLS Android setup/manual URLs unless isLoopbackGatewayHost(host) is true, which excludes private LAN and .local endpoints this PR targets. (apps/android/app/src/main/java/ai/openclaw/app/ui/GatewayConfigResolver.kt:152, 7dc597b92176)
• Current Android TLS resolver forces TLS for private LAN: Current main computes cleartextAllowedHost with isLoopbackGatewayHost(endpoint.host), so manual/discovered private LAN endpoints still get required TLS parameters. (apps/android/app/src/main/java/ai/openclaw/app/node/ConnectionManager.kt:37, 7dc597b92176)
• Current Android bootstrap handoff persistence is narrower: Current main persists Android bootstrap handoff tokens only for bootstrap auth over loopback or TLS, not private LAN cleartext endpoints. (apps/android/app/src/main/java/ai/openclaw/app/gateway/GatewaySession.kt:527, 7dc597b92176)
• Android docs already describe private LAN cleartext support: The Android platform docs say cleartext ws:// remains supported on private LAN addresses and .local hosts while Tailscale/public mobile pairing should use wss:// or Tailscale Serve. Public docs: docs/platforms/android.md. (docs/platforms/android.md:36, 7dc597b92176)
• Security docs still conflict with the proposed policy: The gateway security guide still says mobile pairing and Android private-LAN, link-local, .local, and dotless routes must use TLS unless explicitly opted into trusted private-network cleartext. Public docs: docs/gateway/security/index.md. (docs/gateway/security/index.md:942, 7dc597b92176)

Likely related people:

• BunsDev: BunsDev is assigned to and closed the root LAN pairing issue, authored both the superseded draft and this recreated PR, and is credited in the current changelog for the related iOS/mobile pairing fix. (role: recent mainline policy maintainer and follow-up owner; confidence: medium; commits: 36df0d93b93a, d2145d9b66d4; files: CHANGELOG.md, apps/shared/OpenClawKit/Sources/OpenClawKit/LoopbackHost.swift, apps/ios/Sources/Gateway/GatewayConnectionController.swift)
• steipete: Local blame in the shallow checkout points the central Android gateway security, session, node connection, and config resolver files to Peter Steinberger's recent current-main commit, making him a likely maintainer reviewer for this Android path. (role: adjacent Android/gateway owner; confidence: medium; commits: 2b4b60b551; files: apps/android/app/src/main/java/ai/openclaw/app/gateway/GatewayHostSecurity.kt, apps/android/app/src/main/java/ai/openclaw/app/gateway/GatewaySession.kt, apps/android/app/src/main/java/ai/openclaw/app/node/ConnectionManager.kt)

Remaining risk / open question:

• The PR body lists unit/check verification but no live Android or iOS private-LAN pairing proof.
• The change broadens where Android accepts and persists auth after plaintext ws://, so the remaining docs conflict needs explicit maintainer/security sign-off.
• The superseded draft Fix private LAN mobile pairing auth policy #78140 is still open and should be cleaned up only after this PR is landed or abandoned.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 7dc597b92176.