Codex 只改了脚本权限，为什么代码 diff 没变化却影响 Linux 执行

脚本一行没变，Git 却显示权限变化，这不是可以直接忽略的噪声。Git 对普通文件记录的模式可以区分非可执行和可执行状态；内容对象与文件模式是两份证据。验收 Codex 改动时只看文本 diff，会漏掉部署后直接执行脚本所依赖的这一位。

内容一样，索引模式不同

本例文件只有一行 echo demo。先把它作为 100644 写入独立临时仓库的索引，再用 git update-index --chmod=+x 改为 100755。两次读取 git ls-files --stage，应得到相同的内容对象编号，模式却发生变化。检查器同时断言这两件事，避免用“有差异”这一句含糊结论代替验收。

这里的索引操作是演练数据，不接触读者当前项目的暂存区。脚本退出时临时目录被清理，没有修改全局 Git 配置，也没有把演示文件提交到工作仓库。需要复现时请运行附件检查器，不要在已有复杂暂存内容的目录直接照敲索引修改命令。

看哪两份输出

git diff --cached --summary 用于读模式变更摘要；git ls-files --stage 用于核对索引里的模式和对象编号。只有摘要而没有阶段信息，容易把工作区和索引混在一起；只有对象哈希，又看不到模式这一维。真实审查还要注明比较的是哪个基线，因为工作区与索引、索引与提交是不同的比较面。

反例是仅计算两份脚本文本的 SHA256：它们完全相同，于是报告“没有变化”。这项内容判断本身没错，错在拿它替代整个文件条目的判断。验收清单宜同时保存旧模式、新模式、旧对象、新对象及路径，分别显示内容变化和模式变化。

Windows 能证明到哪里

core.fileMode 涉及 Git 是否信任工作区可执行位变化，宿主文件系统也会影响观察结果。本文采用索引级命令稳定构造样本，没有依据 Windows 文件属性去假装验证 Linux 权限。命令通过只证明 Git 索引记录了预期模式，并不证明容器挂载、部署复制和目标文件系统都保留了它。

上线前应在目标 Linux 环境检查文件权限和真实入口调用方式。./task.sh 与显式交给解释器执行所依赖的条件并不完全相同；还要确认解释器路径、换行和脚本内容。可执行位正确但解释器不存在，仍可能启动失败。

如果任务没有要求改变执行方式，意外的模式变化应单独解释；如果任务明确新增可执行入口，则把模式当成应验收产物。不要见到模式变化就批量恢复，也不要给目录中所有文件统一加执行位。逐路径说明意图，比一个笼统的“修复权限”更便于复核。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a003.json，离线检查器 a003.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a003.py。 此项还需本机可调用 Git；操作仅发生在自动创建的临时目录。

一手资料1；一手资料2；一手资料3。资料核对日期：2026-10-24。