[feature]: make `lncli connect --perm` survive restarts

[ZZiigguurraatt]

Currently lncli connect --perm creates a persistent connection with a peer until LND is shut down. The peer is not reconnected when LND starts back up.

Would appreciate being able to persist this in the DB somewhere and make peers re-connect across restarts of LND.

We do have

lnd/sample-lnd.conf

Lines 242 to 245 in 3e39a4d

	; Specify peer(s) to connect to first.
	; addpeer=

, but that is a config setting that requires a restart so we would have to do both, and we may not have access to change the config settings from the same client that does gRPC connections. Would like a CLI/gRPC call that just does it all.

We might also want lncli disconnect to have an option to temporarily disconnect a persistent peer or permanently.

[github-actions]

Found 3 possible duplicate issues:

1. Connections made with connect --perm are not permanent #3527
2. Add Bootstrapped Connections to Persistent Peers #451
3. Reliability: staying connected despite changing IP address / connection changes #5628

If this issue is a duplicate, please close it and 👍 the existing issue instead.

🤖 Generated with Claude Code

[ZZiigguurraatt]

Although I have tested lncli connect --perm does not persist the connection (even if there is a channel peer) after restarts of LND, claude code also provided the following information:

❯ does `lncli connect --perm` save addresses to the DB?                                                                                                                                                                                                                                                                       

● I'll trace what lncli connect --perm actually does to the database.

  Searched for 3 patterns, read 1 file, listed 1 directory (ctrl+o to expand)

● Now let me trace the server-side ConnectPeer RPC handler to see what it does with Perm and whether it touches the DB.

  Searched for 1 pattern, read 1 file (ctrl+o to expand)

● Now let me look at server.ConnectToPeer to see what perm=true does — specifically whether it persists anything.

  Searched for 1 pattern, read 1 file (ctrl+o to expand)

● The answer is clear. ConnectToPeer with perm=true writes only to in-memory maps (s.persistentPeers, s.persistentPeersBackoff, s.persistentConnReqs) — there is no DB write here. So the question becomes: does the address get persisted to the LinkNode "nib" bucket later, once the connection succeeds? Let me check
  OutboundPeerConnected / the peer-connected path and where AddAddress/AddPeer/CreateLinkNodes get called.

  Searched for 1 pattern (ctrl+o to expand)

● AddAddress / NewLinkNode / CreateLinkNodes don't appear in the connection path at all here. Let me confirm where LinkNode records actually get created/written — it's tied to channel funding, not peer connection.

  Searched for 1 pattern, read 1 file (ctrl+o to expand)

● The relevant LinkNode write is at channeldb/channel.go:2489. Let me confirm it's in the channel-creation path.

  Read 1 file (ctrl+o to expand)

● No. lncli connect --perm does not save addresses to the database.

  I traced the full path and --perm only affects in-memory server state.

  The path
  
  1. lncli connect --perm sets ConnectPeerRequest.Perm = true (cmd/commands/commands.go:963).
  2. The RPC handler rpcServer.ConnectPeer (rpcserver.go:1824) parses the pubkey@host and calls server.ConnectToPeer(peerAddr, in.Perm, timeout) — no DB access.
  3. server.ConnectToPeer with perm=true (server.go:5188-5209) writes only to in-memory maps:
    - s.persistentPeers[targetPub] = true
    - s.persistentPeersBackoff[targetPub]
    - s.persistentConnReqs[targetPub]

  then fires s.connMgr.Connect(connReq). There is no LinkNode write, no AddAddress, no CreateLinkNodes.

  What --perm actually means

  It is purely a runtime reconnect flag. Setting persistentPeers[pub] = true (vs. false for channel peers loaded at startup) tells the server to keep reconnecting to this peer even if it has zero open channels with us. That distinction lives only in memory and is lost on restart.

  Where addresses do get persisted

  The LinkNode "nib" bucket is written only in the channel lifecycle, not the connect path:
  - channeldb/channel.go:2489 (NewLinkNode → putLinkNode) — when a channel is created/synced. Note the early-out at line 2482: if a LinkNode already exists, it doesn't even update addresses.
  - channeldb/db.go:1662-1669 (CreateLinkNodes) — repair path.

  Practical consequence

  If you lncli connect --perm <pubkey>@<host> to a peer you have no channel with and then restart lnd, the address is gone — nothing reloads it, because establishPersistentConnections (server.go:3658) only reads from FetchAllLinkNodes (the "nib" bucket) and the graph, neither of which was written by the connect call.
  The --perm connection does not survive a restart unless a channel exists (which is what creates the persistent LinkNode record).

  So: --perm = "persistent reconnection attempts for this session," not "persist the address to disk."

✻ Churned for 59s

※ recap: You're exploring how lnd stores and uses peer IP addresses in its database. We've confirmed storage (LinkNode "nib" bucket), removal, source priority, and that connect --perm doesn't persist. Next: tell me what you'd like to dig into. (disable recaps in /config)