Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Environment OpenClaw 2026.4.10 gogcli 0.12.0 macOS (Mac Mini)

What works Gmail webhook setup succeeds. Watcher initializes correctly. Logs show:

• gmail watcher started
• hooks gmail watcher started

Issue The Gmail watcher starts successfully on port 8788, but OpenClaw later attempts to start it again, causing a duplicate bind error.

Observed behavior First watcher process runs correctly and listens on 127.0.0.1:8788.

Later, OpenClaw attempts to start another watcher: listen tcp 127.0.0.1:8788: bind: address already in use

Important detail This occurs even after:

• stopping gateway
• killing all gog processes
• restarting clean

Expected behavior Only one watcher should run per account.

Actual behavior OpenClaw repeatedly attempts to start a second watcher despite an active one already running.

Evidence Active process: gog gmail watch serve --account [email protected] --bind 127.0.0.1 --port 8788 ...

Logs show repeated: [gmail-watcher] starting gog gmail watch serve ...

Direct gog test Running on a different port (8799) works fine, suggesting the issue is in OpenClaw watcher lifecycle management.

Question Is this a known issue with gmail-watcher restart logic or gateway lifecycle? Any recommended workaround?

Steps to reproduce

1. Configure Gmail webhooks for a Gmail account using openclaw webhooks gmail setup. 2. Start OpenClaw 2026.4.10 with the Gmail watcher enabled via the gateway. 3. Confirm the first watcher starts successfully: • gateway log shows watch started for <account> • gateway log shows gmail watcher started • lsof -nP -iTCP:8788 -sTCP:LISTEN shows one gog gmail watch serve process listening on 127.0.0.1:8788 4. Leave the gateway running for a few minutes without manually starting another watcher. 5. Observe repeated later log entries: • [gmail-watcher] starting gog gmail watch serve --account <account> --bind 127.0.0.1 --port 8788 ... while the original watcher is still alive and already listening on port 8788. 6. Confirm the duplicate-start symptom by checking that the original watcher PID is still present and holding 127.0.0.1:8788.

Expected behavior

In 2026.2.10, the Gmail watcher initialized a single gog gmail watch serve process per account and maintained a stable listener on the configured port without spawning duplicates.

Under the same configuration and workflow, OpenClaw should: • Start only one Gmail watcher per account • Avoid re-spawning additional watchers if one is already active • Prevent port conflicts on 127.0.0.1:8788 • Maintain a stable, continuous watch process without repeated restart attempts

No additional starting gog gmail watch serve events should occur unless the existing watcher has stopped or failed.

Actual behavior

No reply is posted in the Gmail thread. The gateway log shows repeated attempts to process the event, but fails with “reply target not found,” and no message is created despite the watcher running and receiving events.

OpenClaw version

2026.4.10 (44e5b62)

Operating system

macOS (Apple Silicon, Mac mini, zsh)

Install method

Homebrew (gogcli) + local OpenClaw CLI (launchd gateway)

Model

openai/gpt-5.1-codex

Provider / routing chain

openclaw -> local gateway -> gogcli (gmail watch) -> Google Pub/Sub

Additional provider/model setup details

Local OpenClaw gateway with Gmail watcher enabled via gogcli (Homebrew). Gmail integration uses Google Pub/Sub push to a local webhook endpoint (127.0.0.1:18789/hooks/gmail) with Tailscale funnel on port 8788.

Watcher is auto-managed by the gateway and repeatedly attempts to start gog gmail watch serve on the same port.

Relevant config located at ~/.openclaw/openclaw.json.

Logs, screenshots, and evidence

Impact and severity

Affected: Gmail watcher / email automation via OpenClaw Severity: High (blocks outbound email replies entirely) Frequency: Consistent (reproduces on every attempt) Consequence: Agent receives events but fails to send replies, resulting in missed communications and broken automation workflows

Additional information

Affected: Gmail watcher / email automation via OpenClaw Severity: High (blocks outbound email replies and causes unstable watcher behavior) Frequency: Consistent (reproduces on every attempt)

Consequence: • Agent receives Gmail events but fails to send replies (“reply target not found”) • Gmail watcher repeatedly attempts to restart on the same port (8788), causing port conflicts • Results in broken email automation and unreliable watcher lifecycle overall

This makes it clear the issue isn’t isolated—it’s both messaging + watcher management failing together.