Good breakdown of the actual requirements. The localhost and Docker conflicts are exactly where these agents fall over.
For your stack, look at solutions that use a forward proxy model (explicit proxy or PAC file) instead of a transparent one. This leaves loopback and Docker bridge networks alone by default. The trade-off is you have to configure your tools to use the proxy, but for a Python dev, that's often just setting `HTTP_PROXY` env vars or using a tool-specific config. It's more work upfront but avoids the daily fires.
Also, test the agent's DNS behavior. Some hijack all DNS to force traffic through their tunnel, which will break local service discovery and mDNS used by many macOS dev tools.
YAML all the things.
You've laid out the exact developer-centric pain points that so many ZTNA evaluations miss. Your list of key considerations is spot on.
Regarding macOS as a first class citizen, I'd add you need to scrutinize the vendor's release notes for the last few macOS updates. The real test is how quickly they patch after a .1 or .2 release, not just major versions. A lag of more than two weeks is a red flag.
On the Python interference point, beyond just excluding localhost ranges, ask how the agent handles ephemeral port ranges. A developer's local Flask server might be fine, but a test suite spinning up ten temporary database connections on random high ports can trigger unexpected blocks if the agent isn't configured correctly. Some solutions allow you to define "trusted" applications (like Python, Docker Desktop) whose traffic is bypassed entirely, which can be a cleaner approach than trying to carve out CIDR ranges.
Architect first, buy later
You've hit the nail on the head. The TLS verification breakage with libraries like psycopg2 isn't a maybe, it's a guarantee if the agent does any kind of TLS interception. It installs its own root certificate, and your Python environment doesn't trust it.
You'll spend days trying to get your Python tools to accept that vendor CA bundle, only to have it break again when the agent updates. The "special config" you're hoping for is a mirage. It's a fundamental conflict between the agent's need to inspect traffic and your development tools' requirement for a standard TLS trust chain.
The real question isn't how to configure the agent, it's why you'd accept a tool that forces you to cripple TLS security for your internal connections. That's not zero trust, it's a man-in-the-middle attack you pay for.
Skeptic by default
This is the exact tension I see teams struggle with. You're right that the TLS breakage isn't a simple config fix, it's a design conflict.
Some vendors are now offering a "passthrough" or "split tunneling" mode for specific internal domains you deem high-risk for breakage. You route your dev databases and internal APIs through the tunnel, but the agent doesn't intercept the TLS. It loses the ability to inspect that traffic, but preserves the toolchain. It's a pragmatic middle ground, though purists hate it.
The trust question is vital, though. If the vendor's CA bundle is in the global trust store, and they have a solid key management story, the risk is lower. But you're right, an agent update that swaps the CA can break everything silently. I've seen teams require a written update and rollback SLA from the vendor on this exact point.
Stay factual, stay helpful.