You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #21 ("Remove firewall feature from claude-code") merged on 2025-06-13, removing all firewall logic from the claude-code feature. A year later, the published artifact ghcr.io/anthropics/devcontainer-features/claude-code:1.0 is still v1.0.5 and still contains the pre-#21 behavior. Could you cut a release (e.g. v1.0.6 or v1.1.0) so the artifact matches main?
The stale artifact is the root cause of at least two open issues:
Claude Code devcontainer feature silently overwrites custom /usr/local/bin/init-firewall.sh #38 — install.sh in the published artifact (setup_firewall_script(), ~line 117) unconditionally copies its bundled script to /usr/local/bin/init-firewall.sh. Features build after the user's Dockerfile, so any user-provided script at that path is silently overwritten, and there is no feature option to disable this ("options": {}).
One more failure mode we hit (not yet covered by those issues): the bundled script hard-fails the whole container setup (exit 1) when any domain in its allowlist fails to resolve — including statsig.anthropic.com and statsig.com. Enterprise networks commonly block telemetry domains at DNS level, even though Claude Code works fine there with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1. Combined with the silent overwrite, the sequence is nasty to debug: a user writes their own firewall script that tolerates blocked telemetry domains, the feature silently replaces it, and postCreateCommand then aborts on a domain the user never asked to allowlist.
The divergence makes this hard to troubleshoot from source: src/claude-code/install.sh on main contains no firewall logic at all, yet devcontainer-feature.json on main also says 1.0.5 — the same version string as the published artifact that does contain it. Inspecting the repo tells you the bug shouldn't exist.
Verified today (2026-06-12) by pulling the OCI layer for claude-code:1.0 from ghcr.io: manifest reports v1.0.5, install.sh contains setup_firewall_script(), bundled init-firewall.sh is the 119-line version.
Bump the version in devcontainer-feature.json as part of that release, so the source and published artifact can't share a version string while differing in behavior.
If a firewall script ever returns to this feature: namespace it (e.g. claude-init-firewall.sh), never overwrite an existing file, gate it behind a feature option, and make it warn-and-continue on unresolvable domains rather than aborting container setup.
Happy to send a PR for the version bump if that helps.
PR #21 ("Remove firewall feature from claude-code") merged on 2025-06-13, removing all firewall logic from the
claude-codefeature. A year later, the published artifactghcr.io/anthropics/devcontainer-features/claude-code:1.0is still v1.0.5 and still contains the pre-#21 behavior. Could you cut a release (e.g. v1.0.6 or v1.1.0) so the artifact matchesmain?The stale artifact is the root cause of at least two open issues:
install.shin the published artifact (setup_firewall_script(), ~line 117) unconditionally copies its bundled script to/usr/local/bin/init-firewall.sh. Features build after the user's Dockerfile, so any user-provided script at that path is silently overwritten, and there is no feature option to disable this ("options": {}).init-firewall.shis an outdated copy that breaks DNS in docker-compose setups.One more failure mode we hit (not yet covered by those issues): the bundled script hard-fails the whole container setup (
exit 1) when any domain in its allowlist fails to resolve — includingstatsig.anthropic.comandstatsig.com. Enterprise networks commonly block telemetry domains at DNS level, even though Claude Code works fine there withCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1. Combined with the silent overwrite, the sequence is nasty to debug: a user writes their own firewall script that tolerates blocked telemetry domains, the feature silently replaces it, andpostCreateCommandthen aborts on a domain the user never asked to allowlist.The divergence makes this hard to troubleshoot from source:
src/claude-code/install.shonmaincontains no firewall logic at all, yetdevcontainer-feature.jsononmainalso says1.0.5— the same version string as the published artifact that does contain it. Inspecting the repo tells you the bug shouldn't exist.Verified today (2026-06-12) by pulling the OCI layer for
claude-code:1.0from ghcr.io: manifest reports v1.0.5,install.shcontainssetup_firewall_script(), bundledinit-firewall.shis the 119-line version.Asks
mainso the artifact no longer installs/overwrites/usr/local/bin/init-firewall.sh(this alone resolves Claude Code devcontainer feature silently overwrites custom /usr/local/bin/init-firewall.sh #38 and claude-code feature v1.0.5 bundles outdated init-firewall.sh without DNS restoration #30).devcontainer-feature.jsonas part of that release, so the source and published artifact can't share a version string while differing in behavior.claude-init-firewall.sh), never overwrite an existing file, gate it behind a feature option, and make it warn-and-continue on unresolvable domains rather than aborting container setup.Happy to send a PR for the version bump if that helps.