Tailscale MCP rejected in owner-created webhook routine, but works in direct chat (0.78.1)

Đang mở
  • Có gì không ổn?
#1,142 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Lĩnh vực
networking

Hướng nghiên cứu

Start with the Tailscale plugin README and setup skill, then compare their wording about owner-scheduled routines with the routine documentation on webhook triggers. Trace how execution origin is checked for webhook routines and how that affects private MCP tool loading and calls. Done means establishing whether webhook routines are supported and, if so, resolving the rejection; if not, documenting the distinction and an actionable explanation.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

On Grok Bot 0.78.1 stable, a custom private MCP connector works from the owner's direct chat, but the same connector is rejected when used by an owner-created webhook routine.

The webhook returns HTTP 200 and the routine starts. The failure occurs afterward, when the routine tries to load or call the private MCP tools. Please clarify whether owner-created webhook routines are supported for Tailscale MCP access, and investigate the execution-origin check if they are.

Environment

  • Grok Bot: 0.78.1, stable; macOS / darwin
  • Build: 2026-10-28T02:34:00.517Z
  • Reproduced: 2026-10-30
  • Official Tailscale plugin connected to a personal tailnet
  • Custom remote HTTP/Streamable HTTP MCP at a private HTTPS <server>.<tailnet>.ts.net/mcp address
  • Connector authentication: static Bearer header, already configured and working in direct chat
  • Tailscale Funnel disabled; the MCP server is not publicly exposed

Steps to reproduce

  1. Connect the official Tailscale plugin and register a private MCP connector with valid authentication.
  2. From the owner's direct Grok Bot chat, verify tools/list, ping, and an ordinary mailbox operation. These succeed in our setup.
  3. In that same owner's Bot, create a webhook routine that uses the existing connector to reserve one test request, read it, and save one echo result. Do not change the connector URL or credentials.
  4. POST a small JSON notification containing only test identifiers to the routine's generated webhook URL, authenticated with its sender key.
  5. Observe HTTP 200 and the routine starting, then inspect its MCP access result.

Three controlled deliveries reproduced the failure. The first two used the Authorization header. A further comparison also included X-Automation-Key with the same sender key, as shown in the repository's make-bot-ui example. It still failed. Values and identifiers are omitted here.

Actual behavior

Depending on the run:

  • The connector is reported as error / zero tools while loading the routine's tools; or
  • Tools are visible, but calling the server-side reservation tool fails.

The routine reported this error:

Tool execution error. Tailnet servers work only in your own conversations with Grok Bot.
Someone else, an agent, or an automation started this request.
To use this server, send the request yourself in a Grok Bot chat or a Slack direct message to Grok Bot.

The tools-loading failure also appeared with the prefix failed_to_load: and the same explanatory text.

Our server's reservation/audit, result, and read-receipt records confirm no successful processing of the test requests. This is not a claim that all network traffic was captured. Webhook acceptance and routine wakeup succeeded; task completion did not.

Expected behavior / documentation question

The Tailscale plugin README and setup skill describe access for "routines the owner schedules". The routine documentation includes webhook triggers.

Does this permission include webhook routines created by the owner, or only time-scheduled routines? The time-scheduled case was not tested.

If webhook routines are supported, the observed origin rejection appears inconsistent with that support. If intentionally excluded, please document the distinction and provide an actionable explanation.

Impact and scope

This blocks a private mailbox workflow: another agent posts a request, the server wakes Grok Bot by webhook, and Grok Bot must fetch the request and write its result over the existing private connector.

Including the task body directly in the webhook could avoid fetching its text, but would still leave server-side reservation and result delivery unresolved; this has not been implemented as a workaround.

This report does not establish a root cause or request bypassing origin restrictions. Test runs were cancelled, and webhook sending is paused. Authentication and network exposure were not relaxed.

Separate from #1108: that issue concerns OAuth sign-in before tools become available. Here a static-Bearer connector already works from direct chat; the failure depends on the execution being webhook-triggered.

Real hostnames, tailnet/device/account identifiers, internal message/task/run IDs, credentials, webhook/callback URLs, conversation links, raw logs, and screenshots are intentionally excluded.

Ngôn ngữ chính
TypeScript
Star
14.9k
Fork
1.5k
Merge trung bình
3 giờ 18 phút
Pull request đã merge (30 ngày)
144

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của cursor/plugins

Tất cả issue của cursor/plugins

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.