Fix posthog csp

[dimaMachina]

No description provided.

[changeset-bot]

🦋 Changeset detected

Latest commit: 245ea70

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 10 packages

Name	Type
@inkeep/agents-manage-ui	Patch
@inkeep/agents-api	Patch
@inkeep/agents-cli	Patch
@inkeep/agents-core	Patch
@inkeep/agents-email	Patch
@inkeep/agents-mcp	Patch
@inkeep/agents-sdk	Patch
@inkeep/agents-work-apps	Patch
@inkeep/ai-sdk-provider	Patch
@inkeep/create-agents	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agents-api	Ready	Preview, Comment	Mar 30, 2026 4:53pm
agents-docs	Ready	Preview, Comment	Mar 30, 2026 4:53pm
agents-manage-ui	Ready	Preview, Comment	Mar 30, 2026 4:53pm

[dimaMachina]

@claude add a changeset

[inkeep-internal-ci]

Claude finished @dimaMachina's task in 40s —— View job

---

Adding Changeset

• Review PR changes
• Create changeset
• Push to branch

Added changeset rich-foxes-pump.md for @inkeep/agents-manage-ui (patch): "Fix CSP policy for PostHog and Sentry to use wildcard subdomains instead of exact host URLs"
| Branch

[pullfrog]

TL;DR — Fixes the Content Security Policy in the manage UI so PostHog and Sentry are allowed via wildcard subdomain patterns (https://*.posthog.com, https://*.sentry.io) instead of exact host URLs that break when subdomains rotate. Also adds PostHog to script-src so its tracking snippet can load.

Key changes

• Use wildcard CSP domains for PostHog and Sentry — Replaces the exact PUBLIC_POSTHOG_HOST value and the Sentry DSN-origin extraction with https://*.posthog.com and https://*.sentry.io wildcards in connect-src, following PostHog's CSP guidance.
• Add PostHog to script-src — Refactors script-src into an array-based builder (matching the existing connect-src/frame-src pattern) and includes the PostHog wildcard so its scripts are not blocked by the browser.

_{Summary ｜ 2 files ｜ 13 commits ｜ base: main ← fix-posthog-csp}

Wildcard CSP domains for PostHog and Sentry

Before: connect-src used the literal PUBLIC_POSTHOG_HOST value and parsed the Sentry DSN URL at build time to extract a single origin.
After: Both services use wildcard subdomain patterns (https://*.posthog.com, https://*.sentry.io), eliminating breakage when PostHog rotates subdomains.

The Sentry entry also becomes a simple conditional string instead of a try/catch URL-parsing IIFE.

agents-manage-ui/src/proxy.ts

Array-based script-src builder with PostHog allowlisting

Before: script-src was a hardcoded ternary string with no external domain allowlist.
After: Built as a filtered array (matching connect-src and frame-src), with the PostHog wildcard appended so tracking scripts load without CSP violations.

agents-manage-ui/src/proxy.ts

  ^{｜ View workflow run ｜ Triggered by Pullfrog ｜ Using Claude Opus ｜ 𝕏}

[claude]

PR Review Summary

(0) Total Issues | Risk: Low

This PR correctly updates the CSP policy to accommodate PostHog's and Sentry's use of multiple subdomains. The changes:

1. PostHog wildcard (https://*.posthog.com): Follows PostHog's official CSP documentation which recommends wildcard patterns because PostHog Cloud uses dynamic subdomains for different services (analytics, feature flags, session recording, etc.)

2. PostHog added to script-src: Correctly addresses that PostHog loads JavaScript for analytics/session recording, which requires script-src permissions in addition to connect-src

3. Sentry wildcard (https://*.sentry.io): Simplifies the previous URL-parsing logic while accommodating Sentry's subdomain structure

4. Helpful comment: The reference to PostHog's CSP docs is valuable documentation for future maintainers

💭 Consider (2)

💭 1) proxy.ts:12 Self-hosted PostHog consideration

Issue: The wildcard always uses *.posthog.com regardless of what PUBLIC_POSTHOG_HOST is configured to.
Why: If a deployment uses self-hosted PostHog (e.g., https://analytics.mycompany.com), the CSP would allow posthog.com subdomains but not the actual configured host. This is unlikely to be an issue for Inkeep's use case (PostHog Cloud).
Fix: For full self-hosted support, could conditionally apply the wildcard only when the host contains posthog.com.

💭 2) proxy.ts:18 Self-hosted Sentry consideration

Issue: Similar to PostHog - uses *.sentry.io wildcard regardless of DSN host.
Why: Self-hosted Sentry instances wouldn't be covered. The previous implementation parsed the DSN origin which was more precise but also more complex.
Fix: For self-hosted support, could check if DSN contains sentry.io before applying the wildcard.

Both of these are valid considerations but unlikely to affect Inkeep's deployment which appears to use PostHog Cloud and Sentry SaaS. The current implementation is simpler and follows vendor recommendations.

---

✅ APPROVE

Summary: Clean, well-structured CSP fix that follows PostHog's official guidance. The wildcard approach is the recommended solution for PostHog Cloud's dynamic subdomains. The code simplification for Sentry is reasonable. Ship it! 🚀

Discarded (0)

No findings were discarded.

Reviewers (2)

Reviewer	Returned	Main Findings	Consider	While You're Here	Inline Comments	Pending Recs	Discarded
pr-review-standards	0	0	0	0	0	0	0
pr-review-appsec	2	0	2	0	0	0	0
Total	2	0	2	0	0	0	0

[pullfrog]

TL;DR — Fixes the Content Security Policy in agents-manage-ui so PostHog and Sentry are allowed via wildcard subdomain patterns (*.posthog.com, *.sentry.io) instead of exact host URLs that break when those services rotate subdomains.

Key changes

• Use wildcard CSP domains for PostHog and Sentry — replaces the exact PUBLIC_POSTHOG_HOST value and the DSN-derived Sentry origin with https://*.posthog.com and https://*.sentry.io, following PostHog's own CSP guidance.
• Add PostHog to script-src — the PostHog host is now included in script-src alongside connect-src, allowing its tracking scripts to load without CSP violations.
• Refactor script-src to array builder — replaces the ternary string with the same .filter(Boolean).join(' ') pattern used for connect-src and frame-src, making it easier to add future domains.

_{Summary ｜ 2 files ｜ 13 commits ｜ base: main ← fix-posthog-csp}

Wildcard CSP domains for PostHog and Sentry

Before: CSP connect-src used the exact PUBLIC_POSTHOG_HOST value and parsed the Sentry DSN URL at build time to extract its origin — both broke when PostHog or Sentry rotated subdomains.
After: connect-src and script-src use https://*.posthog.com and https://*.sentry.io, covering all subdomains without maintenance.

The Sentry IIFE that wrapped new URL(...) in a try/catch is removed entirely — a static wildcard is simpler and more resilient. PostHog is also added to script-src so its inline tracking snippet is no longer blocked.

Why wildcards instead of exact hosts?

PostHog Cloud routes requests through multiple subdomains (e.g. us.i.posthog.com, us-assets.i.posthog.com) that can change without notice. Their docs explicitly recommend https://*.posthog.com. Sentry similarly uses regional ingest subdomains under sentry.io.

agents-manage-ui/src/proxy.ts

  ^{｜ View workflow run ｜ Triggered by Pullfrog ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

TL;DR — Fixes the Content Security Policy in the manage UI so PostHog and Sentry are allowed via wildcard subdomain patterns (*.posthog.com, *.sentry.io) instead of exact host URLs. This prevents CSP violations when PostHog rotates subdomains and removes a fragile URL parse for the Sentry DSN.

Key changes

• Use wildcard CSP origins for PostHog and Sentry — replaces the exact PUBLIC_POSTHOG_HOST value and the new URL(SENTRY_DSN).origin IIFE with static https://*.posthog.com and https://*.sentry.io patterns, matching PostHog's own CSP guidance.
• Add PostHog host to script-src — refactors script-src into a filterable array and includes the PostHog wildcard so its tracking scripts are no longer blocked.

_{Summary ｜ 2 files ｜ 13 commits ｜ base: main ← fix-posthog-csp}

Wildcard CSP origins for PostHog and Sentry

Before: connect-src used the exact PUBLIC_POSTHOG_HOST value and parsed NEXT_PUBLIC_SENTRY_DSN at boot to extract its origin; script-src did not include PostHog at all.
After: Both directives use https://*.posthog.com (when PostHog is configured) and https://*.sentry.io (when Sentry is configured), and script-src includes the PostHog wildcard alongside 'self' and 'unsafe-inline'.

The previous approach broke whenever PostHog Cloud rotated to a different subdomain. The Sentry IIFE was also unnecessarily complex — a static wildcard is simpler and equally secure since *.sentry.io is the only relevant origin.

Why wildcards instead of exact hosts?

PostHog Cloud routes telemetry through multiple changing subdomains (e.g. us.posthog.com, us-assets.i.posthog.com). Pinning the CSP to a single host causes intermittent blocked requests. PostHog's own docs recommend https://*.posthog.com. The same rationale applies to Sentry — *.sentry.io covers the ingest endpoint regardless of region.

agents-manage-ui/src/proxy.ts

  ^{｜ View workflow run ｜ Triggered by Pullfrog ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

Clean CSP fix. The wildcard approach for both PostHog (https://*.posthog.com) and Sentry (https://*.sentry.io) aligns with each vendor's official CSP documentation. Adding posthogHost to script-src closes a gap that likely caused script-load CSP violations. The array refactor for scriptSrcDomains is consistent with the existing connectSrcDomains/frameSrcDomains pattern.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}