Slack message hyperlinks stripped before reaching assistant context

[sentry-junior]

Summary

When a user sends a message containing hyperlinked display text (Slack's <url|display text> wire format), the URLs are stripped before the message reaches the assistant. The assistant receives only the display text with no knowledge of the embedded URLs, causing it to miss linked resources entirely — such as PR or thread links referenced in the message.

Root cause

The message ingestion pipeline appears to deliver only the text field (or a sanitized version of it) to the assistant context. Slack encodes rich-text hyperlinks as <https://example.com|display text> in the raw payload, but the assistant's thread transcript shows plain display text with no URL — confirming the URLs are dropped somewhere between Slack's API response and the context the model receives.

Two likely culprits:

• The message pre-processor strips Slack mrkdwn link syntax and keeps only the label.
• The assistant is given a rendered/human-readable string instead of the raw text field (or the blocks array, which also encodes rich-text links).

Reproduction

1. Send a message to the assistant that includes a hyperlinked word or phrase (e.g. <https://github.com/foo/bar/pull/1|this PR>).
2. Observe the assistant's reply — it will have no awareness of the linked URL.
3. Compare against a message where the raw URL is pasted inline (not hyperlinked); the assistant sees it correctly.

Expected behavior

The assistant should receive either the raw Slack mrkdwn text field (with <url|label> syntax intact) or a normalized form that preserves the URL. Hyperlinked text and inline-pasted URLs should behave identically from the assistant's perspective.

Workaround

Users can paste URLs inline (un-hyperlinked) to ensure the assistant sees them.

Action taken on behalf of Daniel Szoke.