PR #60574: fix(hooks): remove hooks token from Tailscale Funnel push endpoint URL

• Repository: openclaw/openclaw
• Author: garagon
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60574

Description (problem / solution / changelog)

Summary

• Problem: ensureTailscaleEndpoint() in src/hooks/gmail-setup-utils.ts:315 appends the hooks token as ?token= to the Pub/Sub push endpoint URL
• Why it matters: the token leaks to Tailscale relay logs and Google Pub/Sub subscription metadata. Also, server-http.ts:502 explicitly rejects requests with ?token= in query params (returns 400), which breaks Gmail push delivery
• What changed: removed the token from the push endpoint URL. The gog serve process already receives the token via --token CLI arg and authenticates against the gateway via Authorization header
• What did NOT change (scope boundary): no changes to the hooks auth flow, gog serve behavior, or gateway token validation

The rest of the codebase already follows the correct pattern. dashboard.ts:75, onboard-helpers.ts:146, and setup.finalize.ts:314 all use URL fragments (#token=) to avoid server-side log exposure.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related #58639
• Related #59002
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: ensureTailscaleEndpoint() was written to include the token in the URL for Pub/Sub push delivery, but the gateway hooks handler was later hardened to reject ?token= in query params (server-http.ts:502-508). The two code paths became inconsistent.
• Missing detection / guardrail: no test validates that the push endpoint URL does not contain secrets in query parameters
• Prior context: the ?token= rejection was added in a security hardening pass. The Tailscale endpoint builder was not updated to match.
• Why this regressed now: the security hardening of server-http.ts created the inconsistency with the existing gmail-setup-utils code

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/hooks/gmail-setup-utils.test.ts
• Scenario the test should lock in: ensureTailscaleEndpoint with a token param should NOT include ?token= in the returned URL
• Why this is the smallest reliable guardrail: tests the exact function that constructs the URL
• If no new test is added, why not: the existing 3 tests in gmail-setup-utils.test.ts pass. A dedicated test for token-not-in-URL could be added by the maintainers if desired. The fix removes the code path entirely rather than changing its behavior.

User-visible / Behavior Changes

Gmail push notifications via Tailscale Funnel may start working for users who had hooks token configured. Previously, Google Pub/Sub would POST to a URL with ?token=, which the gateway rejects with 400.

Diagram (if applicable)

Before:
[Google Pub/Sub] -> POST https://gw.ts.net/hooks/gmail?token=SECRET -> [Tailscale] -> [gog serve] -> [gateway rejects: 400 "query parameters are not allowed"]

After:
[Google Pub/Sub] -> POST https://gw.ts.net/hooks/gmail -> [Tailscale] -> [gog serve --token SECRET] -> [gateway via Authorization header] -> OK

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? Yes
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: the hooks token is no longer placed in the push endpoint URL. This eliminates token exposure in Tailscale relay logs and Google Pub/Sub subscription metadata. The gog serve process already receives the token via --token CLI argument and authenticates via Authorization: Bearer header or X-OpenClaw-Token header. No change in authentication behavior.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 25.2.1
• Integration/channel: Gmail hooks via Tailscale Funnel

Steps

1. Configure Gmail hooks with Tailscale Funnel mode and a hooks token
2. Run openclaw hooks gmail setup
3. Check the Pub/Sub subscription: gcloud pubsub subscriptions describe <sub> --format="value(pushConfig.pushEndpoint)"

Expected

Push endpoint URL should NOT contain the hooks token

Actual

Before fix: https://gw.ts.net/hooks/gmail?token=SECRET After fix: https://gw.ts.net/hooks/gmail

Evidence

• Trace/log snippets

ensureTailscaleEndpoint() at gmail-setup-utils.ts:315:

// Before:
return params.token ? `${baseUrl}?token=${params.token}` : baseUrl;
// After:
return baseUrl;

Inconsistency with rest of codebase:

• dashboard.ts:75 uses #token= (correct)
• onboard-helpers.ts:146 uses #token= (correct)
• setup.finalize.ts:314 uses #token= (correct)
• server-http.ts:502 rejects ?token= with 400 (contradicts the old gmail-setup-utils code)

Human Verification (required)

• Verified scenarios: existing tests pass (gmail-setup-utils.test.ts, 3/3 green), diff is a single code path removal
• Edge cases checked: ensureTailscaleEndpoint called without token param still returns baseUrl (no change in behavior for that path)
• What I did NOT verify: end-to-end Gmail push delivery with live Tailscale Funnel (no Tailscale setup in my environment)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Users who had broken Gmail push notifications due to the ?token= rejection may need to re-run openclaw hooks gmail setup to update the Pub/Sub subscription endpoint.

Risks and Mitigations

• Risk: users who somehow relied on the ?token= in the Pub/Sub URL for custom middleware
  • Mitigation: this URL shape was rejected by the gateway anyway (400 error), so no working setup depends on it

AI-assisted: yes (analysis and PR preparation with Claude). Fix is a single line change, fully understood and manually verified. Tests run locally with vitest: 3/3 passing.

Changed files

• src/hooks/gmail-setup-utils.ts (modified, +5/-1)