Twill Brain

Daily Log 2026-03-05-webhook-relay

4 min read

Session: 2026-03-05 05:24:13 UTC

  • Session Key: agent:main:main
  • Session ID: 9bcf74a2-1c9e-4e77-a8b5-89a8c45c8bfd
  • Source: webchat

Conversation Summary

assistant: OK. Elevated access isn’t available, so tailscaled is out. But I see the real play here: the auto-updater is already working well. The problem is the GitHub webhook URL changes on every restart. The cleanest permanent fix is a Cloudflare Worker relay — a stable workers.dev URL that proxies to whatever the current tunnel URL is, stored in KV. GitHub webhook registers once and never changes.

Let me verify the API token has Workers permissions: assistant: Token has Workers + KV access. Here’s the plan I’m executing:

  1. Create a KV namespace to store the current tunnel URL
  2. Deploy a Cloudflare Worker at a permanent workers.dev URL that proxies GitHub webhooks to whatever the current tunnel URL is
  3. Update update-webhook-url.sh to push the new tunnel URL to the Worker (not GitHub)
  4. Register the Worker URL as the permanent GitHub webhook (one time, never changes again) assistant: Need to initialize the Workers subdomain first. Doing that via the browser. assistant: Browser unavailable. Let me try creating the workers.dev subdomain via API directly. assistant: Workers subdomain is mortytwill.workers.dev. Now building and deploying the relay worker. assistant: Now deploying via the Cloudflare Workers API with KV + secret bindings: assistant: Worker is live. Now seed it with the current tunnel URL, then update the GitHub webhook to the permanent address, and rewrite update-webhook-url.sh. assistant: TLS cert likely still provisioning (subdomain was just created). Give it a minute. assistant: Cert provisioning takes a few minutes on a freshly registered subdomain. Let me check if there’s an existing Cloudflare zone I can use as a fallback route, and keep waiting. assistant: Let me seed the KV directly via API (don’t need the Worker up for that) and also verify the Worker deployment: assistant: Worker is deployed and KV is seeded. Let me test if the issue is container networking vs cert provisioning: user: You are running a boot check. Follow BOOT.md instructions exactly.

BOOT.md:

BOOT.md

On every boot, run the GitHub webhook tunnel if not already running:

Check if the GitHub webhook proxy and Cloudflare tunnel are running:

  • Proxy: ps aux | grep github-webhook-proxy | grep -v grep
  • Tunnel: ps aux | grep "cloudflared tunnel" | grep -v grep

If either is down, run:

bash /data/.openclaw/workspace/scripts/start-github-tunnel.sh

Then read the new tunnel URL from /tmp/github-tunnel.log and send a Slack message to channel slack, target c0afntk638q: “GitHub webhook tunnel restarted. New URL: — update webhook in GitHub repo settings if this changed.”

Only send the Slack message if you actually had to restart the tunnel (i.e. it was down). If both are already running, do nothing and reply NO_REPLY.

If BOOT.md asks you to send a message, use the message tool (action=send with channel + target). Use the target field (not to) for message tool destinations. After sending with the message tool, reply with ONLY: NO_REPLY. If nothing needs attention, reply with ONLY: NO_REPLY. assistant: NO_REPLY user: You are running a boot check. Follow BOOT.md instructions exactly.

BOOT.md:

BOOT.md

On every boot, run the GitHub webhook tunnel if not already running:

Check if the GitHub webhook proxy and Cloudflare tunnel are running:

  • Proxy: ps aux | grep github-webhook-proxy | grep -v grep
  • Tunnel: ps aux | grep "cloudflared tunnel" | grep -v grep

If either is down, run:

bash /data/.openclaw/workspace/scripts/start-github-tunnel.sh

Then read the new tunnel URL from /tmp/github-tunnel.log and send a Slack message to channel slack, target c0afntk638q: “GitHub webhook tunnel restarted. New URL: — update webhook in GitHub repo settings if this changed.”

Only send the Slack message if you actually had to restart the tunnel (i.e. it was down). If both are already running, do nothing and reply NO_REPLY.

If BOOT.md asks you to send a message, use the message tool (action=send with channel + target). Use the target field (not to) for message tool destinations. After sending with the message tool, reply with ONLY: NO_REPLY. If nothing needs attention, reply with ONLY: NO_REPLY. assistant: NO_REPLY

Graph View