I have encountered a significant and troubling blind spot in our egress monitoring infrastructure, specifically involving the Cursor IDE's integrated Claude Code agent functionality. While our standard HTTP/HTTPS proxy configuration (enforced via environment variables and system-wide policies) adequately captures traffic from most development tools, I have observed that API calls initiated by Claude Code within Cursor are completely bypassing these controls.

The issue manifests as follows: when the agent executes a command to fetch a package, call a remote API, or retrieve data from an external service, the network request does not appear in our proxy logs (Squid running with extended custom logging format, feeding into our Elastic Stack). Instead, these calls reach their destination directly, evidenced by successful connections to external endpoints from hosts that should be incapable of doing so without proxy authentication.

After substantial investigation, which involved instrumenting the Cursor process with `strace` and examining its network namespace, I have isolated the probable cause. It appears Claude Code, or the underlying engine that executes its shell commands, may be spawning subprocesses that do not inherit the standard `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables. Alternatively, it might be using a networking library or runtime that explicitly ignores these settings.

Consider this simple test case. When I, as a user, run the following in a terminal within Cursor, the call is proxied and logged:

```bash
curl https://api.publicapis.org/entries
```

However, when I ask Claude Code to "fetch the list of public APIs and show me the count," and it generates and executes functionally identical code, the connection is direct. This suggests the execution context is divorced from the user's environment.

My current diagnostic findings and configuration:

* Our corporate policy enforces proxy via `/.cursor/proxy.sh` (sourced by shell profiles) and systemd environment directives.
* Cursor's own telemetry and update checks respect these proxies (we see those logs).
* The bypass is specific to the agent's *execution* phase, not its chat/completion traffic.
* We have attempted to enforce proxy at the kernel level using `iptables` REDIRECT rules, but this breaks Cursor's legitimate websocket connections to its backend.

The security implications are severe:
* Unmonitored and potentially unauthorized exfiltration of code snippets, repository contents, or other data via API calls.
* Unfettered ingress of code from external sources (package repositories, raw GitHub links) without our standard malware scanning proxy filters.
* A complete gap in audit trails for these agent actions, which is antithetical to a zero-trust network posture.

I am seeking collaboration from others who have dissected Cursor's network behavior. Specifically:
* Has anyone reverse-engineered how Claude Code spawns its execution subprocesses?
* Are there undocumented Cursor flags or environment variables to enforce proxy inheritance?
* Would a mandatory kernel-level egress firewall (with proper exception handling for Cursor's backend) be the only viable solution, or have you found a more elegant method to ensure all agent-originated traffic flows through our inspection choke point?

The logs, as they say, do not lie. And in this case, the silence from our egress logs is a deafening security alarm.