[BUG] .devcontainer/init-firewall.sh: statsig.anthropic.com fails DNS resolution, aborts container startup

Status Open
Reported on v2.1.126
Maintainer reply None cached
Activity 7 comments · opened May 2, 2026

Summary

.devcontainer/init-firewall.sh includes statsig.anthropic.com in its allowlist (line 71 on main), but that hostname has no public DNS records. The script treats any unresolvable domain as fatal (exit 1), so the devcontainer's postStartCommand fails and VS Code reports container setup as failed.

Reproduction

  1. Open the upstream .devcontainer (or any fork that uses the unmodified init-firewall.sh) in VS Code Dev Containers.
  2. Container builds, then postStartCommand runs init-firewall.sh.
  3. The resolution loop hits statsig.anthropic.com:

``
$ dig +short statsig.anthropic.com
(no output)
``

  1. Script logs ERROR: Failed to resolve statsig.anthropic.com and exits 1.
  2. VS Code reports: postStartCommand from devcontainer.json failed with exit code 1.

Relevant log excerpt:

[ERROR] Failed to resolve statsig.anthropic.com
Stop (1035 ms): Run in container: /bin/sh -c sudo /usr/local/bin/init-docker-socket.sh && sudo /usr/local/bin/init-firewall.sh
postStartCommand from devcontainer.json failed with exit code 1. Skipping any further user-provided commands.

Verification

$ dig +short statsig.anthropic.com   # <empty>
$ dig +short statsig.com              # resolves
$ dig +short api.statsig.com          # resolves

statsig.anthropic.com does not appear to be a public hostname (no A, no CNAME). It may be an internal-only DNS name that leaked into the public template, or a stale entry.

Suggested fix

Either:

  • Remove statsig.anthropic.com from the domain list (statsig.com is already present at line 72 of the same file), or
  • Make the resolution loop tolerant: log a warning and continue instead of exit 1, so a single unresolvable entry doesn't kill container startup.

A diff for the tolerant version:

-    if [ -z \"\$ips\" ]; then
-        echo \"ERROR: Failed to resolve \$domain\"
-        exit 1
-    fi
+    if [ -z \"\$ips\" ]; then
+        echo \"WARN: Failed to resolve \$domain — skipping\"
+        continue
+    fi

Environment

  • claude-code: 2.1.126
  • VS Code Dev Containers extension: 0.457.0
  • Host: macOS 26.3.1
  • File: .devcontainer/init-firewall.sh @ main, lines 71 (allowlist entry) and 108–113 (fatal-exit logic)

View original on GitHub ↗

4 Comments

github-actions[bot] · 4 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/35197

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

pmeder-ionos · 3 months ago

Would be interesting to know why it worked last week, but fails now?

lagr · 3 months ago

It used to resolve for me but no longer does. Maybe this is due to an ongoing migration off of Statsig? (Related GH Issue)

animaartificialis · 3 months ago

There's also PR #32848 proposing a different fix — turning the hard exit 1 into WARNING + continue. I'd vote for #56179 instead.

The script's hard-exit on DNS failure looks intentional: set -euo pipefail plus a hardcoded allowlist together form a contract that "these domains must be reachable for the firewall to come up." Silently skipping a stale entry would leave the policy partially applied — and if api.anthropic.com ever failed to resolve for a real reason, we'd want the loud failure, not a warning.

The right fix here is to update the allowlist (#56179), not to relax the failure model. #32848 might make sense for transient-failure scenarios, but landing it in response to this bug would just mask future drift.

Showing cached comments. Read the full discussion on GitHub ↗