The Cowork architecture page documents one TLS interception layer:
sdk-daemon's proxy inside the Linux VM, which installs its own CA and intercepts
all traffic to *.anthropic.com. A second interception layer operates
upstream of the VM — at the boundary of the claude.ai container itself. The two
layers are independent, operate at different points in the request path, and neither
has visibility into what the other modifies.
cowork.exponential-systems.net from inside the container
was intercepted by this CA while the TLS library reported
SSL certificate verify ok — the page documenting sdk-daemon interception
was itself being intercepted by a different layer. The CCR operates at L4/TLS,
not via environment variable. HTTPS_PROXY="" does not bypass it;
the egress gateway intercepts regardless of application-layer proxy settings.
github.com, api.anthropic.com.
Blocked: arbitrary external HTTPS (returns 502 from egress layer).
*.anthropic.com.
Uses goproxy (MITM library). CA cert installed in the guest trust store —
guest processes cannot distinguish the proxy's re-encrypted connection from the
real endpoint. GitHub traffic is proxied but not TLS-stripped; OAuth tokens are
validated against an approved list. Documented in full at
cowork.exponential-systems.net.
api.anthropic.comapi.anthropic.comapi.anthropic.comThe two layers intercept at different points and do not share state. Each sees only the traffic that passes through it, re-encrypted by the other layer:
| If this layer modifies a request | Layer 1 (CCR) sees it? | Layer 2 (sdk-daemon) sees it? | VM process sees it? |
|---|---|---|---|
| Layer 2 modifies outbound request (sdk-daemon) | Yes — receives the modified plaintext | — | No — modification happened before re-encryption |
| Layer 1 modifies outbound request (CCR) | — | No — sees only what VM process sent, before Layer 1 | No |
| Layer 1 modifies inbound response (CCR) | — | Yes — receives the modified plaintext | No — if sdk-daemon forwards as-is |
| Layer 2 modifies inbound response (sdk-daemon) | No — modification happens after Layer 1 | — | Yes — receives modified content as apparently-valid TLS |
Layer 1 (CCR) sees the request as it leaves the container — after any sdk-daemon modification, before the real endpoint. Layer 2 (sdk-daemon) sees the request as it leaves the VM — before CCR, and again on the inbound path after CCR. A modification made by Layer 1 on the outbound path is invisible to sdk-daemon (which already processed the outbound request). A modification made by sdk-daemon on the inbound path is invisible to CCR (which already processed the inbound response). The chain has no single point of full observability.
The CCR layer was confirmed by direct observation documented on the
independent-verification page:
a connection to cowork.exponential-systems.net made from inside the
container was intercepted by O=Anthropic; CN=sandbox-egress-production TLS
Inspection CA, yet the TLS library reported SSL certificate verify ok.
The page documenting the sdk-daemon MITM was itself intercepted by the CCR layer
while being fetched. The two interception layers were both active simultaneously
and independently confirmed in the same observation.