openclaw - ✅(Solved) Fix Feature: Allow LAN devices to auto-pair without manual approval [1 pull requests, 1 participants]

woaim65 · 2026-04-04T10:11:31Z

[openclaw] PR 61004: Feat- issue node pairing auto approve cidrs - Repository: openclaw/openclaw - Author: sahilsatralkar - State: open | merged: False - Link:… # PR #61004: Feat- issue node pairing auto approve cidrs - Repository: openclaw/openclaw - Author: sahilsatralkar - State: open | merged: False - Link: https://github.com/openclaw/openclaw/pull/61004 ## Description (problem / solution / changelog) ## Summary Describe the problem and fix in 2–5 bullets: If this PR fixes a plugin beta-release blocker, title it `fix( ): beta blocker - ` and link the matching `Beta blocker: - ` issue labeled `beta-blocker`. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation. - Problem: Gateway had no opt-in way to auto-approve first-time role: node device pairing from explicitly trusted CIDRs, so tightly controlled node deployments still required manual approval every time. - Why it matters: node onboarding on trusted networks was unnecessarily manual, but any automation here is security-sensitive and must not weaken operator/ browser pairing or upgrade approval boundaries. - What changed: added gateway.nodes.pairing.autoApproveCidrs, wired it into device pairing for first-time node pairing only, documented it, and added focused tests for allowed and rejected paths. - What did NOT change (scope boundary): operator/browser/Control UI pairing still stays manual; role, scope, and metadata upgrades still require approval; loopback trusted-proxy headers are not eligible for auto-approve; no blanket LAN auto-approve mode was added. ## Change Type (select all) - [x] Bug fix - [x] Feature - [ ] Refactor required for the fix - [x] Docs - [x] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [x] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [x] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #60800 - Related # - [x] This PR fixes a bug or regression ## Root Cause (if applicable) For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write `N/A`. If the cause is unclear, write `Unknown`. - Root cause: the new trusted-CIDR pairing path initially keyed only off requested role/scopes and reported client IP, without fully preserving existing browser/control-ui/manual-pairing boundaries and without accounting for spoofable loopback trusted-proxy header paths. - Missing detection / guardrail: there was no server-level regression test covering browser/control-ui node-role connects or loopback trusted-proxy header rejection on the trusted-CIDR path. - Contributing context (if known): pairing decisions already combined several silent-approval paths, so the new path needed to inherit the same trust boundaries instead of only checking CIDR membership. ## Regression Test Plan (if applicable) For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write `N/A`. - Coverage level that should have caught this: - [x] Unit test - [x] Seam / integration test - [ ] End-to-end test - [ ] Existing coverage already sufficient - Target test or file: - src/gateway/node-pairing-auto-approve.test.ts - src/gateway/server.node-pairing-auto-approve.test.ts - Scenario the test should lock in: - matching trusted CIDR is only eligible for first-time role: node pairing with empty scopes - browser/control-ui/webchat node-role connects stay manual - loopback trusted-proxy header paths do not silently auto-approve - role/scope upgrades still require approval - Why this is the smallest reliable guardrail: the helper test locks policy decisions directly, and the server test locks handshake wiring and pairing behavior without needing broader E2E infrastructure. - Existing test that already covers this (if any): existing pairing and allowlist tests still cover neighboring approval behavior. - If no new test is added, why not: N/A ## User-visible / Behavior Changes - New optional config: gateway.nodes.pairing.autoApproveCidrs - When configured, first-time node device pairing with no requested scopes can auto-approve if the effective client IP matches an explicit CIDR/IP allowlist - Operator/browser/Control UI pairing still remains manual - Role, scope, and metadata upgrades still remain manual - Docs now describe the new config and its security boundary ## Diagram (if applicable) Before: [node connect] -> [not paired] -> [manual pairing required] After: [node connect from allowed CIDR] -> [first-time node + no scopes + non-browser + non-loopback-proxy] -> [auto-approved] After (blocked cases): [node connect] -> [browser/control-ui OR loopback trusted-proxy OR upgrade OR non-match] -> [manual pairing required] ## Security Impact (required) - New permissions/capabilities? (Yes/No) Yes - Secrets/tokens handling changed? (Yes/No) No - New/changed network calls? (Yes/No) No - Command/

openclaw2026-04-04 10:11:31

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#60800•Fetched 2026-04-08 02:47:01

View on GitHub

Comments

Participants

Timeline

Reactions

Author

woaim65

Participants

woaim65

Timeline (top)

cross-referenced ×1

Code Example

{
  "gateway": {
    "nodes": {
      "pairing": {
        "lanAutoApprove": true,
        "lanSubnets": ["192.168.0.0/16", "10.0.0.0/8"]
      }
    }
  }
}

RAW_BUFFERClick to expand / collapse

Problem

Currently, when a device (Android/iOS app) connects to the Gateway via LAN IP (e.g. 192.168.x.x), it requires manual pairing approval via CLI or UI every time the app is reinstalled or the device reconnects. This is inconvenient for personal LAN setups where trust is already established at the network level.

Proposed Solution

Add a configuration option to allow all devices on the local network to auto-approve pairing without manual intervention.

{
  "gateway": {
    "nodes": {
      "pairing": {
        "lanAutoApprove": true,
        "lanSubnets": ["192.168.0.0/16", "10.0.0.0/8"]
      }
    }
  }
}

Use Case

For personal/home deployments where the Gateway is behind a router firewall and only accessible via LAN, requiring manual pairing approval on every fresh app install creates unnecessary friction for the owner.

Additional Context

Gateway bind: lan (0.0.0.0)
Use case: personal Android/iOS app reconnecting after reinstall
Current workaround: run openclaw devices approve each time, but this is inconvenient

extent analysis

TL;DR

Enable the lanAutoApprove configuration option to allow devices on the local network to auto-approve pairing without manual intervention.

Guidance

Review the proposed JSON configuration and apply it to the Gateway settings to enable lanAutoApprove.
Verify that the lanSubnets list includes the relevant local network subnets (e.g., 192.168.0.0/16, 10.0.0.0/8) to ensure auto-approval works as expected.
Test the auto-approval feature by reinstalling the app and checking if the device connects without requiring manual pairing approval.
Consider the security implications of enabling auto-approval and ensure that the Gateway is properly secured behind a router firewall.

Example

{
  "gateway": {
    "nodes": {
      "pairing": {
        "lanAutoApprove": true,
        "lanSubnets": ["192.168.0.0/16"]
      }
    }
  }
}

Notes

The effectiveness of this solution relies on the Gateway being properly configured and secured. Additionally, the lanSubnets list should be carefully curated to prevent unintended access.

Recommendation

Apply the workaround by enabling the lanAutoApprove configuration option, as it provides a convenient solution for personal LAN setups where trust is already established at the network level.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#API middleware #SSR setup #ISR setup #authentication setup #request error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix Feature: Allow LAN devices to auto-pair without manual approval [1 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Fix Action

Fix / Workaround

PR fix notes

PR #61004: Feat- issue node pairing auto approve cidrs

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Changed files