OpenClaw Agent Hub bridge stuck on "OpenClaw is still connecting" after `dkg openclaw setup` (v10-rc)

[anabevc]

OpenClaw Agent Hub bridge stuck on "OpenClaw is still connecting" after dkg openclaw setup

Branch: v10-rc
Node version: 10.0.0-rc.1-dev.1777021554.93866af
OS: WSL2 (Ubuntu) on Windows, Node.js 25.8.2
OpenClaw version: 2026.3.31

---

Summary

After running dkg openclaw setup on a fresh V10 RC installation, the Agent Hub in the DKG Node UI (http://127.0.0.1:9200/ui) shows "OpenClaw is still connecting" and the agent chat remains inactive. The adapter plugin does not appear to establish the bridge connection to the OpenClaw gateway.

---

Steps to reproduce

1. Install DKG V10 RC CLI:

   npm install -g @origintrail-official/dkg --allow-prerelease

2. Initialise and start the node:

   dkg init
   dkg start

3. Run the OpenClaw adapter setup:

   dkg openclaw setup

4. The setup completes successfully with all ✓ checks:

   [setup] [verify] plugins.slots.memory === "adapter-openclaw" ✓
   [setup] [verify] plugins.slots.contextEngine !== "adapter-openclaw" ✓
   [setup] [verify] openclaw.plugin.json has "kind": "memory" ✓
   

5. Restart the OpenClaw gateway as instructed:

   openclaw gateway restart

6. Open the DKG Node UI at http://127.0.0.1:9200/ui → Agent Hub.

7. Expected: OpenClaw agent chat is active.
   Actual: "OpenClaw is still connecting" — chat remains inactive.

---

Root cause identified (manual investigation)

Two issues were found by inspecting the resulting ~/.openclaw/openclaw.json:

Issue 1: dkg openclaw setup writes new config, but gateway restart loads a stale backup

The setup script backs up the original config and writes a new one. However, after openclaw gateway restart, the running gateway appears to load the pre-existing config rather than the one written by setup. The plugins.slots, plugins.allow, and plugins.entries.adapter-openclaw keys written by setup were absent after restart.

Evidence: Running openclaw status after restart showed plugin memory-core (the default), not adapter-openclaw. Inspecting ~/.openclaw/openclaw.json confirmed the adapter-openclaw entries were missing.

Issue 2: Setup writes incorrect config key nodeUrl — plugin expects daemonUrl

The setup script populates plugins.entries.adapter-openclaw.config with nodeUrl for the DKG daemon endpoint. However, the adapter's openclaw.plugin.json configSchema defines the correct key as daemonUrl:

"daemonUrl": {
  "type": "string",
  "default": "http://127.0.0.1:9200",
  "description": "DKG daemon HTTP URL"
}

Because of this mismatch, the plugin silently uses the default value even when a custom URL is intended, and — more critically — the misconfigured entry causes the bridge not to establish.

Issue 3: Setup does not set channel.enabled: true in the adapter config

The plugin's configSchema includes:

"channel": {
  "type": "object",
  "properties": {
    "enabled": { "type": "boolean", "default": false },
    "port": { "type": "number", "default": 9201 }
  }
}

The channel.enabled flag defaults to false. The setup script does not set it to true, so the DKG UI ↔ OpenClaw bridge is never activated.

Issue 4: Setup does not set channels.dkg-ui in openclaw.json

The gateway needs a channels.dkg-ui entry to listen on port 9201. The setup adds this via the channels key in openclaw.json ("dkg-ui": { "enabled": true, "port": 9201 }), but this was also lost after the restart loaded the stale config (see Issue 1).

---

Working config (manual fix)

The following manual config in ~/.openclaw/openclaw.json produces a working Agent Hub connection:

"plugins": {
  "slots": { "memory": "adapter-openclaw" },
  "entries": {
    "adapter-openclaw": {
      "enabled": true,
      "config": {
        "daemonUrl": "http://127.0.0.1:9200",
        "memory": { "enabled": true },
        "channel": { "enabled": true, "port": 9201 }
      }
    }
  },
  "allow": ["discord", "anthropic", "duckduckgo", "adapter-openclaw"],
  "load": {
    "paths": [
      "/path/to/node_modules/@origintrail-official/dkg/node_modules/@origintrail-official/dkg-adapter-openclaw"
    ]
  }
},
"channels": {
  "dkg-ui": { "enabled": true, "port": 9201 }
}

Note: the adapter is bundled inside the main dkg package at node_modules/@origintrail-official/dkg/node_modules/@origintrail-official/dkg-adapter-openclaw — not as a standalone global package.

---

Expected behaviour

After dkg openclaw setup + openclaw gateway restart:

• ~/.openclaw/openclaw.json should contain all adapter keys correctly
• openclaw status should show plugin adapter-openclaw not memory-core
• The Agent Hub in the DKG Node UI should show an active OpenClaw chat

---

Suggested fixes

1. Fix config key mismatch: Replace nodeUrl with daemonUrl in the setup script's config population step.
2. Set channel.enabled: true in the adapter config written by setup.
3. Ensure channels.dkg-ui is written to openclaw.json by setup.
4. Investigate config persistence across gateway restart — the most impactful issue. The setup-written config should survive a openclaw gateway restart. Consider verifying config integrity post-restart in the setup [verify] step.

---

Environment

• WSL2 · Ubuntu · Node.js 25.8.2
• DKG V10 RC: 10.0.0-rc.1-dev.1777021554.93866af
• OpenClaw: 2026.3.31
• Adapter bundled at: @origintrail-official/dkg/node_modules/@origintrail-official/dkg-adapter-openclaw

[Jurij89]

Thanks for the repro and detailed analysis, @anabevc.

Cross-checked the four claims against v10-rc HEAD. Three are already correctly handled (evidence below). The fourth — the mute UI you hit after openclaw gateway restart — is more nuanced: the writer produces a correct config, but there's no post-restart proof-of-life, so any gateway-side issue surfaces as a silent "still connecting". We prototyped a fix (post-restart verifier + a new flag) but deferred it until we can pin the actual cause, because several plausible causes for your symptom wouldn't be helped by it. To root-cause before shipping code, could you share four artifacts from the failing run:

1. Full stdout of dkg openclaw setup (all log lines, not just the three ✓ invariants at the tail).
2. openclaw.json contents at two moments, plus the absolute path via readlink -f ~/.openclaw/openclaw.json:
   • Immediately after dkg openclaw setup returns (before any restart).
   • Immediately after openclaw gateway restart returns.
3. Verbatim openclaw status output (the full block you were reading, not just the plugin memory-core line — the plugin-list + runtime-state rows matter).
4. Environment details:
   • which dkg, which openclaw, which openclaw.cmd 2>/dev/null, file $(which openclaw).
   • echo "$HOME", echo "$OPENCLAW_HOME" from the WSL shell you ran setup in.
   • ls -la ~/.openclaw/, and ls -la /mnt/c/Users/$USER/.openclaw/ if that path exists (detects WSL2-vs-Windows homedir split).
   • Install method: npm install -g inside WSL, or npm.cmd install -g from the Windows side?

For the three claims that aren't v10-rc bugs, evidence in HEAD:

Claim	Finding
nodeUrl vs daemonUrl	daemonUrl is the canonical key; nodeUrl does not exist in the shipped code — packages/adapter-openclaw/src/setup.ts L1414-1418.
channel.enabled: true	Same block, setup.ts:1417.
channels.dkg-ui	Created / upgraded / refreshed at setup.ts:700-783 with idempotent ownership tracking (added by PR #250 / fea4a1b1).

Repo-wide rg nodeUrl across the v10-rc worktree returns 0 matches.

Your build is 10.0.0-rc.1-dev.1777021554.93866af. Confirmed via git merge-base --is-ancestor that 93866af already contains all three writers (fc0a8a88, 8eebae34, fea4a1b1 are all ancestors). Your working-config snippet matches what HEAD produces byte-for-byte, which suggests the failing run was against an earlier build or a load-path mismatch (hence ask #4) — the bits you expected are in your build, so the post-restart state you observed came from somewhere other than the setup writer.

One nuance on openclaw status showing plugin memory-core: that alone isn't proof of slot-election failure — see DkgMemoryPlugin.ts:572, DkgNodePlugin.ts:352, DkgChannelPlugin.ts:786 — our adapter code explicitly tolerates memory-core loading concurrently.

Once we have the artifacts we'll ship a tightly-scoped fix if code is actually called for, or close the loop with a docs clarification, depending on what they show.

[anabevc]

Diagnostic artifacts

1. Full dkg openclaw setup stdout

DKG OpenClaw Adapter Setup
========================================

[setup] OpenClaw workspace: /home/purple/.openclaw/workspace
[setup] Agent name: ** AgentPurple
[setup] Merging into existing /home/purple/.dkg/config.json
[setup] Wrote /home/purple/.dkg/config.json (DKG V10 Testnet, edge, port 9200)
[setup] DKG daemon already running (PID 28355, port 9200)
[setup] Installed canonical node skill from .../dkg/skills/dkg-node/SKILL.md
[setup] adapter-openclaw already in plugins.allow
[setup] Removed 1 stale adapter-openclaw load path(s)
[setup] Added adapter path to plugins.load.paths
[setup] adapter-openclaw already in plugins.entries
[setup] Set plugins.entries.adapter-openclaw.config.installedWorkspace = ...
[setup] plugins.slots.memory already = "adapter-openclaw"
[setup] Updated /home/purple/.openclaw/openclaw.json (backed up original)
[setup] Reload the OpenClaw gateway if it does not auto-restart after the config update
[setup] Verifying setup...
[setup] Daemon reachable (peer ID: 12D3KooWEnJqrC9Ybxme1dF5rmg9um2qCuCeBr1iabtJeZmriseQ)
[setup] 3 wallet(s) found
[setup] [verify] plugins.slots.memory === "adapter-openclaw" ✓
[setup] [verify] plugins.slots.contextEngine !== "adapter-openclaw" ✓
[setup] [verify] openclaw.plugin.json has "kind": "memory" ✓
[setup] Node UI: http://127.0.0.1:9200/ui
[setup] Done.

2a. openclaw.json immediately after setup (before restart)

The config written by setup is correct — all expected keys present:

• plugins.slots.memory = "adapter-openclaw"
• plugins.entries.adapter-openclaw.config.daemonUrl = "http://127.0.0.1:9200"
• plugins.entries.adapter-openclaw.config.channel.enabled = true
• channels.dkg-ui = { enabled: true, port: 9201 }

(Full JSON available — too long to inline.)

2b. Gateway restart clobbering — confirmed

The ~/.openclaw/ directory contains multiple openclaw.json.clobbered.TIMESTAMP files (e.g. openclaw.json.clobbered.2026-04-24T09-35-55-322Z, .T09-38-58, .T09-41-48, .T12-37-55). These are the configs that setup wrote correctly, which the gateway overwrote on restart.

readlink -f ~/.openclaw/openclaw.json → /home/purple/.openclaw/openclaw.json (no symlink involved).

3. Verbatim openclaw status output (plugin-relevant lines)

[plugins] [dkg-entry] config - daemonUrl: http://127.0.0.1:9200, memory.enabled: true, channel.enabled: true, registrationMode: full
[plugins] [dkg] Cross-channel persistence registered
[plugins] [dkg-channel] runtime.channel available — dispatch routing enabled
[plugins] [dkg-channel] Registered as OpenClaw channel via registerChannel()
[plugins] [dkg-channel] Registered HTTP routes on gateway: POST /api/dkg-channel/inbound, GET /api/dkg-channel/health
[plugins] [dkg] Channel module enabled — DKG UI bridge active
[plugins] [dkg-memory] registerMemoryCapability called (registrationMode=full)
[plugins] [dkg] Memory module enabled — DKG-backed memory slot active
[plugins] [dkg-channel] Bridge server failed to start: listen EADDRINUSE: address already in use 127.0.0.1:9201
[plugins] [dkg] OpenClaw channel startup did not reach ready state: listen EADDRINUSE: address already in use 127.0.0.1:9201

Memory row: enabled (plugin adapter-openclaw) · unavailable

A dkg-ui:direct:owner session IS present in the sessions list — the DKG UI reached the gateway.

3a. Root cause of EADDRINUSE

Port 9201 is held by the gateway process itself (pid 15107):

ss -tlnp | grep 9201
LISTEN 0  511  127.0.0.1:9201  0.0.0.0:*  users:(("openclaw-gatewa",pid=15107,fd=22))

Setup writes channels.dkg-ui = { enabled: true, port: 9201 } to openclaw.json, which causes the gateway to bind 9201. When the adapter's bridge server then also tries to bind 9201, it gets EADDRINUSE.

The adapter's registerChannel() succeeded (gateway route registered), but the subsequent standalone-server fallback path fires anyway and hits the conflict. The "OpenClaw is still connecting" state in the DKG UI is caused by this startup failure, even though route registration completed.

4. Environment details

which dkg      → /home/purple/.npm-global/bin/dkg
which openclaw → /home/purple/.npm-global/bin/openclaw
file /home/purple/.npm-global/bin/openclaw → symbolic link to ../lib/node_modules/openclaw/openclaw.mjs
HOME=/home/purple
OPENCLAW_HOME=unset

/mnt/c/Users/purple/.openclaw/ does not exist — no Windows-side homedir split.

Install method: npm install -g inside WSL (not npm.cmd from Windows side).

Hypothesis

The gateway binding 9201 via channels.dkg-ui conflicts with the adapter's standalone bridge server. Removing channels.dkg-ui from openclaw.json eliminates the port conflict; the adapter's registerChannel() path is sufficient for the DKG UI connection.

Possible fix: the adapter's bridge startup path should check whether gateway route registration already succeeded and skip the standalone server attempt in that case. Alternatively, dkg openclaw setup should not write channels.dkg-ui when the adapter will register its own channel.

[Jurij89]

Thanks @anabevc — your ss -tlnp output pinned the actual root cause (port 9201 double-bind between the gateway's channels.dkg-ui binding and the adapter's standalone bridge server). Opened #294 with the fix: gate DkgChannelPlugin.start() on !useGatewayRoute so the adapter skips its standalone bridge when the gateway has already taken ownership of the channel routes via registerHttpRoute(). The same gate is applied at the secondary call site in DkgNodePlugin.

Note on the earlier comment: "came from somewhere other than the setup writer" was technically correct but misleading — the setup writer IS correct, and the bug lives in the adapter's startup sequence, which the setup-written config then triggers. Your diagnostic cleared that up.

Will close this issue when the PR merges.

[Jurij89]

Quick update on PR #294, @anabevc — the fix shape pivoted after we found the original approach didn't actually solve the symptom on your environment.

The first attempt gated the standalone bridge so it skipped start() when the gateway had registered the channel routes. That silenced the EADDRINUSE log, but the gateway's /api/dkg-channel/health route is auth: 'gateway' and rejects the daemon's unauthenticated probe — so skipping the bridge left the daemon with no reachable health target and the UI would still have shown "OpenClaw is unavailable" on your 2026.3.31 install.

The current fix (commit ff18e680) keeps the bridge alive: DkgChannelPlugin.start() falls back to an OS-allocated free port when the configured port is already taken (which is what's happening on your env — gateway holds 9201). The bound port surfaces via transport.bridgeUrl, the daemon's probe finds it, and the UI reaches ready.

When the PR merges, would you mind retesting on your 2026.3.31 install? If ~/.openclaw/openclaw.json.clobbered.<TIMESTAMP> files stop accumulating and the UI shows OpenClaw available, the fix is doing what we intend.