Claude Code 网页端 GitHub 访问被 Egress 策略拦截 · 干货攻略

链接: https://x.com/simonw/status/2078344441950286160
分类: x-tips
来源: X @simonw
作者: Jay
更新: 2026-07-22

这是什么

Claude Code 网页端（claude.ai/code）突然开始拦截对 GitHub 的所有网络请求，错误信息为：

"GitHub is blocked by egress policy"

这意味着 git clone、API 调用等一切 GitHub 相关的网络操作在网页端完全失效。这不是第一次发生——根据 @simonw 的报告，这是第二次出现同类回归（first regression 发生在 2026 年 6 月 24 日，见 status/2069856334305230902）。

为什么值得关注

@simonw（Simon Willison，著名开发者、Datasette 作者）指出，这个功能对他的工作流至关重要。他的标准提示词模板之一就是：

"Clone repo X from GitHub to /tmp for reference"

把仓库克隆到 /tmp 然后阅读代码/文档，是许多开发者用 Claude Code 做调研和学习的核心方式。这个功能一旦被阻断，整个 coding agent 的调研能力就瘫痪了。

@simonw 明确呼吁 Anthropic： 1. 尽快修复这个 bug 2. 建立自动化测试，防止此类回归再次发生

这不是边缘 case——对于任何需要让 AI 访问外部代码库的用户，这个 bug 都是生产级的阻断性问题。

核验过程

官方来源

1. Claude Code 官方文档 — Settings（code.claude.com/docs/en/settings）

官方明确描述了 egress 网络策略的配置机制：

sandbox.network.allowedDomains：允许出站流量的域名数组，支持通配符（如 .example.com）
默认值为 ["github.com", ".npmjs.org", "registry.yarnpkg.com"]
sandbox.network.deniedDomains：被封锁的域名，优先级高于 allowedDomains
配置路径：~/.claude/settings.json（用户级）或项目 .claude/settings.json（项目级）

官方示例配置：

{
  "sandbox": {
    "network": {
      "allowedDomains": ["github.com", ".npmjs.org", "registry.yarnpkg.com"],
      "deniedDomains": ["uploads.github.com"]
    }
  }
}

2. Claude Code 官方文档 — Sandboxing（code.claude.com/docs/en/sandboxing）

官方确认： - 沙箱内置于 Claude Code，在 macOS/Linux/WSL2 上运行（Windows 不支持，需用 WSL2） - macOS 使用 Seatbelt 框架，Linux 使用 bubblewrap + socat - 默认情况下，沙箱外命令走常规权限流程（权限提示或 auto mode 分类器）

3. GitHub Issue #30861 & #41034（anthropics/claude-code）

Issue #30861（2026 年 3 月）：Cowork 模式下 MITM egress proxy 封锁所有非 API 域名，用户需在 Settings → Capabilities 中开启 Allow network egress 并设置 All domains
Issue #41034（2026 年 3 月 30 日）：Chrome 扩展的 Cowork 模式把所有网站（包括 google.com）都封锁了，属于同类问题

4. Anthropic GitHub Releases

截至 2026 年 7 月 21 日最新版本为 v2.1.217。

5. Microsoft Security Blog（2026 年 6 月 5 日）

与此次回归无直接关联，但提到 Anthropic 在 v2.1.128（2026 年 5 月 5 日）修复了 /proc/ 文件泄露漏洞，可作为版本时间线参考。

交叉验证结论

确认事实：Claude Code 确实存在 egress 策略机制，默认情况下 GitHub 在允许列表中，但网页端可能因会话/沙箱配置差异导致域名未被正确放行
未核验：网页端具体是哪个配置项导致本次回归（是 allowedDomains 被清空？是代理配置错误？还是 Cowork 模式特定问题）
原帖主张「第二次回归」：经核实 @simonw 确实在 2026 年 6 月 24 日（status/2069856334305230902）报告过同类问题，两次时间跨度约 24 天

上手步骤

当前 workaround：手动配置 allowedDomains

如果你的网页端遇到此问题，在 ~/.claude/settings.json（桌面端用户设置）或项目的 .claude/settings.json 中添加：

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": [
        "github.com",
        "api.github.com",
        "gist.github.com",
        "githubusercontent.com"
      ]
    }
  }
}

注意：.github.com 这样的通配符格式官方文档有提及，但实测 github.com + api.github.com 更稳妥。

网页端特殊处理

Claude Code 网页端（claude.ai/code）不走本地沙箱，其 egress 策略由 Anthropic 服务器端控制。目前 没有用户侧配置选项。如果网页端被拦截：

换用桌面/IDE 端：VS Code、Neovim、VSCodium 等桌面版支持本地沙箱配置，可手动放行域名
使用 GitHub Connector：在 Settings → Connectors 中连接 GitHub 账号，部分操作走 connector 而非 git 命令
在提示词中规避：用 WebFetch 工具代替 git clone（临时方案，不适合大仓库）

验证是否在沙箱内

在 Claude Code 会话中运行：

/sandbox

查看 Config tab，确认 network.allowedDomains 是否包含 github.com。

坑与适用边界

维度	说明
影响范围	仅限 Claude Code 网页端（claude.ai/code）；桌面/CLI 版本不受影响（可通过本地配置修复）
根本原因	网页端的服务器端 egress 策略配置问题，非用户侧配置能解决
Cowork 模式	Chrome 扩展的 Cowork 模式有独立的 egress 代理机制，Issue #41034 表明其封锁范围更广（连 google.com 都拦），属于同类但不同层面的问题
uploads.github.com	git clone 公开仓库通常不需要，但 `git push`/`git pull` 如果走 HTTPS 且需要认证，务必将 `uploads.github.com` 加入 `deniedDomains` 防止令牌外泄（官方默认配置即如此）
安全提醒	将 github.com 列入 allowedDomains 意味着沙箱内代码可以访问所有公开 GitHub 内容，包括在你的认证上下文下可访问的私有仓库
回归频率	2026 年 6 月至今已出现 2 次同类回归，平均每月 1 次，@simonw 呼吁的自动化测试目前未实现（截至 2026 年 7 月 22 日公开信息）
版本参考	官方 v2.1.217（2026-07-21）仍存在此问题；v2.1.128（2026-05-05）是 /proc/ 修复版本，与本次回归无关

一句话结论

Claude Code 网页端的 GitHub egress 拦截是一个已出现两次的生产级回归，当前无用户侧 workaround；桌面端可通过 sandbox.network.allowedDomains 配置解决，同时这也是一个明确的测试覆盖缺口——@simonw 的自动化测试呼吁至今未被 Anthropic 公开回应。