Sandbox prompt for o55978.ingest.us.sentry.io was acli (Atlassian CLI), not Claude Code

Resolved / not a Claude Code issue — leaving this for searchability.

While using Claude Code with the Bash sandbox enabled, the sandbox network layer prompted to allow an outbound connection to o55978.ingest.us.sentry.io (a Sentry ingest endpoint). At first glance this looked like Claude Code phoning Sentry despite DISABLE_ERROR_REPORTING=1, DISABLE_TELEMETRY=1, and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1.

Root cause: it was not Claude Code. The connection came from a third-party CLI invoked inside the sandbox — the Atlassian CLI (acli), which embeds the Go Sentry SDK with a hardcoded DSN pointing at Atlassian's own Sentry org (o55978):

https://<key>@o55978.ingest.us.sentry.io/<project>

(found via strings $(command -v acli) | grep sentry)

What threw me off: Claude Code propagates its own Sentry trace context into child-process env as a BAGGAGE variable (sentry-release=Claude@…, a different Sentry org). That baggage is just trace metadata — not the connection that was blocked. The actual blocked host belonged to a different org (o55978), which is the tell.

Takeaway: if a sandbox prompt shows a Sentry/telemetry host, check which org the host belongs to and which binary owns the DSN before assuming it's Claude Code — it may be a tool you ran. Claude Code's own privacy flags were not implicated here.