openclaw - 💡(How to fix) Fix Node host on macOS connects but never announces caps/commands (file-transfer plugin)

Summary

A freshly paired macOS node (node-host/node) connects successfully to a remote gateway over Tailscale, but the gateway never sees any caps or commands from the node — even though the file-transfer plugin is enabled in the node's local config. As a result, file.fetch, dir.list, dir.fetch, and file.write are all unusable end-to-end.

The same plugin is registered and enabled on the gateway side, and gateway.nodes.allowCommands plus plugins.entries.file-transfer.config.nodes.<node>.allowReadPaths are configured. Calling any file-transfer tool returns:

node command not allowed: the node did not declare any supported commands

Environment

• Gateway host: macOS 26.5 (arm64), OpenClaw 2026.5.22 → 2026.5.26 (Mac mini, Tailscale Serve)
• Node host: macOS 26.3.1 (arm64), OpenClaw 2026.5.26 (MacBook Pro M-series)
• Transport: Tailscale Funnel wss://<gateway>.ts.net → 127.0.0.1:18789
• Node service: LaunchAgent, openclaw node run --host <gateway>.ts.net --port 443 --tls
• Node version reported in describe: ui v2026.5.26 (note: device family is Mac, clientId is node-host, clientMode is node)

Reproduction

1. Fresh pair a macOS machine as a node (openclaw node install --host <gateway> --port 443 --tls).
2. Approve the new pairing request on the gateway (openclaw devices approve <requestId>).
3. Approve the subsequent role-upgrade request that the node-host raises (openclaw devices approve <requestId> again).
4. On the node, ensure the file-transfer plugin is enabled:

   openclaw plugins enable file-transfer
   openclaw config set plugins.allow '["file-transfer","anthropic","telegram","whatsapp","memory-core","google"]'
   openclaw node restart

5. On the gateway, confirm:

   openclaw nodes describe --node "<node display name>"

Expected

Caps lists at least file, Commands includes file.fetch, dir.list, dir.fetch, file.write.

Actual

Caps     │
Commands │ - (none reported)

nodes invoke confirms the gateway thinks the node hasn't declared anything:

node command not allowed: the node did not declare any supported commands

What was already verified

• plugins list on the node confirms file-transfer as enabled, stock stock:file-transfer/index.js, version 2026.5.26.
• The local config has both plugins.allow and plugins.entries.file-transfer.enabled = true.
• Node identity is correctly written (identity/device.json, device-auth.json) with both operator and node tokens.
• The gateway-side file-transfer plugin entry has the node's display name configured under plugins.entries.file-transfer.config.nodes.<name>.allowReadPaths.
• The gateway's gateway.nodes.allowCommands is open for the relevant commands.
• Re-pairing from scratch (deleting ~/.openclaw/identity + node.json, fresh openclaw qr setup code, approving both the initial pairing and the role upgrade) produces the same end state.

Additional weirdness

• Running openclaw node run --host <gateway> --port 443 --tls interactively prints only the OpenClaw banner and then sits silent indefinitely — no plugin-loading output, no connection log, no errors. ~/Library/Logs/openclaw/node.log contains only the config-warning banner from CLI invocations, not anything from the long-running daemon.
• Despite plugins.allow containing anthropic, telegram, whatsapp etc., every CLI invocation prints:

  plugins.entries.anthropic: plugin disabled (not in allowlist) but config is present
  plugins.entries.telegram: plugin disabled (not in allowlist) but config is present
  plugins.entries.whatsapp: plugin disabled (not in allowlist) but config is present

  even after writing plugins.allow with openclaw config set. Suggests plugins.allow is being normalized/ignored somewhere in the node-host code path even though resolveEffectivePluginIds in dist/effective-plugin-ids-*.js reads it correctly.

Hypothesis

ensurePluginRegistryLoaded({ scope: 'all' }) in dist/node-cli-Cheoxwxv.js (the node-host plugin loader) may be picking up a different config than the gateway/CLI path — possibly the bundled/default plugin set only, ignoring user-defined plugins.allow. That would explain why nodeHostCommands from file-transfer is never registered on the node side even though the plugin is on disk and marked enabled.

Impact

Without working file-transfer commands, paired macOS nodes can't be used for any of the typical agent flows (fetching screenshots, reading files in user directories, writing artifacts back). This breaks the documented Mac node use case end-to-end on 2026.5.26.

Asks

• Confirm whether plugins.allow is supposed to be honoured by openclaw node run, or whether the node-host has its own activation list.
• Provide a way to log nodeHostCommands registration when the daemon starts (env var? --log-level debug?) so users can self-diagnose.
• Fix openclaw node run so it logs to ~/Library/Logs/openclaw/node.log (currently empty for foreground daemons; only CLI banner output ends up there).