fix(web): disable PostHog session replay only in local dev

[leoisadev1]

Summary

• Changes disable_session_recording from unconditional true to import.meta.env.DEV
• Session replays now record in production but are suppressed during local development
• Vite statically resolves import.meta.env.DEV to false in production builds

Test plan

• Run bun dev locally → verify no session replay network requests to PostHog
• Deploy to preview/prod → verify session recordings appear in PostHog

---

Created with PostHog Code

[greptile-apps]

Greptile Summary

This PR enables PostHog session replay in production by changing disable_session_recording from a hard-coded true to import.meta.env.DEV, so Vite statically resolves the flag to false in production builds and true during local dev.

• One-line change in apps/web/src/lib/posthog.ts — swaps true for import.meta.env.DEV on disable_session_recording.
• Replay now active in all non-DEV builds — this includes staging and preview environments in addition to production, which could mix replay data if they share the same PostHog project token.
• No reverse proxy configured — session replay payloads now flow directly to us.i.posthog.com, which ad blockers can and do block; setting up a reverse proxy before this goes to production would improve capture reliability.

Confidence Score: 4/5

The change is functionally correct — session replay will be suppressed in local dev and active in production builds as intended.

The one-line swap works as described and Vite's static replacement of import.meta.env.DEV is well-understood. The main thing to double-check before merging is whether staging/preview environments override VITE_POSTHOG_TOKEN; if they don't, their replays will land in the same PostHog project as production. The lack of a reverse proxy is also worth addressing soon now that replay payloads are being sent in production, but neither concern blocks the core intent of the PR.

Only apps/web/src/lib/posthog.ts changed. Verify environment variable configuration for staging/preview deployments before merging.

Important Files Changed

Filename	Overview
apps/web/src/lib/posthog.ts	Single-line change enables session replay in all non-DEV Vite builds; staging/preview environments sharing the same PostHog token will now also record replays, and no reverse proxy is configured for production.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Vite Build] --> B{import.meta.env.DEV?}
    B -- true\nbun dev / local --> C[disable_session_recording = true\nNo replay captured]
    B -- false\nproduction build --> D[disable_session_recording = false\nReplay enabled]
    D --> E{Environment}
    E -- Production --> F[PostHog Project\nProduction token]
    E -- Staging / Preview --> G{Separate VITE_POSTHOG_TOKEN?}
    G -- Yes --> H[PostHog Project\nStaging token]
    G -- No --> I[Same PostHog Project\nData mixed]
    F --> J[us.i.posthog.com\ndirect - adblock risk]
    H --> J

Loading

Comments Outside Diff (2)

1. apps/web/src/lib/posthog.ts, line 55 (link)

   Session replays sent directly to PostHog's domain — adblocking risk

   api_host defaults to https://us.i.posthog.com, meaning session replay payloads are now sent directly to PostHog's known domain in production. Ad-block lists catalog this domain, so some users' replays will be silently dropped. PostHog recommends routing through a reverse proxy on your own subdomain before going to production for more reliable capture (typically improves event capture 10–30%). See PostHog reverse proxy docs.

   Confidence this is an issue: 3/5 — depends on the user base and whether adblock penetration matters here.

   

2. apps/web/src/lib/posthog.ts, line 55 (link)

   No ui_host alongside api_host when using a custom proxy

   api_host is configurable via VITE_POSTHOG_HOST, but ui_host is never set. Per PostHog docs, both must be set together when using a reverse proxy so features like the PostHog toolbar resolve correctly. If VITE_POSTHOG_HOST is ever pointed at a proxy, the toolbar and other PostHog UI links will break silently. Now that session replay is active in production this gap becomes more relevant since replay loads recorder.js through api_host.

   Confidence this is an issue: 2/5 — only matters if a custom proxy host is actually configured.

   

_{Reviews (1): Last reviewed commit: "fix(web): disable PostHog session replay..." | Re-trigger Greptile}

[greptile-apps]

Replay fires in staging/preview builds too

import.meta.env.DEV is false for every Vite production build — including any staging or preview environment. If those environments share the same VITE_POSTHOG_TOKEN as production, their session replays will land in the same PostHog project and pollute the production replay feed. Ensure each non-production deploy overrides VITE_POSTHOG_TOKEN with a separate project token, or consider guarding with an environment-aware expression (e.g. import.meta.env.MODE !== 'production') if a distinct staging mode is configured.

Confidence this is an issue: 3/5 — depends on whether staging already uses a separate PostHog token.