Why Claude Code Knocks Your Whole House Offline

You open four terminals. You start Claude Code in each one. Twenty minutes later the TV stops streaming, the kids' iPads drop off Wi-Fi, and you can't even load your router's admin page.

It feels like Claude Code ate your bandwidth. It didn't. It ate your router's connection table. Here is what is going on and how to stop it.

It's not bandwidth. It's connection count.

Every time a program on your network opens a connection to the internet, your router writes it down in a table. This is called the NAT table. Each row maps one of your devices to one outside port. Home routers have a small table. When it fills up, the router can't open new connections for anyone. Your speed is fine. The router just has no room left to track one more conversation.

That's why a speed test can look normal right before everything falls over. The problem is how many connections are open, not how much data moves through them.

Claude Code opens a lot of connections

A single Claude Code session does not open one connection. It opens many.

One developer measured a one word prompt (claude -p "ok") on Linux. It opened 14 to 18 TCP connections, with up to 13 open at the same time (issue #106875). The API, the MCP proxy and claude.ai all sit on the same IP address, so every connection counts against the same budget. Most of those connections came from two things: claude.ai connectors loading into the CLI, and non-essential traffic like telemetry. Each one seemed to get its own connection instead of sharing one.

Now multiply that by every terminal you have open. Then add the MCP servers each session starts.

Then a network blip turns it into a storm

The real damage happens when something hiccups. A Wi-Fi drop, a VPN reconnect, a slow API response.

Each session starts retrying. Failed connection attempts sit in a half-open state (SYN_SENT) and hold their slot in the router table while they wait to time out. On macOS that wait is 75 seconds. New attempts come in faster than old ones expire.

One user running just 3 parallel Claude Code instances found about 290 connections stuck in that half-open state. The router's table filled up and the whole household went offline. DNS failed, sites timed out, and the router admin page wouldn't load (issue #19006). Another user stress tested his consumer fiber router and found it choked somewhere between 280 and 345 connections opened all at once. The same router handled 500+ when connections were spaced out. Once the storm stopped, it recovered in about 5 seconds.

So the pattern is: lots of sessions, lots of connections each, no backoff when things go wrong. A cheap router can't keep up.

The other "ports" problem: leftover MCP servers

There is a second issue that people often mix up with this one.

Claude Code starts MCP servers as separate processes. When a session ends, crashes, or you close the terminal, those processes are not always killed. They pile up. One report counted 107 orphaned MCP processes after a normal workday with several sessions (issue #33947). Another found 172 after a heavy agent session, using over 1 GB of RAM (issue #40667).

These leftovers hold local ports, memory and open connections. They usually don't kill your internet. They do slow your machine down and can stop new sessions from starting their MCP servers. Worth cleaning up either way.

How to prevent it

1. Cut how many connections each session opens. Add this to ~/.claude/settings.json:

{
  "env": {
    "ENABLE_CLAUDEAI_MCP_SERVERS": "false",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
  }
}

The first stops your claude.ai connectors from loading into every CLI session. The second turns off telemetry, error reporting and the auto updater. In the test from issue #106875, setting both dropped a session from 14 to 18 connections down to a steady 3. Two tradeoffs: run claude update yourself now and then, and add back only the MCP servers you actually use with claude mcp add.

2. Run fewer sessions at once. Three to five parallel sessions is plenty on a home router. If you script agent loops, cap the parallelism and stagger the start times so they don't all connect in the same second.

3. Close sessions before you switch networks or VPNs. A network change is what kicks off the retry storm. Sessions can also hang on to dead connections after a switch (issue #23744). Quit, switch, then restart.

4. Check if you're close to the edge. Count half-open connections:

# macOS
netstat -an | grep SYN_SENT | wc -l

# Linux
ss -tan state syn-sent | wc -l

A handful is normal. Hundreds means a storm is happening right now.

5. Clean up orphaned MCP servers. See what's still running:

ps aux | grep -i mcp | grep -v grep

Kill the leftovers by name, for example pkill -f context7-mcp. If this happens to you a lot, add a Stop hook that cleans up after each session. The open source claude-code-cleanup project has one ready to copy.

6. Fix the router side if you run agents all day. A better router has a bigger NAT table. Or move heavy agent work to a cloud VM. Note that cloud NAT has limits too. Google Cloud NAT defaults to 64 ports per VM, and about 15 sessions on one VM hit that wall in the issue #106875 test. Raise the minimum ports per VM if you go this route.

Does Codex have the same problem?

Yes. OpenAI's Codex CLI and desktop app show the same two patterns.

Too many connections. One user spawned 6 Codex subagents and had them generate images at the same time. That opened about 700 outbound TCP connections, with a burst stuck in SYN_SENT. His internet provider then refused new connections from his PC for a few minutes (issue #29207). In another report, running many codex exec processes in parallel made each one download its own full copy of the same plugin marketplace from GitHub. That meant dozens of HTTPS connections at once, saturated bandwidth and gigabytes of duplicate data (issue #36093).

Leftover MCP servers. Codex leaks MCP processes too, and the reports are bigger. One long running Codex process piled up 492 orphaned MCP children in about 15 hours (issue #18881). Another found 133 orphans using about 9.3 GB of RAM after 25 threads in the desktop app (issue #30408). On macOS these leaks can also hit the open file limit, so Codex fails with "Too many open files" (issue #26984).

The fixes are the same idea. Run fewer sessions and subagents at once, especially for heavy tasks like image generation. Don't fire off a big batch of codex exec runs at the same second. Kill leftover MCP processes with ps and pkill, and restart the Codex app now and then if you live in it all day.

So this isn't a Claude Code bug. It's what happens when AI coding agents that each open lots of connections and child processes meet a home router. Any agent tool run in parallel can do it.

If your internet is already down

Kill the Claude processes first: pkill -f claude. Wait a minute for the half-open connections to time out. Your network should come back on its own. Reboot the router only if it doesn't.

The bottom line

Claude Code doesn't flood your bandwidth. It opens too many connections, and when the network blinks it opens even more. Codex can do the same thing. For Claude Code, two settings cut it by about 80%. Fewer parallel sessions and closing sessions before network changes handle the rest. The behavior is reported in Anthropic's GitHub issues, so expect it to improve. Until then, set those two variables and keep your family's Wi-Fi alive.