Your Coding Agent Is Lying About Its Health — Here's How to Catch It

Last month I watched a friend spend three hours troubleshooting a "Remote Control won't take input" problem on his Windows laptop. The CLI said /rc active in green. The Android app showed a live session. Messages landed in the thread and rendered perfectly. They just never reached the machine. We blamed the VPN. We blamed the office Wi-Fi. We reset sessions, re-authed, toggled every setting we could find. The actual cause? Norton 360's SSL scanning was silently re-signing every TLS connection, killing the long-lived inbound channel while leaving normal API traffic completely untouched.

The Norton bug is interesting but narrow. What stuck with me is the pattern: the agent confidently reported a healthy state while a critical subsystem was dead. No error. No warning. Every diagnostic came back clean.

This isn't a Norton problem. It's a "how do you know your agent is actually working?" problem. And if you've never hit it, you will.

Why Status Indicators Lie

Most agents maintain two kinds of connections:

1. Request-response — you send a prompt, get a reply. Short-lived. Survives most network interference.
2. Long-lived channels — streaming, Remote Control, background watchers, file sync. These break. A TLS interceptor that re-signs certificates can pass a 2-second API call while killing a 30-minute persistent connection.

The Five-Minute Diagnostic

Step 1: Check who signed the certificate.

echo | openssl s_client -connect api.anthropic.com:443 2>/dev/null | openssl x509 -noout -issuer

If the issuer says Let's Encrypt or Amazon, you're talking to the real server. If it says Norton, McAfee, or your company's proxy CA, something is intercepting your traffic.

Step 2: Test the long-lived path specifically. Start a background task, let it sit for 10 minutes. If it drops without warning, you have an interception problem.

Step 3: Check for invisible proxies.

netsh winhttp show proxy  # Windows
env | grep -i proxy        # Linux/Mac

Step 4: Try from a different network context. If you're on Windows, try from WSL. If on corporate WiFi, try your phone's hotspot.

Step 5: Check the certificate chain, not just the result.

curl -v https://api.anthropic.com 2>&1 | grep -E "issuer|subject|SSL"

A 0 return code means the handshake succeeded, but not that it was with the real server.

The Common Culprits

1. Consumer antivirus with TLS scanning — Norton, McAfee, Kaspersky. #1 cause on Windows.
2. Corporate SSL inspection proxies — Zscaler, Blue Coat, Palo Alto.
3. VPN split tunneling misconfiguration — double-encrypted tunnel drops mid-stream.
4. Windows Firewall with deep packet inspection
5. Router-level content filtering — Eero, Google Wifi, consumer Netgear.

The Bigger Lesson

Your agent's status indicator is a claim, not a fact. Treat it accordingly. The five minutes you spend verifying saves you the three hours I spent blaming the VPN.

Originally published at terminalblog.com