Summary

The nextcloud-talk plugin's start() method resolves its promise without retaining a reference to the HTTP server. The plugin subsystem interprets this as "plugin exited" and immediately schedules a restart. The restarted instance finds the port still bound, producing EADDRINUSE, which crashes the gateway in a tight loop and takes down all other channels.

Steps to reproduce

1. Configure the nextcloud-talk plugin in openclaw.json with a valid webhookPort (e.g. 8788), botSecret/botSecretFile, and webhookPublicUrl.
2. Ensure the port is not already in use.
3. Start (or restart) the OpenClaw gateway.
4. Watch the gateway log immediately after startup.

Expected behavior

The nextcloud-talk plugin starts, binds the webhook HTTP server on the configured port, and stays running. The plugin subsystem registers it as active and does not schedule a restart.

Actual behavior

• Plugin logs webhook listening on <webhookPublicUrl>
• ~11ms later: [plugin/nextcloud-talk] auto-restart attempt 1/10 in 5s
• After 5s delay: new instance attempts to bind the same port
• Error: listen EADDRINUSE :::<port> — gateway exits with code=1
• systemd/process manager restarts the gateway → loop repeats indefinitely
• All other channels (e.g. WhatsApp) are taken down with the gateway

OpenClaw version

2026.2.23

Operating system

Linux (Debian-based, systemd user service)

Install method

npm global

Logs, screenshots, and evidence

[nc-talk] webhook listening on https://<host>/nextcloud-talk-webhook
[plugin/nextcloud-talk] auto-restart attempt 1/10 in 5s
Error: listen EADDRINUSE :::8788
    at Server.setupListenHandle [as _listen2] ...
[gateway] exit code=1

Cycle repeats on every gateway start with the plugin enabled.

Impact and severity

• Affected: Any user who configures the nextcloud-talk plugin with webhookPort
• Severity: Critical — crashes the gateway immediately, taking down ALL channels
• Frequency: 100% reproducible on every gateway start with the plugin enabled
• Consequence: Plugin is completely unusable in its bundled form; only workaround is "enabled": false

Additional information

Root cause hypothesis: start() creates an HTTP server but resolves the returned promise before (or without waiting for) the server's listening event. The plugin subsystem sees a resolved start() as "plugin has exited" and schedules the auto-restart immediately. The original server is still holding the port when the restart fires.

Workaround: Set "enabled": false in the nextcloud-talk plugin config and run a standalone webhook receiver as a separate process/service that forwards inbound Nextcloud Talk messages to OpenClaw via the /v1/chat/completions HTTP endpoint.

Also observed: The ON badge on the Chrome Browser Relay extension does not clear when the attached tab navigates to a new page (full navigation), giving a false impression that the tab is still attached. May be worth a separate issue.