[richiemcilroy]

Server and edge tracing are off: tracesSampleRate is 0. Sentry still adds sentry-trace and baggage headers to every outgoing request from those runtimes. Nothing reads them: the media server and the other services Cap calls don't use Sentry. Some outgoing requests go to customers' own servers, for example Cap Infra webhook deliveries, and those servers then receive the release and project details the headers carry.

Change

tracePropagationTargets: [] in sentry.server.config.ts and sentry.edge.config.ts, so no outgoing request gets the headers.

What stays the same:

• Error reporting.
• The browser config.
• The CORS rules that let browsers send these headers to Cap.

Tests

sentry-server-propagation.test.ts loads both configs and checks the setting. It fails without the change. The existing Sentry browser filter test still passes.

Proof on Vercel previews

I built two throwaway cap-web previews, one from main and one from this branch. Each had a temporary route that sent requests to a capture server I ran. The route and both branches are now deleted.

Request	main	this branch
sendDeveloperWebhook (the real Infra webhook path, node:https)	sentry-trace and baggage sent	neither sent
fetch from a Node route	sentry-trace and baggage sent	neither sent
fetch from an Edge route	neither sent	neither sent

On main, baggage carried sentry-environment, sentry-release, sentry-public_key, sentry-trace_id and sentry-org_id. The Edge runtime sent no trace headers on main either, so on Edge the setting only keeps it that way. The webhook still delivered (200) with its cap-signature, cap-event-id and cap-event-type headers.

Error reporting is unchanged. A test exception sent from the branch preview reached Sentry ingest with HTTP 200 on Node, the same as on main. On Edge, afterSendEvent fired on both builds with the same empty result. instrumentation-client.ts is not touched.

The full apps/web unit suite gives the same result as main, plus the 2 new tests. The only failures are 7 share-stage-identity tests, which fail on main too.

Production proof (after merge)

I checked this on production after deploy 083ef75 with a real Infra delivery, using no temporary route. A test app registered a webhook endpoint pointing at a receiver I ran, and I uploaded one clip. Exactly one video.ready arrived 36.9 s into the run, and its cap-signature verified. No second video.ready came in the following 30 s. The earlier webhook.test delivery had the same headers. Both the endpoint and the video were deleted afterwards: the video now returns 404 and the endpoint is gone from the list.

Header names received on video.ready (names only):

accept-encoding, cap-event-id, cap-event-type, cap-signature, cdn-loop, cf-connecting-ip, cf-ew-via, cf-ipcountry, cf-ray, cf-visitor, cf-warp-tag-id, cf-worker, connection, content-length, content-type, host, user-agent, x-forwarded-for, x-forwarded-proto, x-invocation-id, x-vercel-id

There was no sentry-trace, baggage or traceparent. The cf-* and cdn-loop headers come from the tunnel in front of the receiver, not from Cap.

Confidence Score: 5/5

The PR appears safe to merge; no actionable issues were found.

Summary

Sets tracePropagationTargets: [] in the Node and Edge Sentry configs to stop outgoing trace headers.

• Outgoing server requests no longer carry Sentry trace headers.

_{Reviews (3) · Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." · Reviewed by Greptile}

[sandchest-com]

Sandchest reviewed 451ffa9: nothing exploitable found in this change.

_{Sandchest reviews every change for vulnerabilities an attacker could use · Review details}

[capy-ai]

Capy found no issues.

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated
cap-status	Skipped		Nov 13, 2026 1:16pm UTC

[capy-ai]

Capy found no issues.

[capy-ai]

Capy found no issues.

[richiemcilroy]

@greptileai