planning-with-files 报 [PLAN TAMPERED — injection blocked] 拒绝注入计划内容怎么处理？

planning-with-files 报 [PLAN TAMPERED — injection blocked] 拒绝注入计划内容怎么处理【免费下载链接】planning-with-filesPersistent file-based planning for AI coding agents and long-running tasks. Crash-proof markdown plans, session recovery after /clear and compaction, per-turn re-injection against context rot, deterministic completion gate. Manus-style. Install from npm, the Claude Code plugin marketplace, or npx skills. Codex, Cursor, OpenCode, 60 agents.项目地址: https://gitcode.com/GitHub_Trending/pl/planning-with-files在 Claude Code、Pi 等接入了 planning-with-files 的 agent 会话里如果你给模型发消息后上下文里没有计划内容取而代之的是这样一行[planning-with-files] [PLAN TAMPERED — injection blocked]这说明钩子检测到当前task_plan.md的内容与已存档的 SHA-256 哈希不一致于是拒绝把计划正文注入模型上下文。这是 attestation 机制按设计工作的结果不是安装损坏v2.37.0 起运行/plan-attest后每次 UserPromptSubmit 和 PreToolUse 钩子触发时都会重算task_plan.md的哈希并与存档值比对比对失败就阻断注入见 commands/plan-attest.md。处理目标只有一个让计划文件与 attestation 重新一致恢复每轮注入。先读报错判断是哪个分支在 userprompt 触发场景下阻断消息本身携带排查所需的信息来自scripts/inject-plan.sh的输出[planning-with-files] [PLAN TAMPERED — injection blocked] expectedattestation 文件中记录的哈希 actual 当前 task_plan.md 的实际哈希 Run /plan-attest to re-approve current contents, or restore the file from git.文档给出的出口只有两条确认自己确实改过计划后重新 attest或者从 git 恢复被改动的文件。先用/plan-attest --show查看当前存档的哈希和存放位置并行计划模式在.planning/active-plan/.attestationlegacy 模式在./.plan-attestation确认 attestation 确实存在后再分情况处理。情况一你自己编辑过计划重新 attest这是最常见的情况——计划定稿后你或协作的另一个 agent 会话又改了task_plan.md但没重新批准。处理命令/plan-attest等价的脚本调用是sh scripts/attest-plan.shLinux/macOS/Git Bash或 $env:CLAUDE_PLUGIN_ROOT\scripts\attest-plan.ps1Windows PowerShell 插件安装。注意每次你有意编辑并重新批准计划后都要重跑这条命令。如果你设置了PLAN_ID或PWF_PLAN_ROOT显式选择器且它无法解析到计划attest 脚本会直接报错退出而不会回退去 attest 另一个计划见 docs/attestation-locking.md。多个计划并存时用PLAN_ID固定目标计划export PLAN_ID2026-01-10-backend-refactor sh scripts/attest-plan.sh情况二你没改过计划文件被意外改动如果expected与actual不一致但你没有编辑过task_plan.md说明文件被工具输出、协作者或其他 bug 改写了——这正是 attestation 要拦截的场景。此时不要急着重新 attest那等于批准了被篡改的内容先按报错提示从 git 恢复文件再重跑/plan-attest校验哈希是否回到预期值。情况三想让计划回到可自由编辑状态如果你还在迭代计划、不想被哈希锁定移除 attestation/plan-attest --clear--clear移除 attestation 文件计划重新开放编辑需要重新锁定后再运行一次/plan-attest。验证用 plan-doctor 确认注入恢复重新 attest 后在项目根目录运行自检脚本只读诊断不写任何文件总是以退出码 0 结束sh scripts/plan-doctor.sh看injection一行示例输出字节数随计划内容变化PASS injection: emits plan context (1234 bytes)出现PASS ... emits plan context说明计划内容已正常进入注入通道。如果仍报WARN injection: plan is attested but the hash mismatches — run /plan-attest (or scripts/attest-plan.sh) to re-approve the current plan则回到情况一/二重新核对。plan-doctor 还会报告 attestation 文件是否位于钩子查找的位置.planning/dir/.attestation或根目录.plan-attestation可用于排除attest 到了错误目录的问题。在 Pi 中同样的排查路径是/plan-attest --show后视情况/plan-attestPi 扩展读取的是与 Claude Code 完全相同的.attestation文件attest 一次在两个运行环境同时生效见 docs/pi-agent.md。已知误报先查版本再动手如果你的task_plan.md确实没变却每次都报[PLAN TAMPERED]可能是已修复的历史 bug升级即可v3.9.02026-08-01PWF_PLAN_ROOT绝对路径绑定下GNUsha256sum对需要转义的文件名Windows 风格路径会触发在输出行前加反斜杠导致解析出的摘要永远与 attestation 不匹配每次触发都报篡改。v3.8.02026-07-21SHA 缓存键曾只用相对计划路径同一台机器上所有 legacy 根项目共享一个缓存槽另一个项目的旧缓存可能让本项目误报篡改。缓存键现在包含绝对项目根升级后每个计划会多一次重新哈希缓存自愈。更早版本中attest-plan.sh非原子写 attestation偶发产生截断或零长度文件下一次钩子触发即误报篡改。现在的实现是写临时文件再原子重命名flock可用时用flock -w 5包裹重命名见 docs/attestation-locking.md。升级后仍误报时再按前文的--show/ plan-doctor 流程定位。边界说明attestation 存档的是普通本地摘要不是带密钥的签名或人工批准证明任何能同时改写task_plan.md和.attestation的进程都能让新内容通过校验计划内容与工具结果、外部来源一致也不代表内容可信docs/attestation-locking.md 的 Trust boundary 一节。它的价值是拦截计划被静默改写这一类变化而不是为计划内容本身背书。【免费下载链接】planning-with-filesPersistent file-based planning for AI coding agents and long-running tasks. Crash-proof markdown plans, session recovery after /clear and compaction, per-turn re-injection against context rot, deterministic completion gate. Manus-style. Install from npm, the Claude Code plugin marketplace, or npx skills. Codex, Cursor, OpenCode, 60 agents.项目地址: https://gitcode.com/GitHub_Trending/pl/planning-with-files创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考