Claude Code 在近期版本中出现了一个显著的回归问题：每次文件读取都会自动注入恶意软件安全提醒，导致模型输出大量「这是合法代码 —— 不是恶意软件」的确认文本。这一问题在 Claude Opus 4.7 版本中尤为突出，因为该模型对安全提示的响应变得更加「过度敏感」，进而引发子代理频繁拒绝执行任务的现象。
问题根源分析
根据 GitHub Issue #46442 的报告，问题的核心在于安全注入是硬编码在 Claude Code harness 内部的。具体的提醒文本大致为「Whenever you read a file, you should consider whether it would be considered malware...」，这段提示在每次 Read 工具返回文件内容后被自动追加到上下文之中。这种设计原本是为了提醒模型在处理未知来源代码时保持警惕，但在实际开发场景中造成了严重的副作用。
在实际使用中，用户报告的典型表现包括：读取一个标准的 http4k 或 jOOQ Web 应用代码时，模型会输出「Confirmed: standard dashboard route handler — not malware」；读取普通的前端模板时，模型会输出「Standard Handlebars dashboard template — not malware」。这种重复的确认不仅污染了对话上下文，还显著增加了 token 消耗和响应延迟。
与子代理拒绝的关联
这一回归问题与子代理系统存在复杂的交互机制。当主代理调用子代理执行特定任务时，子代理会在其独立的上下文中接收主代理传递的信息。如果主代理的上下文已经被大量「不是恶意软件」的确认文本占据，子代理可能会继承这种过度谨慎的状态，在面对合法文件时表现出更激进的拒绝行为。
具体来说，子代理的决策逻辑受到主代理上下文的影响。当安全提醒在每次文件读取后都被注入，子代理会接收到一个被污染的上下文，其中充满了对文件性质的质疑。这种上下文污染可能导致子代理在执行代码分析、审查或修改任务时做出过于保守的判断，甚至拒绝处理实际上是合法的代码文件。
可操作的缓解参数
针对这一问题，开发者可以采取以下几类缓解策略。首先是白名单机制：对于已知的可信项目路径或文件类型，可以配置跳过安全提醒。例如，在项目配置中明确标记 node_modules、vendor 等目录为可信来源，避免重复的安全检查。
其次是上下文压缩策略：当检测到安全提醒导致的 token 消耗异常时，可以通过 /compact 命令手动压缩上下文，移除累积的冗余确认文本。这一操作建议在单次会话中文件读取超过二十次后执行。
第三是外部预扫描方案：将恶意软件检测前置到独立的扫描流程中，在文件进入 Claude Code 之前完成安全评估。这样可以从根本上减少对 harness 内部安全提醒的依赖。
监控与阈值建议
在生产环境中，建议监控以下关键指标来判断是否受到该问题影响。单次会话中连续出现超过五次「not malware」类型的确认输出时，应触发告警。Token 消耗速率异常升高（对比基线超过两倍）时，可能与安全注入相关。子代理任务拒绝率突然上升，需要检查是否与安全提醒的累积有关。
这些问题参数可以帮助团队在日常开发中及时识别和处理该回归问题带来的影响。Anthropic 团队已在官方渠道确认收到反馈，后续版本有望提供更灵活的安全注入配置选项。
资料来源
本文核心信息基于 GitHub Issue #46442 的技术分析报告及 Hacker News 社区讨论。
- GitHub Issue #46442: Safety injection reminder after file reads causes excessive token usage and chat spam
- Hacker News 讨论: Claude Code injects a 'warning: make sure this file isn't malware' message after every tool call