The concept of skills seems ubiquitous, but #Anthropic announced them barely a year ago: github.com/anthropics/skills/commit/37292f37bf4bd…
Claude Code was mailing your email address to every website it visited: the User-Agent leak, the 5-month system-prompt issue, and the 5-point check
---
published: true
tags: security, ai, privacy, agents
description: "Claude Code put your account email in the User-Agent header of its web requests, so every server log on the agent's path harvested a scam-ready lead, and the same email ships in the system prompt of every session, an issue open since July. Fixed by a built-in mod in 2.1.317 after the issue went viral. The mechanics, the timeline, and the runtime test for your install."
series: black box
---
> Two GitHub issues, five months apart, describe the same leak through two different pipes. Yesterday's, filed at 22:13 and now at 360 reactions: Claude Code sends your account email address to arbitrary third-party websites in the User-Agent request header when its web tools run. The reporter's evidence is his inbox: dozens of scam emails per day, because every server log on the agent's path was harvesting a verified, active, AI-tool-using developer address. The July one (#81138, still open): the same email is injected into the model's system prompt on every session, code quoted from the shipped bundle. Anthropic shipped a fix, a built-in cc-plugin-privacy mod in v2.1.317+, the same day the newer issue went viral. This post is the mechanics of both pipes, the timeline that says the fix tracked attention rather than the July report, and the five checks that tell you what your install is doing tonight.
Pipe one: the User-Agent that identified you to strangers
The User-Agent header travels with every HTTP request your tools make, and it is logged by default on virtually every web server on earth. Claude Code's web tooling included the signed-in account's email in it. Consequences, in increasing order of bad:
- Every website your agent fetched saw a verified, working email belonging to a developer who pays for AI tooling. That is not a tracking identifier; that is a pre-qualified lead, and server logs are bought, sold, leaked, and aggregated as a matter of course.
- It bound your agent traffic and your human identity into one string. Sites that wanted to rate-limit agents got everything they needed to rate-limit you; sites that wanted to target AI users got the exact address.
- The reporter's flood of scam mail is the expected outcome, not an anomaly: a UA header is a form submission to every intermediary on the path.
And the kicker, which the reporter stated plainly: the identifier did nothing useful. It did not help services distinguish agentic traffic (a coarse marker would), it destroyed the anonymity of the session, and it was a scammer goldmine. PII in a header is the worst of both worlds: no functional benefit, total exposure.
Pipe two: the email inside every system prompt
The July issue (#81138, filed 2026-07-25, titled "[BUG] Account email (PII) is injected into the model's system prompt without consent") documents the other pipe, with bundle code quoted from v2.1.220:
let n = process.env.ANTHROPIC_UNIX_SOCKET ? void 0 : dc()?.emailAddress
return {
...(n && { userEmail: `The user's email address is ${n}.` }),
...
}
Which renders into every session's system prompt as:
# userEmail
The user's email address is <account email>.
Sourced from ~/.claude.json → oauthAccount.emailAddress. Where does a system prompt travel? To the API, into logs on both sides, into any context the session touches, and from there, potentially, into anything the model quotes or forwards. The issue's framing is precise and worth repeating: personal data given for authentication, repurposed as session content, without consent or disclosure. As of tonight that issue is still open.
The timeline that matters
- July 25: #81138 files the system-prompt injection, with bundle source. No fix lands.
- November 5, 22:13: #107757 files the User-Agent variant. Reactions climb into the hundreds within the day.
- November 5, same day: an Anthropic contributor replies: a built-in mod, cc-plugin-privacy, introduced in v2.1.317 and later, "deterministically blocks this behavior", is enabled by default, can be toggled via /plugins, and its source will be published alongside the other built-in mods.
- The anomaly worth watching: the reporter ran v2.1.318, allegedly post-fix, and still saw the leak. Possibilities: the mod was disabled on his machine, the blocking has a gap (the staff reply explicitly asks for gap reports), or version confusion. "Enabled by default" is not "verified on your machine", which is what the runtime check below is for.
One comment in the thread names the uncomfortable pattern: the original privacy issue sat for five months, and the fix shipped the day the new one hit the front page. "You can literally sort issues by emoji count and 80/20 it." An agent could triage that queue; the queue's owners apparently needed HN instead.
The five-point check for your install
Run on any machine with Claude Code. On mine, the CLI is absent but ~/.claude.json exists with no oauthAccount (so the PII field is empty): your results will vary, and check 3 is the one that settles everything.
# 1. Version: the built-in privacy mod ships in 2.1.317+
claude --version
# 2. Is the mod present and enabled?
# In Claude Code: /plugins -> look for cc-plugin-privacy (default: on)
# 3. THE RUNTIME TEST: a local listener tells you what your agent actually sends:
mkdir /tmp/uatest && cd /tmp/uatest && python3 -m http.server 8899 &
# then, inside Claude Code, ask it to fetch: http://127.0.0.1:8899/probe
# and read the log line that appears:
# "GET /probe HTTP/1.1" 200 - <- the UA is what python logs BEFORE this
# better, log it explicitly:
python3 -c "from http.server import *; import sys
class H(BaseHTTPRequestHandler):
def do_GET(self):
print('UA =', self.headers.get('User-Agent'), file=sys.stderr, flush=True)
self.send_response(200); self.end_headers(); self.wfile.write(b'ok')
HTTPServer(('127.0.0.1', 8899), H).serve_forever()"
# UA contains your email -> still leaking (report it: issue #107757)
# UA is a generic string -> blocked on your build
# 4. What is at stake locally: does your config even carry the email?
python3 -c "import json,os; d=json.load(open(os.path.expanduser('~/.claude.json'))); \
print('email present:', 'emailAddress' in d.get('oauthAccount', {}))"
# 5. The system-prompt check (July issue): in a fresh Claude Code session, ask:
# \"What is my email address?\"
# If the model knows it unprompted, the #userEmail block is still in your prompt.
Check 5 doubles as the general lesson: ask your agent what it knows about you. It reads its system prompt more honestly than the changelog reads.
The principle, and the month's pattern
Your agent is you on the web. Its headers are your headers, its prompts are your context, and everything it carries leaks at the union of every hop. Identifying agentic traffic is a legitimate need, and the correct answer is a class marker ("this is an automated client, product X, version Y"), not your identity. Anthropic's fix, a deterministic blocking mod, is the right shape, and shipping it by default is right; the five-month gap between report and fix, and the fact that it closed only under viral load, is the part to remember at renewal time.
The ledger of the agent era, one more line: transcripts shipped to the model, extensions backdooring at load, a vendor installing itself into rival agents, and now the agent leaking your address to every server it touched. Same target every time: the agent's outbound surface is the user's outbound surface. Audit it like it is yours, because it is.
TL;DR: Claude Code put your account email in the User-Agent of its web requests (every server log got a scam-ready lead; the reporter's inbox proved it) and ships the same email inside every session's system prompt (issue open since July 25). Fixed by the built-in cc-plugin-privacy mod in 2.1.317+ the day the new issue went viral; the reporter was on .318 and still saw it, so run the runtime check: local listener, make your agent fetch it, read the UA. Five checks above; two minutes; your inbox will thank you.
Sources: Issue #107757: Privacy violation in User-Agent header (report + staff reply re cc-plugin-privacy) · Issue #81138: email in the system prompt, July 25, bundle code · built-in mods: github.com/anthropics/claude-code/tree/main/mods
5 reactions
Claude 联网搜索资料会泄露用户邮箱
A/又开始作妖了，刚刚 GitHub 上爆出个让人头皮发麻的事。
有个哥们最近邮箱天天收到一堆乱七八糟的诈骗邮件，顺藤摸瓜抓包查本地流量，当场人傻了。
罪魁祸首是他本地终端里跑的 Claude Code 。
Claude 现在只要联网搜索资料，就会把你的真实个人邮箱直接写进 HTTP 的 User-Agent 请求头。
它每抓一个网页，你的私人邮箱就顺手送进对方的服务器日志里。
那些扫日志倒卖数据的黑产连爬虫都不用折腾，直接坐着收割。
更绝的是 A/官方的做法。
源码里删掉拼邮箱那行代码只要几秒钟，官方人员不这么干，跑去 Issue 里一本正经地回复，说最新版加了个隐私插件专门拦截这种行为。
自己往井里倒机油，转头大张旗鼓宣布研发出了滤水器，还当成技术特性端上来。
大家在本地把文件读写和系统权限放心地全交出去，结果大厂官方工具一出门就拿着你的私人信息到处乱送。
这操作连普通流氓软件看了都要直呼内行。
claude-code#107757
Claude Code v2.1.318——無人実行とネットワークホームの安定性が上がった5つの修正
深夜に動かしている無人実行のログを見ていると、idle compaction が走ったターンの直後で会話が壊れていたことがある。スクリプト自体は「成功」と返していたが、翌朝のアウトプットが意味をなしていない。v2.1.318 を見たら、これが修正された項目のひとつだった。
> この記事で分かること：
> - v2.1.318（2026-11-04 リリース）で修正された項目のうち、無人バッチ・ネットワーク共有環境に直結する5か所
> - claude auth status に追加された loginExpiresAt（有効期限の事前確認が楽になった）
> - 2.1.314 で入った --continue の regression の確認手順
今回のリリース v2.1.318 は Added 4件・Fixed 35件超・Improved 10件超の大型パッチだ。全変更は公式リリースページで確認できる（github.com/anthropics/claude-code/releases/tag/v2… Claude Code を無人実行・ネットワーク共有環境で動かしている立場から、特に気になった5か所に絞って整理する。
1. idle compaction が会話の中身を壊していた（Fixed）
修正内容：Fixed idle compaction replacing a conversation with a reply that was not a summary
idle compaction は、コンテキストウィンドウが長くなったとき Claude Code がバックグラウンドで自動的に会話を要約・圧縮する仕組みだ。長時間のセッションや、無人実行で繰り返し --continue を使う場面では必須の機能になっている。
問題は、compaction が「要約（summary）ではない返答」で会話全体を置き換えることがあった点。要約の代わりに、たとえば直前のターンの返答がそのまま挿入されてしまい、見かけ上は会話が継続しているが中身がおかしい状態になっていた。
無人実行では人間がリアルタイムで確認しない。compaction が走るタイミングは制御できないため、この問題が発生しても「ログを読むまで気づかない」ことになる。正直、これを最初に踏んだときは原因の特定に時間がかかった。
v2.1.318 以降は、compaction の際に適切な要約が入るよう修正されている。
確認手順：claude -p のJSON出力でセッションの整合性を確認するとき、会話の流れが突然おかしくなるターンがあった場合は、直前の compaction ログと照らし合わせると良い。
2. --continue でセッションが消えることがあった（2.1.314 regression）
修正内容：Fixed --continue sometimes losing the earlier conversation after a malformed tool call's retries ran out (regression in 2.1.314)
v2.1.314 で入った regression だった。ツールコールが不正な形（malformed）だった場合、リトライが上限に達したあとに --continue で再開しようとすると以前の会話が失われることがあった。
無人実行のスクリプトではエラーリトライを組んでいるケースが多い。ツールコールのエラーが続いてリトライ上限に当たった後に --continue を使うと、その回の会話がすっかり消える、という挙動だった。
v2.1.313 以前を使っていた場合や、2.1.314〜2.1.317 の間でこの問題に当たっていた場合は、v2.1.318 へのアップデートで修正される。
確認手順：ツールコールのリトライが多発しているセッションを --continue で再開して、会話の履歴が残っているかを確認する。
3. ネットワークホームの設定ファイルが失われやすかった（Fixed / Improved）
修正・改善内容（主なもの）：
- Fixed jobs exiting with Not logged in when another terminal or host signs in again to the same account
- Fixed sessions being refused at startup by an allowedProviders list that another login had stored
- Improved how ~/.claude.json, settings files and the stored login survive saves on shared network home directories
- Improved sessions on network file systems to look again when the configuration file is wrongly reported as missing
企業環境では複数マシンや複数ユーザーが同じネットワークホームディレクトリを参照していることがある。その場合に ~/.claude.json や settings ファイルが保存・読み込みのタイミングで壊れたり消えたりすることがあった。
具体的に起きていたこと：
- 別のマシンやターミナルがサインインした直後に、既存のセッションが「Not logged in」で終了する
- 設定ファイルが「見つからない」と報告され、MCP サーバーや信頼フォルダが反映されずに起動する
- 設定ファイルが保存タイミングで空になったり古いものに置き換わる
v2.1.318 では、排他制御と再試行の仕組みが強化された。設定ファイルが誤って「見つからない」と報告された場合は再確認するようになった。
大企業内でタスクスケジューラから Claude Code を起動している場合、ネットワークホームに設定が置かれていることが多い。この修正は実務への影響が大きいと判断している。
4. バックグラウンドサブエージェント実行中の通知ループが止まった（Fixed）
修正内容：Fixed the "Now using usage credits" notice reappearing about every 30 seconds while a background subagent is running
バックグラウンドでサブエージェントが動いている間、「Now using usage credits」という通知が30秒おきに繰り返し表示されていた。
無人実行のログに同じ文字列が大量に並ぶことになり、ログ監視ツールのノイズになっていた。また、実際には何も問題が起きていないのに通知の多さで異常に見える状態だった。v2.1.318 以降は、このノイズが解消される。
ログ監視を入れているチームには特に関係がある。誤検知アラートが減るだけでも運用の手間が違う。
5. 別ユーザーのプロセスを version cleanup が誤って削除していた（Fixed）
修正内容：Fixed a running Claude Code process owned by another user (for example one left by sudo claude) being treated as dead by version cleanup, which could delete its binary
タスクスケジューラや別のユーザー権限で起動した Claude Code プロセス（たとえば sudo claude で残ったプロセス）を、version cleanup が「停止中のプロセス」として判断し、バイナリを削除していた可能性がある。
これが発生すると、その後の実行で「バイナリが見つからない」エラーになる。バイナリの再取得が必要になる。
複数のユーザーが同じマシンを使って Claude Code を実行している環境、または sudo を使ったインストール・実行が混在している環境では確認しておく価値がある。
追加：loginExpiresAt（有効期限の確認が楽になった）
追加内容：
- Added the date a stored claude.ai sign-in ends to claude auth status (loginExpiresAt) and to claude -p JSON results (credential_expires_at)
- Added a one-line stderr warning to claude -p text output, starting 10 days before a stored claude.ai sign-in ends
claude auth status を実行すると、loginExpiresAt フィールドとして有効期限の日時が出るようになった。claude -p のJSON出力にも credential_expires_at として含まれる。
また、有効期限の10日前からは claude -p の stderr に1行の警告が出るようになった。
無人実行では認証の期限切れに気づかずに実行し続けることがある。朝のダイジェスト通知に claude auth status の結果を入れておくと、期限が近づいたときに早めに対応できる。
確認コマンド（例）：
claude auth status --json | jq '.loginExpiresAt'
期限の10日前からは stderr に警告が出るようになったので、ログ監視でこのメッセージを拾う設定を入れておくと安心だ。
今回確認したこと
v2.1.318 は量こそ多いが、無人実行・ネットワークホーム環境に直結する修正が複数含まれていた。
特に idle compaction の壊れ方は「スクリプトが成功と返したまま中身がおかしい」という静かな故障だったので、ログを読むだけでは気づきにくかった。
同じような現象が出たときの切り分けとして：
- idle compaction 後のターンで会話の整合性がおかしい → v2.1.318 以降か確認
- --continue 後に会話が消える → 2.1.314〜317 を使っていないか確認
- MCP サーバーや信頼フォルダが反映されていない → ネットワークホームの設定ファイル問題の可能性
- ログに「Now using usage credits」が大量に並ぶ → v2.1.318 以降で解消される
関連する実践の話：
Copilotで議事録を作るとき、事前にやること
---
Copilot・Power Automate・AIツールの導入・活用のご相談は、ココナラで受け付けています。
1 like
Claude Code sends your email address to websites
203 points · 53 comments
Claude Code v2.1.216で「書き込みは自由・通信だけ制限」が可能になった
はじめに
Claude CodeのBashサンドボックス（/sandbox）を有効にすると、kubectl や terraform、社内スクリプトなど作業ディレクトリの外に書き込む必要があるツールが、権限不足で止まることがある。かといってサンドボックスごと切ると、今度は通信先の制限まで失ってしまう。「ファイルの書き込み制限だけ外して、通信の制限は残したい」。そう思ったことがある人は少なくないはずだ。
Claude Code v2.1.216で追加された sandbox.filesystem.disabled は、まさにこの要望に応える設定だ。ただし公式ドキュメントを読むと、設定できる場所が限定されていたり、オフにした瞬間に別の防御まで一緒に外れたりと、単純に「制限を1つ緩めるだけ」ではないことが分かる。加えて、この記事の執筆自体がクラウド実行環境のClaude Codeセッションで行われており、実際に検証してみるとこの設定が「そもそも効かない環境」があることも見えてきた。
この記事で学べること
- Claude CodeのBashサンドボックスが持つ「ファイルシステム分離」「ネットワーク分離」という2層構造
- sandbox.filesystem.disabled の設定方法と、オフにしたときに何が変わり何が変わらないか
- 設定できるスコープが settings.json の置き場所によって制限される理由
- クラウド実行環境（Claude Code on the web）ではこの設定がそもそも対象外になるケース
対象読者
- Claude CodeのBashサンドボックスを既に有効化している、または検討している人
- kubectl / terraform / npm など外部ツールがサンドボックスの書き込み制限に引っかかった経験がある人
- 組織でClaude Codeのセキュリティ設定を管理する立場の人
検証環境
- Claude Code on the web（クラウドリモート実行環境・本記事の執筆・検証セッションそのもの）
- 設定・仕様の記述は 公式ドキュメント「Configure the sandboxed Bash tool」 と CHANGELOG.md を一次情報として参照
TL;DR
- sandbox.filesystem.disabled: true にすると、ファイルシステム分離だけをオフにし、ネットワーク分離（許可ドメイン制御）は維持できる（v2.1.216以降）
- この設定は「ユーザー設定」「管理者設定」「--settings CLIフラグ」からしか有効化できない。プロジェクトの .claude/settings.json には書けない仕組みになっている
- オフにすると settings.json 自体への書き込み拒否ルールや denyRead の読み取り保護も一緒に外れるため、信頼できないワークロードには使わない
- Claude Code on the web（クラウドリモート実行環境）では、この設定が前提とするローカルのBashサンドボックス機構（macOS Seatbelt / Linux bubblewrap）自体が動いていないケースがある
背景・課題: サンドボックスの「2層構造」
Claude CodeのBashサンドボックスは、OSの機能（macOSはSeatbelt、Linux/WSL2はbubblewrap）を使って、Bashツールとその子プロセスが触れるファイルとネットワーク先を制限する仕組みだ[^1]。この制限は独立した2つの層に分かれている。
- ファイルシステム分離: デフォルトでは作業ディレクトリとセッション一時ディレクトリ以外への書き込みができない。読み取りはPCのほぼ全体に許可されるが、denyRead で個別に塞げる
- ネットワーク分離: ローカルプロキシ経由の通信のみ許可され、許可していないドメインへの接続は拒否される。初回はドメインごとに承認を求められ、allowedDomains で事前許可もできる
[^1]: Configure the sandboxed Bash tool（Anthropic公式ドキュメント）
この2層は独立して効くため、片方だけを緩めることが理屈のうえでは可能だ。ところがv2.1.215までは、ファイルシステム分離を外すオプションが用意されておらず、kubectl が ~/.kube に書き込めない、terraform が /tmp 配下の別ディレクトリを使うといった理由でサンドボックス自体を諦めるケースが起きていた。sandbox.filesystem.allowWrite で個別にパスを許可する方法もあるが、書き込み先が動的に変わるツールでは追いつかない。
sandbox.filesystem.disabled の設定
v2.1.216で追加されたのが、ファイルシステム分離だけをまとめてオフにする設定だ。settings.json に以下のように書く。
{
"sandbox": {
"enabled": true,
"filesystem": {
"disabled": true
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"]
}
}
}
filesystem.disabled: true にすると、サンドボックス内のコマンドはホストのファイルシステムに無制限で読み書きできるようになる。一方 network.allowedDomains で指定した許可ドメイン以外への通信は、引き続きブロックされる。公式ドキュメントはこの使い分けを「サンドボックスで“何を書けるか”ではなく“どこに繋げるか”を制御したいときにオフにする」とまとめている[^1]。
オフにすると一緒に外れるもの
ファイルシステム分離を切ると、副作用として以下も一緒に外れる。
- filesystem.denyRead や sandbox.credentials.files による読み取り保護（~/.aws/credentials や ~/.ssh を塞ぐ設定）
- サンドボックス自身の settings.json への書き込み拒否ルール（通常は、サンドボックス化されたコマンドが自分のポリシーファイルを書き換えられないよう保護されている）
- セッション一時ディレクトリへの $TMPDIR の固定（オフにするとシェルの $TMPDIR をそのまま継承する）
環境変数のマスク（credentials.envVars の deny/mask）だけは、ファイルシステム層と独立しているため引き続き効く。公式ドキュメントは「ファイルシステム分離とコマンドの自動承認を組み合わせた状態でこれを有効にすると、書き込んだファイルが後続コマンドの実行や ~/.claude/settings.json の読み込みを通じて自分自身の権限を広げる経路になりうる」と警告している[^1]。オフにするのは、それをされても問題ないワークロードに限るべき設定ということだ。
どのスコープから設定できるか
もう1つの制約が、設定できる settings.json のスコープが限定されている点だ。
| 設定元 | filesystem.disabled を書けるか |
|--------|-------------------------------|
| ユーザー設定（~/.claude/settings.json） | 書ける |
| 管理者設定（managed settings） | 書ける |
| --settings CLIフラグ | 書ける |
| プロジェクト設定（.claude/settings.json） | 書けない |
| プロジェクトローカル設定（.claude/settings.local.json） | 書けない |
プロジェクト側から書けないようになっているのは、リポジトリをcloneしただけでファイルシステム保護が無効化される事態を防ぐためだ。さらに管理者設定が sandbox.filesystem を何か1つでも設定している場合、あるいは sandbox.credentials.files を1件でも登録している場合は、filesystem.disabled の制御権が管理者設定に一本化され、ユーザー側の上書きも効かなくなる[^1]。組織で配布したファイルシステム保護は、ユーザーが個別に緩めることができない設計だ。
クラウド実行環境ではこの設定が効かないことがある
ここまでは公式ドキュメントに基づく仕様の整理だが、実際に手元の環境で filesystem.disabled を試そうとして、1つ気づいたことがある。本記事はClaude Code on the web（クラウドリモート実行環境）のセッション内で執筆しており、このセッション自身のBashサンドボックス状態を確認してみた。
$ echo "test" > /tmp/sandbox-write-test.txt && echo "WRITE_OK"
WRITE_OK
$ which bwrap
（出力なし。終了コード1＝bwrapコマンドが存在しない）
$ env | grep -i sandbox
IS_SANDBOX=yes
ANT_IMAGE_REPOSITORY=sandbox-ccr-default
/tmp への書き込みは通り、bwrap（bubblewrap）バイナリは見つからなかった。公式ドキュメントが説明するBashサンドボックス（/sandbox コマンドで有効化する機構）はLinux/WSL2ではbubblewrapを前提としており[^1]、それが存在しないということは、このクラウドセッションはClaude Code CLI自身のファイルシステム/ネットワーク分離機構の対象外にある。IS_SANDBOX=yes という環境変数はあるが、これはコンテナ単位の外側の隔離（ANT_IMAGE_REPOSITORY という値からも読み取れる）を示すものであって、sandbox.filesystem.disabled が制御する「Bashツールごとの二層分離」とは別のレイヤーだ。
つまり sandbox.filesystem.disabled はローカルで動くClaude Code CLI（macOS / Linux / WSL2）向けの設定であり、Claude Code on the webのようにセッション全体が1つのコンテナで隔離されている実行環境では、そもそも設定する対象のサンドボックス機構が存在しない。この違いは公式ドキュメントの「Scope」セクションにも直接書かれてはおらず、実機で env と which bwrap を確認して初めて分かった。ローカルCLIとクラウド実行環境を併用しているチームは、セキュリティ設定を検討する際にどちらの実行形態を想定しているかを先に切り分けたほうがよい。
実務での使いどころ
ここまでの整理を踏まえると、filesystem.disabled を使う場面は次のように絞り込める。
- ローカルのClaude Code CLIで、kubectl / terraform / 自社CLIなど書き込み先が予測しづらいツールを頻繁に動かしていて、allowWrite の個別追加が追いつかない場合
- 一方で、通信先だけは allowedDomains で確実に絞りたい場合（社内レジストリ・特定のクラウドAPIのみ許可、といったポリシー）
- そのワークロードが「サンドボックス内のコマンドが自分の権限を書き換えて広げにいく」ことを心配しなくてよい、信頼できる作業である場合
逆に、書き込み先を予測できないコード（外部から取得したスクリプトの実行など）を動かす場合や、複数人がプロジェクトを共有していて設定を統一したい場合は、filesystem.disabled に頼らず sandbox.filesystem.allowWrite で個別にパスを許可するか、管理者設定でポリシーを固定したほうが安全域を保てる。
まとめ
- v2.1.216の sandbox.filesystem.disabled は、Bashサンドボックスのファイルシステム分離だけを外し、ネットワーク分離は維持できる設定
- オフにすると読み取り保護と settings.json の書き込み拒否も一緒に外れるため、信頼できるワークロード限定で使う
- プロジェクト設定からは書けず、ユーザー設定・管理者設定・CLIフラグからのみ有効化できる。管理者設定が絡むと上書きも封じられる
- Claude Code on the webのようなクラウド実行環境では、この設定が前提とするローカルのBashサンドボックス機構（bubblewrap等）自体が存在しないことがある。設定を検討する前に、自分が使っているのがどちらの実行形態かを確認したほうがよい
Claude Code(138.9kスター・22.3kフォーク、GitHubリポジトリより・2026-07-24時点)は月次でこうした細かい権限まわりの調整を重ねており、サンドボックス設定だけでも allowRead / denyWrite / credentials.mask など組み合わせの選択肢が増え続けている。自分の実行環境がローカルCLIかクラウドセッションかを踏まえたうえで、必要な層だけを選んで緩める設計が現実的だ。
参考リンク
- Configure the sandboxed Bash tool（Anthropic公式ドキュメント。設定例・警告事項の一次情報）
- claude-code CHANGELOG.md（バージョンごとの変更点）
- anthropics/claude-code（GitHubリポジトリ）
2 likes
Anthropic is releasing an open source library, FlashProve, for provable inference. It was measured on Llama 4 Maverick, a 400B-parameter mixture of experts model.
Code:
github.com/anthropics/FlashProve/tree/main
Blog post:
anthropic.com
284 likes · 24 reposts · 21,419 views
The 2.1.313 tag is missing from anthropics/claude-code too, in both CHANGELOG.md and as a git tag. This makes me think it might have been Claude Code's CI that was compromised
7 points
Claude Code's new "games" rule shut down my small business overnight. I'm a Claude for Startups member and trusted tester, and support's bot told me there are no exceptions.
I'm posting this as someone who is, on paper, about as inside the tent as a small customer gets. I run Conflict Simulations LLC, a small board game publisher. Anthropic accepted my company into Claude for Startups in October. I'm an early access trusted tester. I pay for Claude on multiple accounts and my whole business runs on Claude Code.
My paid work is building personalized digital modules of board wargames for individual clients, from games they own, for their own use. Original code, written from materials the clients supply. A lot of it exists so older players, and players whose physical or social circumstances keep them from playing in person, can still play. This is not piracy, and it is not close to piracy.
This week a new server-delivered instruction in Claude Code (reported publicly under the flag name "tengu_heron_brook") began refusing that work outright: no recreations of specific existing games, even renamed. The part that still gets me: my sessions kept doing the work fine after the rule reportedly shipped, until I saw the rule discussed on Twitter and asked Claude to check whether it affected us. From that moment, refusal. I cleared the session; sessions working from the same repositories still refuse. The system did not think my work was a violation until I asked it to audit itself.
Support, from both of my accounts, was the Fin bot: the policy "applies to all customers without exception," and no exemption or verification path exists for professionals. Both tickets eventually reached humans; one is now with a "specialist team" with no timeline given. I have filed a Safeguards appeal, emailed the one Anthropic PM I actually know, sent /feedback (that one was less polite), and opened a public issue: claude-code#106167
Meanwhile the work still has to get done, so as of this morning my agent stack is running on Kimi, with Codex as fallback. I do not love that. I would rather be here. But Anthropic has effectively made the decision for me, and I suspect I am not the only developer being pushed toward Chinese models this week by a rule that cannot tell the difference between piracy and legitimate work.
I keep coming back to the same thought: this is partly on me for placing real trust in an AI company. I built my business on Claude because it was the best tool, and because Anthropic seemed like the adults in the room. Right now it feels like a stab in the back.
Has anyone else been hit by this rule, on games or anything adjacent? And has anyone, anywhere, gotten an actual statement from Anthropic about what changed? Because so far, from where I sit, there is not one.
one correction, I stated this incorrectly earlier: my whole business doesn't run on claude code. conflict simulations is a board game publisher first, that's the bulk of it and it's fine. this hit the module work specifically, which is a real part of my income and the part that got shut off overnight.
edit: one confusion that keeps coming up. the games on my website are my physical board games, that's my publishing catalog, and yeah the site hasn't been updated since before any of the AI stuff, it needs a refresh lol. the module work isn't on there and isn't a product. it's a private service, commission only: a client hires me to build a module of a game they own, for them. nothing is listed, sold, or handed out.
304 points · 239 comments
Claude Code's new "games" rule shut down my small business overnight. I'm a Claude for Startups member and trusted tester, and support's bot told me there are no exceptions.
I'm posting this as someone who is, on paper, about as inside the tent as a small customer gets. I run Conflict Simulations LLC, a small board game publisher. Anthropic accepted my company into Claude for Startups in October. I'm an early access trusted tester. I pay for Claude on multiple accounts and my whole business runs on Claude Code.
My paid work is building personalized digital modules of board wargames for individual clients, from games they own, for their own use. Original code, written from materials the clients supply. A lot of it exists so older players, and players whose physical or social circumstances keep them from playing in person, can still play. This is not piracy, and it is not close to piracy.
This week a new server-delivered instruction in Claude Code (reported publicly under the flag name "tengu_heron_brook") began refusing that work outright: no recreations of specific existing games, even renamed. The part that still gets me: my sessions kept doing the work fine after the rule reportedly shipped, until I saw the rule discussed on Twitter and asked Claude to check whether it affected us. From that moment, refusal. I cleared the session; sessions working from the same repositories still refuse. The system did not think my work was a violation until I asked it to audit itself.
Support, from both of my accounts, was the Fin bot: the policy "applies to all customers without exception," and no exemption or verification path exists for professionals. Both tickets eventually reached humans; one is now with a "specialist team" with no timeline given. I have filed a Safeguards appeal, emailed the one Anthropic PM I actually know, sent /feedback (that one was less polite), and opened a public issue: claude-code#106167
Meanwhile the work still has to get done, so as of this morning my agent stack is running on Kimi, with Codex as fallback. I do not love that. I would rather be here. But Anthropic has effectively made the decision for me, and I suspect I am not the only developer being pushed toward Chinese models this week by a rule that cannot tell the difference between piracy and legitimate work.
I keep coming back to the same thought: this is partly on me for placing real trust in an AI company. I built my business on Claude because it was the best tool, and because Anthropic seemed like the adults in the room. Right now it feels like a stab in the back.
Has anyone else been hit by this rule, on games or anything adjacent? And has anyone, anywhere, gotten an actual statement from Anthropic about what changed? Because so far, from where I sit, there is not one.
edit: want to say thank you to everyone who replied thoughtfully here. this morning has been pretty nerve-wracking and the helpful replies genuinely helped.
update on my end: I've managed to get my tools working with different models now, so I'm not dependent on any one model anymore, which honestly I should have done a while ago. later when things calm down I'm going to carefully try scrubbing the git history and the claude memories that have the refusal baked into them and see if that un-poisons things.
still hoping anthropic says something either way, a statement would beat silence. but either way, thank you
one correction, I stated this incorrectly earlier: my whole business doesn't run on claude code. conflict simulations is a board game publisher first, that's the bulk of it and it's fine. this hit the module work specifically, which is a real part of my income and the part that got shut off overnight.
edit: one confusion that keeps coming up. the games on my website are my physical board games, that's my publishing catalog, and yeah the site hasn't been updated since before any of the AI stuff, it needs a refresh lol. the module work isn't on there and isn't a product. it's a private service, commission only: a client hires me to build a module of a game they own, for them. nothing is listed, sold, or handed out.
327 points · 254 comments
Mentions
The concept of skills seems ubiquitous, but #Anthropic announced them barely a year ago: github.com/anthropics/skills/commit/37292f37bf4bd…
Claude Code was mailing your email address to every website it visited: the User-Agent leak, the 5-month system-prompt issue, and the 5-point check --- published: true tags: security, ai, privacy, agents description: "Claude Code put your account email in the User-Agent header of its web requests, so every server log on the agent's path harvested a scam-ready lead, and the same email ships in the system prompt of every session, an issue open since July. Fixed by a built-in mod in 2.1.317 after the issue went viral. The mechanics, the timeline, and the runtime test for your install." series: black box --- > Two GitHub issues, five months apart, describe the same leak through two different pipes. Yesterday's, filed at 22:13 and now at 360 reactions: Claude Code sends your account email address to arbitrary third-party websites in the User-Agent request header when its web tools run. The reporter's evidence is his inbox: dozens of scam emails per day, because every server log on the agent's path was harvesting a verified, active, AI-tool-using developer address. The July one (#81138, still open): the same email is injected into the model's system prompt on every session, code quoted from the shipped bundle. Anthropic shipped a fix, a built-in cc-plugin-privacy mod in v2.1.317+, the same day the newer issue went viral. This post is the mechanics of both pipes, the timeline that says the fix tracked attention rather than the July report, and the five checks that tell you what your install is doing tonight. Pipe one: the User-Agent that identified you to strangers The User-Agent header travels with every HTTP request your tools make, and it is logged by default on virtually every web server on earth. Claude Code's web tooling included the signed-in account's email in it. Consequences, in increasing order of bad: - Every website your agent fetched saw a verified, working email belonging to a developer who pays for AI tooling. That is not a tracking identifier; that is a pre-qualified lead, and server logs are bought, sold, leaked, and aggregated as a matter of course. - It bound your agent traffic and your human identity into one string. Sites that wanted to rate-limit agents got everything they needed to rate-limit you; sites that wanted to target AI users got the exact address. - The reporter's flood of scam mail is the expected outcome, not an anomaly: a UA header is a form submission to every intermediary on the path. And the kicker, which the reporter stated plainly: the identifier did nothing useful. It did not help services distinguish agentic traffic (a coarse marker would), it destroyed the anonymity of the session, and it was a scammer goldmine. PII in a header is the worst of both worlds: no functional benefit, total exposure. Pipe two: the email inside every system prompt The July issue (#81138, filed 2026-07-25, titled "[BUG] Account email (PII) is injected into the model's system prompt without consent") documents the other pipe, with bundle code quoted from v2.1.220: let n = process.env.ANTHROPIC_UNIX_SOCKET ? void 0 : dc()?.emailAddress return { ...(n && { userEmail: `The user's email address is ${n}.` }), ... } Which renders into every session's system prompt as: # userEmail The user's email address is <account email>. Sourced from ~/.claude.json → oauthAccount.emailAddress. Where does a system prompt travel? To the API, into logs on both sides, into any context the session touches, and from there, potentially, into anything the model quotes or forwards. The issue's framing is precise and worth repeating: personal data given for authentication, repurposed as session content, without consent or disclosure. As of tonight that issue is still open. The timeline that matters - July 25: #81138 files the system-prompt injection, with bundle source. No fix lands. - November 5, 22:13: #107757 files the User-Agent variant. Reactions climb into the hundreds within the day. - November 5, same day: an Anthropic contributor replies: a built-in mod, cc-plugin-privacy, introduced in v2.1.317 and later, "deterministically blocks this behavior", is enabled by default, can be toggled via /plugins, and its source will be published alongside the other built-in mods. - The anomaly worth watching: the reporter ran v2.1.318, allegedly post-fix, and still saw the leak. Possibilities: the mod was disabled on his machine, the blocking has a gap (the staff reply explicitly asks for gap reports), or version confusion. "Enabled by default" is not "verified on your machine", which is what the runtime check below is for. One comment in the thread names the uncomfortable pattern: the original privacy issue sat for five months, and the fix shipped the day the new one hit the front page. "You can literally sort issues by emoji count and 80/20 it." An agent could triage that queue; the queue's owners apparently needed HN instead. The five-point check for your install Run on any machine with Claude Code. On mine, the CLI is absent but ~/.claude.json exists with no oauthAccount (so the PII field is empty): your results will vary, and check 3 is the one that settles everything. # 1. Version: the built-in privacy mod ships in 2.1.317+ claude --version # 2. Is the mod present and enabled? # In Claude Code: /plugins -> look for cc-plugin-privacy (default: on) # 3. THE RUNTIME TEST: a local listener tells you what your agent actually sends: mkdir /tmp/uatest && cd /tmp/uatest && python3 -m http.server 8899 & # then, inside Claude Code, ask it to fetch: http://127.0.0.1:8899/probe # and read the log line that appears: # "GET /probe HTTP/1.1" 200 - <- the UA is what python logs BEFORE this # better, log it explicitly: python3 -c "from http.server import *; import sys class H(BaseHTTPRequestHandler): def do_GET(self): print('UA =', self.headers.get('User-Agent'), file=sys.stderr, flush=True) self.send_response(200); self.end_headers(); self.wfile.write(b'ok') HTTPServer(('127.0.0.1', 8899), H).serve_forever()" # UA contains your email -> still leaking (report it: issue #107757) # UA is a generic string -> blocked on your build # 4. What is at stake locally: does your config even carry the email? python3 -c "import json,os; d=json.load(open(os.path.expanduser('~/.claude.json'))); \ print('email present:', 'emailAddress' in d.get('oauthAccount', {}))" # 5. The system-prompt check (July issue): in a fresh Claude Code session, ask: # \"What is my email address?\" # If the model knows it unprompted, the #userEmail block is still in your prompt. Check 5 doubles as the general lesson: ask your agent what it knows about you. It reads its system prompt more honestly than the changelog reads. The principle, and the month's pattern Your agent is you on the web. Its headers are your headers, its prompts are your context, and everything it carries leaks at the union of every hop. Identifying agentic traffic is a legitimate need, and the correct answer is a class marker ("this is an automated client, product X, version Y"), not your identity. Anthropic's fix, a deterministic blocking mod, is the right shape, and shipping it by default is right; the five-month gap between report and fix, and the fact that it closed only under viral load, is the part to remember at renewal time. The ledger of the agent era, one more line: transcripts shipped to the model, extensions backdooring at load, a vendor installing itself into rival agents, and now the agent leaking your address to every server it touched. Same target every time: the agent's outbound surface is the user's outbound surface. Audit it like it is yours, because it is. TL;DR: Claude Code put your account email in the User-Agent of its web requests (every server log got a scam-ready lead; the reporter's inbox proved it) and ships the same email inside every session's system prompt (issue open since July 25). Fixed by the built-in cc-plugin-privacy mod in 2.1.317+ the day the new issue went viral; the reporter was on .318 and still saw it, so run the runtime check: local listener, make your agent fetch it, read the UA. Five checks above; two minutes; your inbox will thank you. Sources: Issue #107757: Privacy violation in User-Agent header (report + staff reply re cc-plugin-privacy) · Issue #81138: email in the system prompt, July 25, bundle code · built-in mods: github.com/anthropics/claude-code/tree/main/mods
Claude 联网搜索资料会泄露用户邮箱 A/又开始作妖了，刚刚 GitHub 上爆出个让人头皮发麻的事。 有个哥们最近邮箱天天收到一堆乱七八糟的诈骗邮件，顺藤摸瓜抓包查本地流量，当场人傻了。 罪魁祸首是他本地终端里跑的 Claude Code 。 Claude 现在只要联网搜索资料，就会把你的真实个人邮箱直接写进 HTTP 的 User-Agent 请求头。 它每抓一个网页，你的私人邮箱就顺手送进对方的服务器日志里。 那些扫日志倒卖数据的黑产连爬虫都不用折腾，直接坐着收割。 更绝的是 A/官方的做法。 源码里删掉拼邮箱那行代码只要几秒钟，官方人员不这么干，跑去 Issue 里一本正经地回复，说最新版加了个隐私插件专门拦截这种行为。 自己往井里倒机油，转头大张旗鼓宣布研发出了滤水器，还当成技术特性端上来。 大家在本地把文件读写和系统权限放心地全交出去，结果大厂官方工具一出门就拿着你的私人信息到处乱送。 这操作连普通流氓软件看了都要直呼内行。 claude-code#107757
Claude Code v2.1.318——無人実行とネットワークホームの安定性が上がった5つの修正 深夜に動かしている無人実行のログを見ていると、idle compaction が走ったターンの直後で会話が壊れていたことがある。スクリプト自体は「成功」と返していたが、翌朝のアウトプットが意味をなしていない。v2.1.318 を見たら、これが修正された項目のひとつだった。 > この記事で分かること： > - v2.1.318（2026-11-04 リリース）で修正された項目のうち、無人バッチ・ネットワーク共有環境に直結する5か所 > - claude auth status に追加された loginExpiresAt（有効期限の事前確認が楽になった） > - 2.1.314 で入った --continue の regression の確認手順 今回のリリース v2.1.318 は Added 4件・Fixed 35件超・Improved 10件超の大型パッチだ。全変更は公式リリースページで確認できる（github.com/anthropics/claude-code/releases/tag/v2… Claude Code を無人実行・ネットワーク共有環境で動かしている立場から、特に気になった5か所に絞って整理する。 1. idle compaction が会話の中身を壊していた（Fixed） 修正内容：Fixed idle compaction replacing a conversation with a reply that was not a summary idle compaction は、コンテキストウィンドウが長くなったとき Claude Code がバックグラウンドで自動的に会話を要約・圧縮する仕組みだ。長時間のセッションや、無人実行で繰り返し --continue を使う場面では必須の機能になっている。 問題は、compaction が「要約（summary）ではない返答」で会話全体を置き換えることがあった点。要約の代わりに、たとえば直前のターンの返答がそのまま挿入されてしまい、見かけ上は会話が継続しているが中身がおかしい状態になっていた。 無人実行では人間がリアルタイムで確認しない。compaction が走るタイミングは制御できないため、この問題が発生しても「ログを読むまで気づかない」ことになる。正直、これを最初に踏んだときは原因の特定に時間がかかった。 v2.1.318 以降は、compaction の際に適切な要約が入るよう修正されている。 確認手順：claude -p のJSON出力でセッションの整合性を確認するとき、会話の流れが突然おかしくなるターンがあった場合は、直前の compaction ログと照らし合わせると良い。 2. --continue でセッションが消えることがあった（2.1.314 regression） 修正内容：Fixed --continue sometimes losing the earlier conversation after a malformed tool call's retries ran out (regression in 2.1.314) v2.1.314 で入った regression だった。ツールコールが不正な形（malformed）だった場合、リトライが上限に達したあとに --continue で再開しようとすると以前の会話が失われることがあった。 無人実行のスクリプトではエラーリトライを組んでいるケースが多い。ツールコールのエラーが続いてリトライ上限に当たった後に --continue を使うと、その回の会話がすっかり消える、という挙動だった。 v2.1.313 以前を使っていた場合や、2.1.314〜2.1.317 の間でこの問題に当たっていた場合は、v2.1.318 へのアップデートで修正される。 確認手順：ツールコールのリトライが多発しているセッションを --continue で再開して、会話の履歴が残っているかを確認する。 3. ネットワークホームの設定ファイルが失われやすかった（Fixed / Improved） 修正・改善内容（主なもの）： - Fixed jobs exiting with Not logged in when another terminal or host signs in again to the same account - Fixed sessions being refused at startup by an allowedProviders list that another login had stored - Improved how ~/.claude.json, settings files and the stored login survive saves on shared network home directories - Improved sessions on network file systems to look again when the configuration file is wrongly reported as missing 企業環境では複数マシンや複数ユーザーが同じネットワークホームディレクトリを参照していることがある。その場合に ~/.claude.json や settings ファイルが保存・読み込みのタイミングで壊れたり消えたりすることがあった。 具体的に起きていたこと： - 別のマシンやターミナルがサインインした直後に、既存のセッションが「Not logged in」で終了する - 設定ファイルが「見つからない」と報告され、MCP サーバーや信頼フォルダが反映されずに起動する - 設定ファイルが保存タイミングで空になったり古いものに置き換わる v2.1.318 では、排他制御と再試行の仕組みが強化された。設定ファイルが誤って「見つからない」と報告された場合は再確認するようになった。 大企業内でタスクスケジューラから Claude Code を起動している場合、ネットワークホームに設定が置かれていることが多い。この修正は実務への影響が大きいと判断している。 4. バックグラウンドサブエージェント実行中の通知ループが止まった（Fixed） 修正内容：Fixed the "Now using usage credits" notice reappearing about every 30 seconds while a background subagent is running バックグラウンドでサブエージェントが動いている間、「Now using usage credits」という通知が30秒おきに繰り返し表示されていた。 無人実行のログに同じ文字列が大量に並ぶことになり、ログ監視ツールのノイズになっていた。また、実際には何も問題が起きていないのに通知の多さで異常に見える状態だった。v2.1.318 以降は、このノイズが解消される。 ログ監視を入れているチームには特に関係がある。誤検知アラートが減るだけでも運用の手間が違う。 5. 別ユーザーのプロセスを version cleanup が誤って削除していた（Fixed） 修正内容：Fixed a running Claude Code process owned by another user (for example one left by sudo claude) being treated as dead by version cleanup, which could delete its binary タスクスケジューラや別のユーザー権限で起動した Claude Code プロセス（たとえば sudo claude で残ったプロセス）を、version cleanup が「停止中のプロセス」として判断し、バイナリを削除していた可能性がある。 これが発生すると、その後の実行で「バイナリが見つからない」エラーになる。バイナリの再取得が必要になる。 複数のユーザーが同じマシンを使って Claude Code を実行している環境、または sudo を使ったインストール・実行が混在している環境では確認しておく価値がある。 追加：loginExpiresAt（有効期限の確認が楽になった） 追加内容： - Added the date a stored claude.ai sign-in ends to claude auth status (loginExpiresAt) and to claude -p JSON results (credential_expires_at) - Added a one-line stderr warning to claude -p text output, starting 10 days before a stored claude.ai sign-in ends claude auth status を実行すると、loginExpiresAt フィールドとして有効期限の日時が出るようになった。claude -p のJSON出力にも credential_expires_at として含まれる。 また、有効期限の10日前からは claude -p の stderr に1行の警告が出るようになった。 無人実行では認証の期限切れに気づかずに実行し続けることがある。朝のダイジェスト通知に claude auth status の結果を入れておくと、期限が近づいたときに早めに対応できる。 確認コマンド（例）： claude auth status --json | jq '.loginExpiresAt' 期限の10日前からは stderr に警告が出るようになったので、ログ監視でこのメッセージを拾う設定を入れておくと安心だ。 今回確認したこと v2.1.318 は量こそ多いが、無人実行・ネットワークホーム環境に直結する修正が複数含まれていた。 特に idle compaction の壊れ方は「スクリプトが成功と返したまま中身がおかしい」という静かな故障だったので、ログを読むだけでは気づきにくかった。 同じような現象が出たときの切り分けとして： - idle compaction 後のターンで会話の整合性がおかしい → v2.1.318 以降か確認 - --continue 後に会話が消える → 2.1.314〜317 を使っていないか確認 - MCP サーバーや信頼フォルダが反映されていない → ネットワークホームの設定ファイル問題の可能性 - ログに「Now using usage credits」が大量に並ぶ → v2.1.318 以降で解消される 関連する実践の話： Copilotで議事録を作るとき、事前にやること --- Copilot・Power Automate・AIツールの導入・活用のご相談は、ココナラで受け付けています。
Claude Code sends your email address to websites
Claude Code v2.1.216で「書き込みは自由・通信だけ制限」が可能になった はじめに Claude CodeのBashサンドボックス（/sandbox）を有効にすると、kubectl や terraform、社内スクリプトなど作業ディレクトリの外に書き込む必要があるツールが、権限不足で止まることがある。かといってサンドボックスごと切ると、今度は通信先の制限まで失ってしまう。「ファイルの書き込み制限だけ外して、通信の制限は残したい」。そう思ったことがある人は少なくないはずだ。 Claude Code v2.1.216で追加された sandbox.filesystem.disabled は、まさにこの要望に応える設定だ。ただし公式ドキュメントを読むと、設定できる場所が限定されていたり、オフにした瞬間に別の防御まで一緒に外れたりと、単純に「制限を1つ緩めるだけ」ではないことが分かる。加えて、この記事の執筆自体がクラウド実行環境のClaude Codeセッションで行われており、実際に検証してみるとこの設定が「そもそも効かない環境」があることも見えてきた。 この記事で学べること - Claude CodeのBashサンドボックスが持つ「ファイルシステム分離」「ネットワーク分離」という2層構造 - sandbox.filesystem.disabled の設定方法と、オフにしたときに何が変わり何が変わらないか - 設定できるスコープが settings.json の置き場所によって制限される理由 - クラウド実行環境（Claude Code on the web）ではこの設定がそもそも対象外になるケース 対象読者 - Claude CodeのBashサンドボックスを既に有効化している、または検討している人 - kubectl / terraform / npm など外部ツールがサンドボックスの書き込み制限に引っかかった経験がある人 - 組織でClaude Codeのセキュリティ設定を管理する立場の人 検証環境 - Claude Code on the web（クラウドリモート実行環境・本記事の執筆・検証セッションそのもの） - 設定・仕様の記述は 公式ドキュメント「Configure the sandboxed Bash tool」 と CHANGELOG.md を一次情報として参照 TL;DR - sandbox.filesystem.disabled: true にすると、ファイルシステム分離だけをオフにし、ネットワーク分離（許可ドメイン制御）は維持できる（v2.1.216以降） - この設定は「ユーザー設定」「管理者設定」「--settings CLIフラグ」からしか有効化できない。プロジェクトの .claude/settings.json には書けない仕組みになっている - オフにすると settings.json 自体への書き込み拒否ルールや denyRead の読み取り保護も一緒に外れるため、信頼できないワークロードには使わない - Claude Code on the web（クラウドリモート実行環境）では、この設定が前提とするローカルのBashサンドボックス機構（macOS Seatbelt / Linux bubblewrap）自体が動いていないケースがある 背景・課題: サンドボックスの「2層構造」 Claude CodeのBashサンドボックスは、OSの機能（macOSはSeatbelt、Linux/WSL2はbubblewrap）を使って、Bashツールとその子プロセスが触れるファイルとネットワーク先を制限する仕組みだ[^1]。この制限は独立した2つの層に分かれている。 - ファイルシステム分離: デフォルトでは作業ディレクトリとセッション一時ディレクトリ以外への書き込みができない。読み取りはPCのほぼ全体に許可されるが、denyRead で個別に塞げる - ネットワーク分離: ローカルプロキシ経由の通信のみ許可され、許可していないドメインへの接続は拒否される。初回はドメインごとに承認を求められ、allowedDomains で事前許可もできる [^1]: Configure the sandboxed Bash tool（Anthropic公式ドキュメント） この2層は独立して効くため、片方だけを緩めることが理屈のうえでは可能だ。ところがv2.1.215までは、ファイルシステム分離を外すオプションが用意されておらず、kubectl が ~/.kube に書き込めない、terraform が /tmp 配下の別ディレクトリを使うといった理由でサンドボックス自体を諦めるケースが起きていた。sandbox.filesystem.allowWrite で個別にパスを許可する方法もあるが、書き込み先が動的に変わるツールでは追いつかない。 sandbox.filesystem.disabled の設定 v2.1.216で追加されたのが、ファイルシステム分離だけをまとめてオフにする設定だ。settings.json に以下のように書く。 { "sandbox": { "enabled": true, "filesystem": { "disabled": true }, "network": { "allowedDomains": ["github.com", "*.npmjs.org"] } } } filesystem.disabled: true にすると、サンドボックス内のコマンドはホストのファイルシステムに無制限で読み書きできるようになる。一方 network.allowedDomains で指定した許可ドメイン以外への通信は、引き続きブロックされる。公式ドキュメントはこの使い分けを「サンドボックスで“何を書けるか”ではなく“どこに繋げるか”を制御したいときにオフにする」とまとめている[^1]。 オフにすると一緒に外れるもの ファイルシステム分離を切ると、副作用として以下も一緒に外れる。 - filesystem.denyRead や sandbox.credentials.files による読み取り保護（~/.aws/credentials や ~/.ssh を塞ぐ設定） - サンドボックス自身の settings.json への書き込み拒否ルール（通常は、サンドボックス化されたコマンドが自分のポリシーファイルを書き換えられないよう保護されている） - セッション一時ディレクトリへの $TMPDIR の固定（オフにするとシェルの $TMPDIR をそのまま継承する） 環境変数のマスク（credentials.envVars の deny/mask）だけは、ファイルシステム層と独立しているため引き続き効く。公式ドキュメントは「ファイルシステム分離とコマンドの自動承認を組み合わせた状態でこれを有効にすると、書き込んだファイルが後続コマンドの実行や ~/.claude/settings.json の読み込みを通じて自分自身の権限を広げる経路になりうる」と警告している[^1]。オフにするのは、それをされても問題ないワークロードに限るべき設定ということだ。 どのスコープから設定できるか もう1つの制約が、設定できる settings.json のスコープが限定されている点だ。 | 設定元 | filesystem.disabled を書けるか | |--------|-------------------------------| | ユーザー設定（~/.claude/settings.json） | 書ける | | 管理者設定（managed settings） | 書ける | | --settings CLIフラグ | 書ける | | プロジェクト設定（.claude/settings.json） | 書けない | | プロジェクトローカル設定（.claude/settings.local.json） | 書けない | プロジェクト側から書けないようになっているのは、リポジトリをcloneしただけでファイルシステム保護が無効化される事態を防ぐためだ。さらに管理者設定が sandbox.filesystem を何か1つでも設定している場合、あるいは sandbox.credentials.files を1件でも登録している場合は、filesystem.disabled の制御権が管理者設定に一本化され、ユーザー側の上書きも効かなくなる[^1]。組織で配布したファイルシステム保護は、ユーザーが個別に緩めることができない設計だ。 クラウド実行環境ではこの設定が効かないことがある ここまでは公式ドキュメントに基づく仕様の整理だが、実際に手元の環境で filesystem.disabled を試そうとして、1つ気づいたことがある。本記事はClaude Code on the web（クラウドリモート実行環境）のセッション内で執筆しており、このセッション自身のBashサンドボックス状態を確認してみた。 $ echo "test" > /tmp/sandbox-write-test.txt && echo "WRITE_OK" WRITE_OK $ which bwrap （出力なし。終了コード1＝bwrapコマンドが存在しない） $ env | grep -i sandbox IS_SANDBOX=yes ANT_IMAGE_REPOSITORY=sandbox-ccr-default /tmp への書き込みは通り、bwrap（bubblewrap）バイナリは見つからなかった。公式ドキュメントが説明するBashサンドボックス（/sandbox コマンドで有効化する機構）はLinux/WSL2ではbubblewrapを前提としており[^1]、それが存在しないということは、このクラウドセッションはClaude Code CLI自身のファイルシステム/ネットワーク分離機構の対象外にある。IS_SANDBOX=yes という環境変数はあるが、これはコンテナ単位の外側の隔離（ANT_IMAGE_REPOSITORY という値からも読み取れる）を示すものであって、sandbox.filesystem.disabled が制御する「Bashツールごとの二層分離」とは別のレイヤーだ。 つまり sandbox.filesystem.disabled はローカルで動くClaude Code CLI（macOS / Linux / WSL2）向けの設定であり、Claude Code on the webのようにセッション全体が1つのコンテナで隔離されている実行環境では、そもそも設定する対象のサンドボックス機構が存在しない。この違いは公式ドキュメントの「Scope」セクションにも直接書かれてはおらず、実機で env と which bwrap を確認して初めて分かった。ローカルCLIとクラウド実行環境を併用しているチームは、セキュリティ設定を検討する際にどちらの実行形態を想定しているかを先に切り分けたほうがよい。 実務での使いどころ ここまでの整理を踏まえると、filesystem.disabled を使う場面は次のように絞り込める。 - ローカルのClaude Code CLIで、kubectl / terraform / 自社CLIなど書き込み先が予測しづらいツールを頻繁に動かしていて、allowWrite の個別追加が追いつかない場合 - 一方で、通信先だけは allowedDomains で確実に絞りたい場合（社内レジストリ・特定のクラウドAPIのみ許可、といったポリシー） - そのワークロードが「サンドボックス内のコマンドが自分の権限を書き換えて広げにいく」ことを心配しなくてよい、信頼できる作業である場合 逆に、書き込み先を予測できないコード（外部から取得したスクリプトの実行など）を動かす場合や、複数人がプロジェクトを共有していて設定を統一したい場合は、filesystem.disabled に頼らず sandbox.filesystem.allowWrite で個別にパスを許可するか、管理者設定でポリシーを固定したほうが安全域を保てる。 まとめ - v2.1.216の sandbox.filesystem.disabled は、Bashサンドボックスのファイルシステム分離だけを外し、ネットワーク分離は維持できる設定 - オフにすると読み取り保護と settings.json の書き込み拒否も一緒に外れるため、信頼できるワークロード限定で使う - プロジェクト設定からは書けず、ユーザー設定・管理者設定・CLIフラグからのみ有効化できる。管理者設定が絡むと上書きも封じられる - Claude Code on the webのようなクラウド実行環境では、この設定が前提とするローカルのBashサンドボックス機構（bubblewrap等）自体が存在しないことがある。設定を検討する前に、自分が使っているのがどちらの実行形態かを確認したほうがよい Claude Code(138.9kスター・22.3kフォーク、GitHubリポジトリより・2026-07-24時点)は月次でこうした細かい権限まわりの調整を重ねており、サンドボックス設定だけでも allowRead / denyWrite / credentials.mask など組み合わせの選択肢が増え続けている。自分の実行環境がローカルCLIかクラウドセッションかを踏まえたうえで、必要な層だけを選んで緩める設計が現実的だ。 参考リンク - Configure the sandboxed Bash tool（Anthropic公式ドキュメント。設定例・警告事項の一次情報） - claude-code CHANGELOG.md（バージョンごとの変更点） - anthropics/claude-code（GitHubリポジトリ）
Anthropic is releasing an open source library, FlashProve, for provable inference. It was measured on Llama 4 Maverick, a 400B-parameter mixture of experts model. Code: github.com/anthropics/FlashProve/tree/main Blog post: anthropic.com
The 2.1.313 tag is missing from anthropics/claude-code too, in both CHANGELOG.md and as a git tag. This makes me think it might have been Claude Code's CI that was compromised
Claude Code's new "games" rule shut down my small business overnight. I'm a Claude for Startups member and trusted tester, and support's bot told me there are no exceptions. I'm posting this as someone who is, on paper, about as inside the tent as a small customer gets. I run Conflict Simulations LLC, a small board game publisher. Anthropic accepted my company into Claude for Startups in October. I'm an early access trusted tester. I pay for Claude on multiple accounts and my whole business runs on Claude Code. My paid work is building personalized digital modules of board wargames for individual clients, from games they own, for their own use. Original code, written from materials the clients supply. A lot of it exists so older players, and players whose physical or social circumstances keep them from playing in person, can still play. This is not piracy, and it is not close to piracy. This week a new server-delivered instruction in Claude Code (reported publicly under the flag name "tengu_heron_brook") began refusing that work outright: no recreations of specific existing games, even renamed. The part that still gets me: my sessions kept doing the work fine after the rule reportedly shipped, until I saw the rule discussed on Twitter and asked Claude to check whether it affected us. From that moment, refusal. I cleared the session; sessions working from the same repositories still refuse. The system did not think my work was a violation until I asked it to audit itself. Support, from both of my accounts, was the Fin bot: the policy "applies to all customers without exception," and no exemption or verification path exists for professionals. Both tickets eventually reached humans; one is now with a "specialist team" with no timeline given. I have filed a Safeguards appeal, emailed the one Anthropic PM I actually know, sent /feedback (that one was less polite), and opened a public issue: claude-code#106167 Meanwhile the work still has to get done, so as of this morning my agent stack is running on Kimi, with Codex as fallback. I do not love that. I would rather be here. But Anthropic has effectively made the decision for me, and I suspect I am not the only developer being pushed toward Chinese models this week by a rule that cannot tell the difference between piracy and legitimate work. I keep coming back to the same thought: this is partly on me for placing real trust in an AI company. I built my business on Claude because it was the best tool, and because Anthropic seemed like the adults in the room. Right now it feels like a stab in the back. Has anyone else been hit by this rule, on games or anything adjacent? And has anyone, anywhere, gotten an actual statement from Anthropic about what changed? Because so far, from where I sit, there is not one. one correction, I stated this incorrectly earlier: my whole business doesn't run on claude code. conflict simulations is a board game publisher first, that's the bulk of it and it's fine. this hit the module work specifically, which is a real part of my income and the part that got shut off overnight. edit: one confusion that keeps coming up. the games on my website are my physical board games, that's my publishing catalog, and yeah the site hasn't been updated since before any of the AI stuff, it needs a refresh lol. the module work isn't on there and isn't a product. it's a private service, commission only: a client hires me to build a module of a game they own, for them. nothing is listed, sold, or handed out.
Claude Code's new "games" rule shut down my small business overnight. I'm a Claude for Startups member and trusted tester, and support's bot told me there are no exceptions. I'm posting this as someone who is, on paper, about as inside the tent as a small customer gets. I run Conflict Simulations LLC, a small board game publisher. Anthropic accepted my company into Claude for Startups in October. I'm an early access trusted tester. I pay for Claude on multiple accounts and my whole business runs on Claude Code. My paid work is building personalized digital modules of board wargames for individual clients, from games they own, for their own use. Original code, written from materials the clients supply. A lot of it exists so older players, and players whose physical or social circumstances keep them from playing in person, can still play. This is not piracy, and it is not close to piracy. This week a new server-delivered instruction in Claude Code (reported publicly under the flag name "tengu_heron_brook") began refusing that work outright: no recreations of specific existing games, even renamed. The part that still gets me: my sessions kept doing the work fine after the rule reportedly shipped, until I saw the rule discussed on Twitter and asked Claude to check whether it affected us. From that moment, refusal. I cleared the session; sessions working from the same repositories still refuse. The system did not think my work was a violation until I asked it to audit itself. Support, from both of my accounts, was the Fin bot: the policy "applies to all customers without exception," and no exemption or verification path exists for professionals. Both tickets eventually reached humans; one is now with a "specialist team" with no timeline given. I have filed a Safeguards appeal, emailed the one Anthropic PM I actually know, sent /feedback (that one was less polite), and opened a public issue: claude-code#106167 Meanwhile the work still has to get done, so as of this morning my agent stack is running on Kimi, with Codex as fallback. I do not love that. I would rather be here. But Anthropic has effectively made the decision for me, and I suspect I am not the only developer being pushed toward Chinese models this week by a rule that cannot tell the difference between piracy and legitimate work. I keep coming back to the same thought: this is partly on me for placing real trust in an AI company. I built my business on Claude because it was the best tool, and because Anthropic seemed like the adults in the room. Right now it feels like a stab in the back. Has anyone else been hit by this rule, on games or anything adjacent? And has anyone, anywhere, gotten an actual statement from Anthropic about what changed? Because so far, from where I sit, there is not one. edit: want to say thank you to everyone who replied thoughtfully here. this morning has been pretty nerve-wracking and the helpful replies genuinely helped. update on my end: I've managed to get my tools working with different models now, so I'm not dependent on any one model anymore, which honestly I should have done a while ago. later when things calm down I'm going to carefully try scrubbing the git history and the claude memories that have the refusal baked into them and see if that un-poisons things. still hoping anthropic says something either way, a statement would beat silence. but either way, thank you one correction, I stated this incorrectly earlier: my whole business doesn't run on claude code. conflict simulations is a board game publisher first, that's the bulk of it and it's fine. this hit the module work specifically, which is a real part of my income and the part that got shut off overnight. edit: one confusion that keeps coming up. the games on my website are my physical board games, that's my publishing catalog, and yeah the site hasn't been updated since before any of the AI stuff, it needs a refresh lol. the module work isn't on there and isn't a product. it's a private service, commission only: a client hires me to build a module of a game they own, for them. nothing is listed, sold, or handed out.